On Fri, 18 Aug 2006 06:05:36 -0000 "mindlace" <[EMAIL PROTECTED]> 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? > > 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. > > 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. > > ~ethan fremen It may be nice to have a template-centric focus developing widgets but I have a few questions about it. How would you control what happens to data before it hits the template? I'm not sure that variables can be inferred from kid templates or that how they need to be massaged before hand can be inferred. If widgets were template-centric, wouldn't that mean a lot more widget logic (the stuff in update_params, etc) would be embedded in the templates? Two problems arise from that: it's common use to embed as little business/app/processing logic in the template as possible and then designers are responsible for data manipulation and processing. Do you trust your designers to write python code? The thing about konfabulator or OSX's widgets (if I'm not mistaken) is that they're written for the konfabulator or OSX widget "canvas". You can do whatever you want with that (interface wise) because the API is much more flexible than something like HTML. With HTML (especially if you want semi-valid HTML), you have a lot more constraints you have to fit in. Unless I make everything a floating, absolute div... but who would want to do that? How is that different from using a widget framework in javascript? If you're just referring to konfabulator and OSX's widget's ability to be dropped anywhere and have everything they need then it's pretty much already been talked about. Someone suggested storing controller methods in the widgets and it was decided not to. Generally grabbing data inside a widget is possible, but something that's frowned upon. You're free to try it though. I don't know how expressive HTML/CSS/Javascript are. In our application (http://oprius.com) we list rows of data that you can ctrl-click on to turn them into text fields for editing. If we generated that ctrl-click code in the template, every page that uses them (let's just say there are 4 main pages, with something like 6 or 7 actual tables) would need a copy of that ctrl-click javascript and HTML. Why would I not want to wrap the data that's going to my template anyway with a little something to automatically add the ctrl-click javascript and HTML? I don't know of a way to add javascript and HTML structure around something without just writing it (well, maybe if I had a javascript function that looked for a css class and did DOM manipulation after the page was loaded... but then I'd have to rescan anything I stuffed into the page using innerHTML... and we load a lot of our tables using JSON requests, so it would happen often...). In case you haven't noticed, I'm looking for actual concrete changes/examples not just that TG widgets had better shape up before you'll stop slinging dirt at them. Thoughts? Jason
signature.asc
Description: PGP signature
