On Apr 8, 11:18 pm, "oggie rob" <[EMAIL PROTECTED]> wrote: > So, my first question is whether this could be designed to work > without respect to models. For example, there are a lot of cases where > views might refer to the same data, but not the same models. It would > seem cleaner if there were a separation (and would avoid complications > with inner classes vs. overridden fields). In my particular case, it > would be cleaner to simply have a new class (or classes if it is > easier to manage) that contains ALL the "constant" data.
Well, it should be fairly simple to put together a base class within this framework that can then be subclassed in whatever file you like, where you could then place your placeholder definitions. This way, you'd have a separate class that's not connected to Django's DB framework in any way, but is just a place for your settings. On Apr 8, 11:18 pm, "oggie rob" <[EMAIL PROTECTED]> wrote: > Was there a > reason that you went with field-defined values? I can see the > "context" argument, but seems like a lot of extra complexity if that > is the only reason. I'll list the reasons I chose the current approach, but I should note that I'm not adamantly tied to any of these, they're just the reasons I used when building it. * Like any project, I could only plan for what I could anticipate. I had no way of knowing what other people would want out of it, so I only designed for the way my own project would best utilize it. * Defining them directly inside models allows it to be 100% contrib, with no modifications to Django's core. Given some of the other suggestions here, however, this doesn't seem like the only way to go about that, so I'm open to other concepts. * Defining them within a class allowed me to use descriptors for accessing their values. However, this only explains why they weren't defined at the module level; including a separate class on which to define them on would also satisfy this goal. On Apr 9, 7:32 am, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote: > Integration with the admin interface would be also a nice thing! Well, the supplied editor is based on the admin template, so it visually integrates with the admin interface, but it does still require a separate urlpattern, and no links are provided from within the main admin interface. To me, it'd be ideal for the admin app to have a way to "plug in" contrib apps like this into the admin. This would work quite well next to the Add and Change links for the models, or even at the app level if the app has model-neutral options. Or, worst case, a separate pseudo-app section could be shown, with a list of all the apps that utilize these options, with each link going to a per-app editor. Perhaps, since there's already considerable work being done on the admin interface for newforms-admin, could something like this be included? I'd be willing to do some work on it if it would be a possibility. On Apr 9, 7:56 am, "Honza Král" <[EMAIL PROTECTED]> wrote: > but problem is with name clashes... what if I have a field called > parameters (or constants for that matter)? i think this could work a > bit as a Manager class: > > class MyParams( params.Parameters ): > max_items = params.IntegerParam( 'Max ........', default=6, ) > > class MyModel( models.Model ): > field1 = models.... > field2 = models.... > > params = MyParams() The ability to change the name would have been present in my subclass idea mentioned above, but you bring up a very interesting idea. I hadn't considered the possibility of sharing a set of options across multiple models, and your example does show an excellent way of representing that. In fact, that would tie in quite well with rob's request for defining values without regard to any particular model. If a separate class is used, it could be instiated within a model OR directly at the module level. It could also be useful for other contrib apps to supply their own class, subclassing the base from this framework, but without instantiating it. Take, for example, a framework that logs edits to models. The framework could supply a class with options for what events should be logged, as well as how much verbosity should be used in the log. Since those could apply to any model, it would be up to the individual project to simply import the class and instantiate it on whichever models use it. All in all, I'm starting to like the idea of a separate class that's instantiated wherever it's used. I'll set up a branch for it on the Google Code page and get to work on it. Thanks again for all the feedback. It's great to hear that there are others who need this. -Gul --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
