On Tue, 2007-05-29 at 11:48 +1000, Malcolm Tredinnick wrote: > On Mon, 2007-05-28 at 21:36 -0400, Marty Alchin wrote: > > On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > Aren't you asking the wrong question here? The real issue seems to be > > > "how is admin going to handle arbitrary Field classes that it doesn't > > > otherwise know about?" > > > > Well, I'm not worried about Field classes. DurationField, for > > instance, works just fine in newforms-admin without any modifications. > > Bad terminology on my part. I also meant extra things like Options(). > > > > > For particular models, you can easily do whatever you like as far as > > > admin presentation goes with the existing code. You override methods > > > like fieldsets(), fieldsets_add(), fieldsets_change() and the *_view() > > > (add_view, change_view, etc) methods to do whatever you wish. They are > > > all in the ModelAdmin class and look pretty easy to replace with > > > whatever behaviour you would like. So the framework for the ultimate > > > presentation of the information is already there. > > > > That's true when you have control over the model being represented, > > yes. For django-values, however, it can be placed on any model in any > > project, without django-values having any control over where or how it > > gets used. > > > I probably was not very clear in my explanation. Sorry; let's try again. > > The Options() instance that is attached to a model by django-values > should be viewed as a relation to another model, just like ForeignKey or > ManyToMany key. Editing those requires either something like edit-inline > behaviour or moving to a different page. So this is exactly the same > logic for django-values.
I just made an assertion there and omitted the reasoning: It seems that "extra" things on a model in whatever form they may take are either instance-specific, in which case they are Field sub-classes -- for database-backed data -- or methods, or they are model-specific (e.g. django-values's Option() class), in which case, editing them via the per-instance page is illogical, because the results apply to all instances. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
