On 2/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 2/13/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > Right now admin widgets use templates named ``widget/
> > <field_class_name>``. I'd like the change this to be similar to the
> > change form templates and look for templates in this order::
> >
> > * admin/<app_label>/<module_name>/widget/<field_id>
> > * admin/<app_label>/<module_name>/widget/<field_class>
> > * admin/<app_label>/widget/<field_class>
> > * widget/<field_class>
> >
> > Any objections/additions?
>
> I strongly object to this, because that means for *each widget on your
> admin form* it's going to hit the filesystem for *all of those* files.
> So if your admin form has 10 fields (average), and none of them has a
> custom field widget (average), that means it'll hit the filesystem
> FORTY times -- and that's *just* for the widget templates! Not to
> mention the other templates.
>
> I'm already slightly freaked out by the way the current admin site
> checks for all those templates. Customizing the admin form in such a
> way is *not* a common case.
I was hoping/assuming that caching unrendered templates could take
care of this, but I see your point.
> Instead of this hook, how about just using the existing JavaScript
> hook? Either that, or we can add declarative syntax to the 'class
> Admin' like so:
>
> class Admin:
> use_custom_templates = ('field_name1', 'field_name2')
I've used the javascript hook to remove/rename submit buttons, etc.
It's a hack. I'm not thrilled with use_custom_templates, but I could
live with it.
Joseph
