On Monday 16 July 2007 07:02:27 Marco Mariani wrote:
>
> 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.
> 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.
> For point 1), an assigment of d['id'] to a global counter.next() in
> update_params() can be enough for many cases.
> An UUID makes the document so ugly to read that I'd rather avoid it.
I don't get what is this "id". Is it the HTML id attribute? 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.
> For 2), I know there are templating packages that would let me modify
> the rendered document as an ElementTree, so that for each widget
> insertion I could check that javascript and css are properly loaded. I
You'll be rewriting what is already there and doing the hard work by
yourself... It isn't worth.
> don't think this is the case for Kid, and I'm not sure about Genshi.
It would probably work... But then, if you're doing this by yourself, you'll
be missing a lot of the automation done by widgets.
> The YAHOO.Loader approach could work for CSS too, but I expect it would
> pose cross-browser compatibility issues.
> Both approaches break on XMLHTTP-retrieved snippets.
>
> I'm not asking for any change on the trunk, just wondering how the
> others approach the issues and what are the work-arounds.
I believe that the standard mechs would work... I don't know why it isn't
working for you. Maybe you forgot something on your templates and didn't
look at the repeating widgets. Either that or I didn't get the problems.
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
