template engines and configuration data
Greetings, So having finished my first iteration of Breve, I've come across a glaring incompatibility between how TurboGears and Pylons interact with template engines: specifically how configuration information is passed into the template. It seems TurboGears (which more or less defines this API) passes in configuration data as a function which can be called to fetch specific configuration data, whereas Pylons passes in a dictionary. Further, TurboGears passes this information in the render() method while Pylons passes it in __init__(). For example: # TurboGears: def __init__ (... ): ... def render ( ... ): value = self.get_extra_vars ( )[ 'std' ][ 'config' ]( 'breve.foo' ) # Pylons: def __init__ ( ... ): for k, v in options.iteritems ( ): if k.startswith ( 'breve.' ): breve_opts [ k [ len ( 'breve.' ): ] ] = v def render ( ... ): ... Personally I prefer how Pylons does it (more efficient to pass at template instantiation, more flexible to get an iterable than a function, and not as seemingly complex), but the real issue is that it requires special-case code in the template engine's Buffet adapter which is just plain wrong. I'd rather have one mildly bad API than two incompatible ones that must both be supported. Being passed the values at different times isn't an insurmountable obstacle (in my own code I simply always delay until the render() method is called to fetch them regardless of when they are passed), but having to fetch them two completely different ways is pretty annoying. I've written to Christian Dowski (Buffet's author) regarding this issue, but ultimately a decision is going to require framework support and I'd like to hear any thoughts on the matter from people who might be able to help resolve it. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
None option for options_for_select_* helpers
Hi all,
I have a small concern with the options_for_select_* helpers: I find
myself, more often than not, having to add an empty option, meaning
that no object is selected. Typically, that happens every time I have a
foreign key that is allowed to be NULL.
One approach would be to use a Null Object design pattern, and actually
have an object that represents None selected, but it is not always
applicable (like for me now, porting an existing app that was not
designed with Null objects), and can be overkill if all you need is to
be able to select None.
On another framework I helped design, our
'options_for_select_from_objects' equivalent takes a couple of extra
arguments ('def_value' and 'def_value_display', probably not the best
naming, but anyways...) to define the value and display string of that
extra None option. This lets us build a select from objects,
including the None option, in a one-liner in the template.
In Pylons, using the default helpers, I guess I could craft a Null
Object and insert in in my objects list. I could also build a dict from
my objects, add the None option, and use
options_for_select_from_dict... All of these being quite overkill for
what could be a one-liner. For now, I am thinking to create my own
helper, options_for_select_from_objects_with_none (argh, name getting
way too long for my pythonista taste...), that wraps
options_for_select_from_objects and takes my extra two arguments.
Now, there may be an elegant way to do it in Pylons that I am not aware
of. How do you guys do it?
Cheers!
--
Yves-Eric
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: None option for options_for_select_* helpers
OK, next time I will code before I ask... Writing the simple
options_for_select_from_objects_with_none helped me find what is
probably the right way to do it with existing helpers:
% h.select('room_id', h.options_for_select([['No room', '']])
+ h.options_for_select_from_objects(c.rooms, 'name', value_attr='id'))
%
Compared to using options_for_select_from_objects_with_none, it is not
that different. And in this example, it's even 2 characters shorter:
% h.select('room_id',
h.options_for_select_from_objects_with_none(c.rooms, 'name',
def_name='No room', def_value='', value_attr='id')) %
Sorry about the noise ^^;
Cheers,
--
Yves-Eric
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
