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. > 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. > Isn't the difficulty something like django-values faces is how is the > initial link to the admin page for an options class going to work in the > first place? I'm not sure exactly what you're asking here, but I think the answer is "yes". If you're talking about the HTML link to the value editor, or the more symbolic "link" of attaching the editor to the ModelAdmin class, both are what I'm wondering about. If, however, you're referring to something else entirely, I guess I don't follow. -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 -~----------~----~----~----~------~----~------~--~---
