On Feb 13, 2006, at 11:22 AM, Adrian Holovaty wrote:
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.
Yeah, I'd thought about that, and I'm concerned by it too -- but I'm
not sure how to go about fixing it.
One response is that the admin itself is not the "common case" and
that a certain amount of processor/disk intensiveness is OK, but
that's not really an argument I feel comfortable getting behind.
However...
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.
Sure, it may not be a common case, but that's not a reason to make it
impossible -- Django isn't Rails, after all :)
Instead of this hook, how about just using the existing JavaScript
hook?
I really feel like the JS hook is a hack, and it's actually going to
be deprecated in the Dojo-integration stuff (in favor of just using a
custom template with new JS in the head).
Either that, or we can add declarative syntax to the 'class
Admin' like so:
class Admin:
use_custom_templates = ('field_name1', 'field_name2')
Yeah, I like this idea a lot. Actually, I like it even more than I
like my proposal :) How about this syntax::
class Admin:
custom_templates = {
'field_name1' : 'widget/template_name1',
'field_name2' : 'widget/template_name2',
}
(i.e. a dict mapping field names to template names).
The other option, of course, is caching, but I'd like to avoid that
if possible.
Jacob
