On 2/14/06, hugo <[EMAIL PROTECTED]> wrote:
> But one thing I think about: wouldn't it be needed to have some
> overrideable function to handle the data from the custom template?
> Because the current code still expects the data in the same format as
> it would have with the default template - so
>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')
Heh, I like that. What I don't really like is the fact that st
Hi. I have a situation where I store a pickle in a field that I'd like
to unpickle for an update form and on save pickle again. What would be
the best approach for this scenario given the current or future
possibilities of admin customization.
Regards,
David
Jacob Kaplan-Moss wrote:
On F
On Feb 13, 2006, at 12:05 PM, Joseph Kocherhans wrote:
Another option (although I'm not sure that I like it) is to allow
either style. The tuple would use the template lookup described in
Jabob's first email, and the dict would of course allow you to supply
*any* template path. It's more flexibl
On 2/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 2/13/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > How about this syntax::
> >
> > class Admin:
> > custom_templates = {
> > 'field_name1' : 'widget/template_name1',
> >
On Feb 13, 2006, at 11:57 AM, Adrian Holovaty wrote:
Seems a bit boilerplatish, compared to a simple list of field names,
but the advantage of this would be that you could easily reuse
widget-specific templates. On the other hand, you could reuse
widget-specific templates with the field-name lis
On 2/13/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> How about this syntax::
>
> class Admin:
> custom_templates = {
> 'field_name1' : 'widget/template_name1',
> 'field_name2' : 'widget/template_name2',
>
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),
Adrian Holovaty a écrit :
>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')
>
>Adrian
>
>
Hi i'm nobody.
I'd j
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/
> > ``. I'd like the change this to be similar to the
> > change form templates and look for templates in this order::
> >
On 2/13/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Right now admin widgets use templates named ``widget/
> ``. I'd like the change this to be similar to the
> change form templates and look for templates in this order::
>
> * admin///widget/
> * admin///widget/
> *
On 2/13/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> Right now (thanks to Robert's awesome admin work a few months ago)
> you can easily make a custom template for an admin change form. I've
> found at times that this is too heavyweight for me since often all I
> want to do is override th
Hey folks --
Right now (thanks to Robert's awesome admin work a few months ago)
you can easily make a custom template for an admin change form. I've
found at times that this is too heavyweight for me since often all I
want to do is override the display of a specific field. For example:
13 matches
Mail list logo
