On Mar 14, 8:35 am, "Martijn Faassen" <[EMAIL PROTECTED]>
wrote:
> Hi there,
>
> Yesterday I tried to port the Turbogears's autocomplete field to
> ToscaWidgets, but had to give up in frustration. This is not helped by
> my not fully understanding either TG widgets *or* ToscaWidgets. While
> part of this lack of understanding is surely due to my own lack of
> skills and knowledge, it would really be appreciated if the
> ToscaWidgets documentation could be expanded with a conceptual
> overview - the API docs and the existing code are just not cutting it
> for this kind of use case.
Right now ToscaWidgets assumes some familiarity with TG widgets which
shouldn't be that way but I'm afraid it'll be until I have time to get
some decent docs together. There's a widget browser prototype (similar
to TG's) too which will also host widgets docs but it's suffering the
same lack of time I can devote to this project ATM.
> I think I got a decent handle on creating non-compound widgets. I feel
> a bit scared by the magic that ToscaWidgets seems to be doing
> underneath (I tried to process an argument to __init__ before passing
> it to super's __init__.. little did I know this is too late!) but it's
> not a big problem overall.
Widgets do some pre-initialization (that needs to occur before any
__init__ from the widget subclasses is called) in the __new__ method.
You normally don't need to bother about it, just take into account
that all arguments passed to __init__ will be bound to "self" once
you're inside __init__ and that children passed to __init__ or listed
at the "children" class attribute will be bound to "self".
If you need to modify a parameter to __init__ before calling super do
it at __new__ instead, or, better still, override it inside __init___
like so: self-foo = self.foo + self.bar
This "magic" is because widgets are designed to be stateless,
instantiated once and reused in every request. To do this, all state
is fixed at initialization time by parameters passed to the
constructor so it makes sense to avoid a bunch boiler plate like
"self.help_text = help_text" at __init__. This same argument applies
to "update_params" where all attributes listed at "params" are
available at the dict "update_params" updates after calling super's.
> My problem has to do with compound widgets. The autocomplete widget in
> TG is compound, and has several child widgets. In the template for the
> autocomplete field, value_for and params_for are used. These do not
> exist in ToscaWidgets, and I do not know how to do the equivalent.
The new names are "value_for" and "args_for" and are available at any
Widget subclass template. There's also a shortcut for displaying a
child widget with those parameters partially applied:
"display_child(child_name or child_instance)" which is equivalent to:
"children.child_name.display(value_for(children.child_name),
**args_for(children.child_name))"
or
"children.child_name.display(value_for('child_name'),
**args_for('child_name'))"
> Perhaps this happens automatically somehow in ToscaWidgets? I'm
> somewhat shakey about what they do. Getting a mental picture of how
> the data is passed around the widgets is a bit of a struggle for me
> (just a bit of documentation about what the basic ideas are would help
> a lot, I think)
Agree. Again, properly documenting this is high on my priority list
after I get over a project I'm in now. I hope that before a month some
decent tutorials and design overview are available.
In short words: data is bound to the widget from the constructor's
parameters (possibly mangled by __init__) and fixed there. Then, on
every render, all parameters listed at "params" are picked up from the
widget instance, passed through "update_params" where there's a last
chance to mangle them before sending them to the template. Most of the
parameters fixed at construction time can be overriden when calling
"display/render", how many of them depends on the widget's
implementation although ideally all of them should. Some clean-up is
needed in this area to make this more predictable...
>
> Related to this is that in AutoCompleteField, there is a section
> 'member_widgets'. I do not believe one can spell it out this way in
> ToscaWidgets. Perhaps this is spelled out with 'children'. Perhaps
> not. I currently have something like this to list the two child
> widgets in my class:
>
> children = [
> Child(TextField, name="text"),
> Child(HiddenField, name="hidden"),
> ]
That almost should work (there's no longer a "name" parameter", just
"id")
BTW, equivalent to that snippet is the more readable:
children = [TextField("text"), HiddenField("hidden")]
> but I have no idea whether this is even remotely correct, or whether
> if this *were* correct, what it should actually be accomplishing. I
> imagine some name mangling (of the name used in HTML for form
> elements) might be triggered by a parent-child relationship, but I
> don't know. Anything else?
Yep, there's name mangling in order to support FormEncode's
variable_decode. So if a FieldSet with id "fieldset" has a TextField
as a child with id "name", the effective TextField's id would be
"fieldset_name" and the name "fieldset.name", again, these are
overridable at display time if needed (makes more sense to do with the
id to display a child non-input widget more than once and avoid id
collisisions). One thing that has caused confusion is that, neither
the id or name are "hard" fixed at __init__ time. Both can be
overriden at display although it doesn't make much sense to override
"name" as the validator will not be able to find the value when it's
submitted if the name changes.
> Anyway, sorry about my frustration. I do think that perhaps this
> feedback is useful if you want ToscaWidgets to be adopted wider and by
> non-TG frameworks. While I could figure out some basic widget usage
> and creation looking at sample code, the toscawidgets.org website
> doesn't provide enough information to get started easily.
Feedback much appreciated :). I understand your frustration, I just
wish I could devote more time to this project and write some half-
decent docs, but It's impossible for me to do it right now.
>
> Regards,
>
> Martijn
>
> P.S. If you want to push ToscaWidgets outside of TG, I would also
> suggest creating another mailing list than the TG one for discussion
> of ToscaWidgets. It's a bit of a chicken and egg problem though - the
> volume of discussion might not warrant it, but then the volume of
> traffic might not increase if you keep it here either, when it feels
> bound to the TurboGears project as a whole.
That makes sense now. Just created one:
http://groups.google.com/group/toscawidgets-discuss
>From now on please direct all TW related discussion to this group.
However It'll take me a while to update the link at toscawidgets.org :
(
Regards,
Alberto
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
