On Aug 18, 2006, at 9:01 PM, mindlace wrote:
> This would be great, if I could ever use these things without
> having to
> edit the accompanying css/js files, which seldom seems to be the case.
Well, the first "C" of "CSS" stands for "Cascading" ;) This means
that you can override any selector with your own without even
touching the original stylesheet if the later is included after the
built-in. This is as simple as adding your default stylesheet to a
widget's subclass:
class MyCalendar(CalendarDatePicker):
css = CalendarDatePicker.css + [mycssfile]
As for JS, it's seldom needed to edit the code, if you still need to
you'll be better off subclassing the widget you want to tweak and
provide a patched version:
class MyCalendar(CalendarDatePicker):
javascript = [mypatchedjsfile]
>> 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).
>
> This could be cool; I stopped experimenting with the automagic form
> creation stuff once I realized that adding sufficent accessability
> components meant overriding the templates/controllers to the point
> that
> I might as well just, well, write an html form ;)
I was referring to server-side form *validation* and coercion
(turning "2006-07-12" into a nice datetime object you can do
arithmetic and all sorts of fancy stuff with), not form markup
generation.
> Sufficient in this case means: proper <legend> grouping, <labels> that
> work no matter where the form is embedded (a corner case for me, I'm
> aware), longdesc attributes that get fetched for sighted readers via
> XMLHttpRequest, accesskeys where appropriate with some display of what
> accesskeys do what, control over where and how error messages are
> displayed, etc.
I just explained in another recent thread how a widget's template can
be overridden to have *total* control over it's layout. As someone
else has said in this thread, by providing your own template and
parameters to a custom widget you can have *total* control over each
tag's attributes and many other things.
> With the spiffy tabular widget, there are a bunch of other
> accessability issues, but I'm too strung out to go into all of them at
> the moment.
I'm looking forward to reading them, maybe in another rant post... ;)
> Basically, if you're willing to live with all the assumptions that the
> widget-writer made, you can use widgets ok; I just feel like (at the
> moment) it's way too difficult to change those assumptions you need to
> change for your app without digging through half a dozen layers of
> indirection.
I guess the same is true for any semi-complex under-documented
library, but that should change soon once docudo is up to full speed
and we start writing those needed docs.
The point is that some people and I actually find widgets useful and
*much* more productive (and fun) than manually generating markup,
validation logic and tracking needed resources and making sure you're
not duplicating code all over around. However, YMMV... luckily
there's nothing in TG stopping you from doing it your way ;)
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
-~----------~----~----~----~------~----~------~--~---
