Jason Chu wrote: > 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.
I would agree that there should be some code that massages the data before the template gets it. > 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? Not particularly, but I don't put too much code in > > 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. OS X widgets are "just" html pages with some javascript objects that allow for (some) access to the local filesystem... the only magic is the canvas element, supported in Firefox as well. Konfabulator uses its own xml syntax, which I'm not advocating for :) > With HTML (especially if > you want semi-valid HTML), you have a lot more constraints you have to > fit in. I'm not sure what these constraints are, aside from the fact that css/js has to be included 'before' the widget html is. > 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. Honestly, in this case it seems like javascript event handlers would do the job of picking up the rows to have the extra behaviour. > 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? the javascript part seems like it'd be handled by including via <script href="control_click.js" /> so it's loaded once. I admit that kid makes automatically including the html stuff a bit painful, which is why I moved to Markup (http://markup.edgewall.org) where I can programmatically specify what should be included in a page. > I don't know of a way to add > javascript and HTML structure around something without just writing it [...] > 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. I'm working on something like this, using Markup instead of kid for the xpath matching and sane include approach. Basically all the "widgets" are well formed xhtml pages, and I go through the templates pulling out the CSS links/style elements and populating the "target" page with them. Meaning if you look at the widget page, you see the widget, all of its error conditions, etc, and can edit the html. In a rendered page, the appropriate elements get matched to the html in the page. Anyway, more in a week or so when I have delivered this beast. ~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 -~----------~----~----~----~------~----~------~--~---
