Kevin Dangoor wrote: > As I mentioned previously (in "TurboGears forms first look": > http://tinyurl.com/c28c7), turbogears.forms has the concept of > "widgets" that are put together to create a form. In fact, widgets are > so important to how forms are put together that I've renamed the > package turbogears.widgets. Form objects are, in fact, widgets (and > now live in turbogears.widgets.forms).
Yes, renaming the package in widgets is the right thing IMO since widget will be (are) first class component for TG. > > I know that there are times when you need complete 100% control over > how things look on the web. Even though you can extensively customize > widgets, there will be circumstances where you need to go even > further. For this reason, widgets also support output of Kid for the > purposes of customization. You'll be able to take that output and drop > it directly into your template so that you can modify however you need > to. > Great! > ... > > Customizing Widgets > ------------------- > > The easiest customization you can do is to include a stylesheet that > implements the classes used by the widgets. All of the standard > widgets should use CSS classes extensively and consistently to make > them easy to customize. Is there an easy way to customize classes names used by widgets without specifying a different template? maybe a dictionary? I'm sure I'm missing something here (excuse me in this case) > > That's not hard. How do you know what to put in that template? The > TurboGears Toolbox will help with that, but this message isn't about > the Toolbox :) The Toolbox looks cool indeed! Can't wait to see it in action. > > Sometimes just changing the generated markup isn't enough and you need > to change the behavior of the widget. Widgets are standard Python, so > subclassing will let you customize further. Brilliant! > > Writing Widgets > --------------- > I'll go for what is currently the most complex widget to show the > parts of writing a widget: > > class CalendarDatePicker(Widget): > css=[CSSLink(static, "calendar-system.css")] > javascript=[JSLink(static, "calendar.js"), > JSLink(static, "lang/calendar-en.js"), > JSLink(static, "calendar-setup.js")] Regarding the calendar widget, I've seen you have put all its javascripts under the static directory, maybe (since there are many things there and it will probably grow) it's better to put them on static/calendar/ (easier to maintain/update), the same goes for others widgets. > > But, I wanted to get a first look out there. I think this is ready for > people to start playing with and trying out (and certainly commenting > on!). Great work IMHO, it's clear that you have put much thought (and time) on this problem. 0.9 will simply rock! Ciao Michele
