> There are some things that we do though, that I don't see in Django. The
> biggest is our logging system, which I really like. In Django I've
> just seen logging in the admin page with the 'History'. Our setup is that
> we have a class LogEntry (actually action_log but i would change it now)
> correspding to a table in the db with all of the changes.
It makes sense for Django not to add this overhead by default. However
it is really easy to add on your own on the classes where it makes
sense. For instance, I built a simple Issue/Bug tracker (similar to
Trac's) and for that you want full change tracking. By overloading the
save() command (in magic-removal, in trunk you would utilize pre_save
and post_save), I have it generate a complete changelog on every save.
Right now you have to do this manually, so it might be useful for
someone to build a more generic package that might be useful to plug
into any sort Model class. If you want to look at my current code for
ideas, I'll be happy to let you see it.
Your triggers needs could also probably be taken care of in the save()
overload (another example from my issue tracker is that it generates
emails with change notifications).
> We have authentication in our website that is tied to the user's main
> password, which we want to keep. This brings up two things - Is there a
> way to have the admin interface pwcheck based on a different method? In
> our case, NIS. And having an easy way to slip an authentication page into
> Django 'apps' is good. There might be something like that already.
This is still being debated as to the best way to approach a lot of the
authentication issues. Feel free to try to come up with some good
general approach and offer it as a solution.
> We also have the equivalent of the Django admin interface in command line
> form.
> We have a program called 'userbase' which sysadmins can do to query
> anything about a user or users. For example:
> userbase -look activeusers -with resources cluster1,cluster2 \
> -with 0 sponsors -query name_first='Alan' -get name_last
Django's query syntax is very clear and easy to read, and on most
systems you can easily use Python scripts like shell scripts and you
can easily type in ``python`` for a command line or for a better
shortcut with some nice auto-imports you can do ``python manage.py
shell``.
An example script might look like (in the recent descriptor syntax):
``
#!/usr/bin/python
import userbase.models.User
users = User.objects.filter(resource__name='cluster1') | \
User.objects.filter(resource__name='cluster2')
users = user.filter(active=True, sponsor__count=0, name_first='Alan')
for user in users:
print user.name_last
``
Not as compressed as your one-line command, but very readable, and even
easy enough to do on the fly from a Python console. Not to mention you
are free to make as useful a Python API as you need (for instance
adding an active_users filter to User, if that is commonly used).
Again, no reason not to just use Python for such command-scripting
needs.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
