On Aug 18, 2006, at 8:05 AM, mindlace wrote:
>
> Kevin, Mario, Jason and Ed,
>
> Thanks for taking the time to reply to my email. You all indicated
> that
> I can add a variable to a form element controller and override the
> template if I would like to add an attribute or other data to a
> widgetized layout.
>
> Let's imagine, for the moment, that I'm a designer that's been
> hired to
> work with a TG site that uses widgets heavily. Let's say I want to
> change the tabs that appear on each page. So I go to the template
> that's used for the page; no markup there that's relevant.
>
> What would give me the slightest idea that I should go to
> tg/widgets/links.py, scroll through the source until I find
> TabberDesc,
> select that string, paste it into a *new* document, change it as I
> thought appropriate, and then ask the programmer if he would pretty
> please use this template instead?
You can store the template in a separate file just to ease this use
case:
class MyWidget(Widget):
template = "templates.mywidget"
The designer can just edit templates/mywidget.kid to change the
widget's appearance, no need to bug a programmer for this.
> Mario, I respectfully disagree that this is a 'good design
> decision'. I
> have been working with web frameworks since '96. I have seen a ton of
> toolkits that try to treat the web as if it were just another
> windowing
> framework. One of my first paying jobs was re-writing a site where the
> original consultants wrote their own writing-html-from-code - *in
> javascript*; I've never since seen this approach bear fruit worth
> eating.
>
> I had foolishly hoped, based on the name "widgets", that tg.widgets
> would be something like konfabulator or OS X's widgets: relatively
> high-level 'bundles' of functionality.
>
> Instead I see things like InputWidget() for <input name='text' />;
> indirection for indirection's sake.
You're right that if widgets were yet another way to create html they
would be pretty useless, however, it's not the case. Widgets also aim
to:
1) Encapsulate most of the view logic for common patterns into a
python egg for easier redistribution, along with all required
resources like css and js files which get automatically pulled into
the template a widget is placed into. Take a look at the Plotkit,
TurboTinyMCE, SelectShuttle... widgets for examples of this.
2) Handle form validation in quite a powerful and flexible way
through FormEncode: Form widgets automatically generate a schema to
validate the input generated by all the widgets contained in it, also
handling the input-name mangling to support nested structures
(fieldsets) and lists (repeating fieldsets).
3) Many other cool things I cannot remember now... ;)
For me, 1) alone makes widgets worth using. It's foolishly easy to just:
import tinymce
....
def controller_method(...)
return dict(widget=TurboTinyMCE())
to get a rich text editor in your page, not worrying about it's
required CSS and JS files which let the magic happen.
Of course, I understand your frustration as the widget library is
heavily under-documented so most of this features are easily
overseen. This should get fixed soon hopefully.
>
> Javascript, CSS, and HTML already give you sufficient expressive power
> to write templates that describe the form you want in a parsimonious
> fashion. It may make it 'easier' for someone who prefers writing
> python
> code to write pages using a series of function calls, but it makes
> things difficult for anyone else who has to decipher what's going
> on to
> make a page happen.
As I tried to point out: widgets are not just Yet-Another-Way-To-
Generate-HTML ;)
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
-~----------~----~----~----~------~----~------~--~---
