webcomm wrote: > I've been playing with django in recent weeks and have been impressed, > but there is one publishing/programming problem I'm not sure how I > would handle with django. I'm thinking of a site where dozens of > different users need to frequently create and edit content types. > > I have in mind a site where several dozen privileged users can create/ > edit event types and then allow hundreds of other users to submit > events that conform to those event types. Event types would > essentially be models that are associated with a template. The > privileged users would be able to edit templates via the interface and > associate each of their event types with a different template. > > I'm not sure how this could work since the server needs to be > restarted each time a model is edited. This is my first time working > with a framework that requires an apache restart each time a model is > changed, and I haven't built a production django site, so I'm not sure > if it's really feasible to build a site where apache might need to be > restarted dozens of times each day. I'm not sure if this creates > extra overhead and don't know if the restarts are somehow visible to > site visitors... or might in some way interfere with the user > experience. > > It seems like it might be possible to store all the data for all > events (regardless of event type) in a single table. The table would > have an ID column, a field ID column and a value column. Meanwhile, > the table for event types would have one column with all the field > metadata for that event type. The field metadata column could store a > list of lists, with each list consisting of a field ID (to reference > the event data table), a field definition and a field label. > Something like that. Such an approach would seem to make it possible > to handle a lot of event types without ever editing the model classes > in a models.py file... no? > > I'm wondering if the design I've described above is already in use in > some publicly available module/app that I could look at... or if there > are problems with this type of design. Or if there are other > approaches to the problem I've described. > It sounds as though you are on the right track. Essentially your models need to be complex enough to describe all possible events that your users might want to create. This should avoid the need to restart the database, but you may well find that you need several different tables (in much the same way your database uses several internal tables to describe the structure of your application data).
regards Steve --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
