You can view another good frameworks, like www.miolo.org.br tha goes further in this way.
Correct me if I'm wrong.
mario h.c.t.
On 8/17/06, Kevin Horn
<[EMAIL PROTECTED]> wrote:
I won't get into philosophy here, but most of the standard widgets (at least the basic ones...buttons, forms, textfileds, etc) can take one or more "attrs" parameters, which add arbitrary parameters to tags in the template. Does this not solve your attributes problem? Is this not enough for your purposes? Or am I misunderstanding the issue?
Kevin HOn 8/16/06, mindlace < [EMAIL PROTECTED]> wrote:
Gentlebeings,
I was excited about the notion of widgets; indeed it was one of the
primary things that induced me to start developing against the alpha
release rather than the production release.
Unfortunately, as implemented they're completely useless to me, because
of accessability issues and the, pages-as-python-code idea that seems
to be at the center of them.
Accessibility means I have to guarantee that all of the pages I
generate are accessable. This means that either the widget framework
has to completely adopt accessability - something that's likely
impossible - or it has to make it so that I can accessable-ify the
widgets easily.
To be fair, the widgets go a reasonable length towards being
accessable, by having label elements and the like. Unfortunately they
don't include all the accessability niceties, like longdesc attributes,
the myriad of attributes that make tables accessible, or much in the
way of ensuring that the JS provides meaningful results to screen
readers.
I was prepared to deal with this; I figured I'd just modify the widget
templates appropriately. This is where I started to run into the second
part of the problem.
The problem, basically stated, is that it is a mistake to generate
templates in code. The conceit of tg.widgets is that a form or widget
should be created by some python code that 'fills in' the templates.
Examples include setting titles, label values and the like via keyword
arguments to constructor methods.
This makes things difficult for i18n, painful for collaborating with
designers, and difficult to make accessibility modifications. As a
simple example, if I need to include a longdesc attribute, I need to
override the constructor *and* the template, or I need to override the
template only and provide some other method for filling the attribute,
which makes it even harder to understand where a bit of generated
markup is coming from.
In my little world, it seems like widgets should be templates (and yes,
the *template* should contain js, css, error messages, alternate
versions, etc) with python helper code, rather than code that generates
templates. I admit that I won't be able to help much on this end for a
while, but I wanted to get the idea out there while widgets were not
quite frozen in their approach.
Thanks for hearing my kvetch,
~ethan fremen
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
