On Fri, 14 Apr 2006 19:31:22 -0000 "Michele Cella" <[EMAIL PROTECTED]> wrote:
>
> Hi guys,
>
> I would like to hear your opinion on these things:
>
> 1) We have the nifty template_vars attribute that let's us pass values
> at class, construction and display time without the need to implement
> a single line of code.
>
> While writing some widgets I have noticed that I would like to use it
> even for some parameters that I need but that at the end will not end
> up to be used inside the template (an example is the disabled_fields
> parameter for a form), in other case the name used in the template is
> the same as the one in template_vars but the content of the variable
> is not exactly the same.
>
> So I'm wondering should we rename template_vars to a more generic
> name? parameters perhaps? the reason is that I avoid using
> template_vars if the attribute used is not directly present inside
> the widget template since the relation between template_vars and
> template is being lost in this case.
>
> Or should we introduce another type of "magic" attribute like this one
> to manage those case? something like other_parameters (better name)?
> this one will automatically remove things from the dict after
> update_data has finished, but it's not my preferred one since we will
> need to explain the difference between this, template_vars and also
> member_widgets for compounds.
>
> The idea is to get to the point where you can write almost any widget
> by just using those magic attributes and an update_data method, also
> the idea is that you can easily tell the widget user how he can
> customize the widget behavior by just looking at the content of those
> attributes or printing them.
>
> For example ATM disabled_field is managed in this way:
>
> disabled_fields = d.pop("disabled_fields", Set())
>
> and is somewhat hidden inside update_data and not easily documentable
> even for the widget browser that could just list the content of
> "parameters" and for compounds "member_widgets".
I think template_vars is fine. When you put something into
template_vars, you're saying you want it available to the template.
That doesn't necessarily mean that you're going to use it in the
template.
> 2) I would like to rename some of the generics methods we are using to
> make it clear that you can use any type of object that provides those
> methods, just like in python you can provide a custom iterable with a
> proper __iter__ method, so that's what I'm proposing:
>
> retrieve_javascript -> __javascript__
> retrieve_css -> __css__
> validate -> __validate__
>
> I think that's all for 2) as ATM I can't think of any other method
> used inside controllers.py in this generic way, ie without checking
> for isinstance(obj, Widget)
Isn't __ the pseudo-private variable syntax? Doing a quick test, it
looks like that rule only applies to references inside methods of a
class (unless they're existing __ named methods) ie. methods defined
(with def) and referenced as self.__foo__ work, but when you try to set
a self.__foo__ inside a method, it translates it to
self.__Classname_foo__.
I think that's more confusing than I'd like.
Does a Widget really only need those three methods to be a widget?
What about display and render?
Jason
Jason
signature.asc
Description: PGP signature
