Jorge Godoy ha scritto:
>> 1) have an 'id' property much like the field_id in FormField, to be
>> able to properly refer to the widget container in YUI's constructors and
>> CSS
>>
>
> Hmmm... You can override the mechanism used on widgets to do that. But you
> have to be careful because it is important to chain widgets and tie it to the
> correct set of validators.
>
No, no. Validators are not an issue. I'm not talking about FormFields,
but about simple Widgets.
I've mentioned FormFields because they provide field_id, which is
constructed from the path of the parent compound widgets, thus leading
to a unique way to refer to, for instance, the HTML element containing
the widget.
From CalendarDatePicker:
<div xmlns:py="http://purl.org/kid/ns#";>
<input type="text" id="${field_id}" class="${field_class}"
name="${name}" value="${strdate}" py:attrs="a
<input type="button" id="${field_id}_trigger"
class="date_field_button" value="${button_text}" />
<script type="text/javascript">
See? To properly use the javascript library that comes with the widget,
we need to have an unique HTML ID. Alas, we have it.
Now, what happens if I want to provide a wrapper around LinkButton (one
of the simplest widgets in YUI)?
I'd like to use ${linkbutton(href="http://www.turbogears.org";,
label="Click Me Please")}, maybe with an icon image or other features
but that's not the point.
There are three mechanisms to build it:
1) from existing markup
<a id="mybutton" href="http://www.turbogears.org";>Click Me Please</a>
<script type="text/javascript">
new YAHOO.widget.Button('mybutton')
</script>
This Button() constructor will replace our element with a new one, much
like this:
<span id="some_new_id" class="yuibutton">
<span class="yui-firstchild">
<a href="http://www.turbogears.org>Click Me Please</a>
</span>
</span>
Note that some_new_id can be generated by YUI or passed to the Button()
constructor.
2) from yui-style markup.
This method will start from a markup similar to the one generated by
method 1)
In this case, the KID template contains the two <span> and the <a> tag.
Button() is called with the ID of the outer <span> element.
3) completely from javascript. But you need to provide the container:
<div id="${field_id}_container" />
<script type="text/javascript">
new YAHOO.widget.Button({type:'link',label:'${label}', href:'${href}',
container:"${field_id}_container" });
</script>
The Button constructor could also be passed an Element object instead of
an id, but there is no way that I know of, to get hold of the containing
<script> tag. If this were the case, a container could be automatically
put before it.
As you see, if each of the three cases, there is a need for a unique ID.
But widget names are seldom assigned, there is no function to build an
ID from the path, and no repeating-widget mechanism like there is for
form fields.
>> 2) automagically including javascript and css when widgets are used in a
>> page, without explicitly returning them from the controller. Many times
>> I'm forced to do a census of the widgets I'm using in the template, and
>> put them in the returned dict.
>> It would be _sweet_ to just call wid.SomeWidget() from the template
>> without adding it to the controller.
>>
>
> This should be automatic. Did you remove the lines that insert CSS and JS
> (on
> the head section and at the bottom of the html page) from your master
> template? If you didn't and you're doing the right thing on your widgets --
> take some of mine or Alberto's as example -- they should be returning CSS and
> JS automatically to your page.
>
Please note that I've written "without explicitly returning them from
the controller".
Can you pass widgets=tg.widgets to your templates, and display
widgets.Tabber() without touching the controller's returned dictionary
to add a tabber instance there, too?
You can, but it works only if the Tabber widget has no javascript or css
attached.
> If so, it should
> be unique on the page and autogenerated as well. If it is for your widgets,
> it will be unique within the context where the widget is used:
>
> - Widget with ID "me" alone on the page will render an element with
> ID "widget_me" (for example)
> - Same widget on a form: "form_me"
> - Two forms on the same page, using the same widget: "form1_me",
> "form2_me".
>
> So you always end up with a unique ID. If you need more instances of the
> same
> widget inside the same form doing the same thing and with the same name,
> check the code for repeatable widgets. You can see it working on my package
> for DynWidgets.
>
I reckon what you said does only apply to FormField widgets, right?
> I believe that the standard mechs would work... I don't know why it isn't
> working for you.
The standard stuff is working. I have a few dozen forms with repeating
widgets, widget and form-level validators, RemoteForms and I've also
done some ajax widgets.
> Maybe you forgot something on your templates and didn't look at the repeating
> widgets. Either that or I didn't get the problems.
>
Those are not "problems", just minor annoyances that I could happily
live without, expecially when wrapping complex widgets like those in
yui-ext.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
