On 8/18/06, 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?
I can see that you have a point there to some degree, but I think it's partly a question of target audience. I can't imagine that a tg site would ever really be suitable for handing over to a designer to let them go through and edit things without supervision (though personally I don't think it's ever appropriate to hand something over to a designer and let them do what they want). I think most tg sites will be lead by a programmer, and if necessary a designer would come in and consult. Personally, I hand them a finished site and let them create css code. I they want to change the html, they ask me and I sort it out. If they are very competent I would give them the kid templates as well. I've never met a designer who would want to add longdesc's or anything similar. Normally, the ones I meet seem to say "can we put it all in tables?". > 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. I agree that it is difficult for someone who doesn't know TurboGears to work out what is going on in a TurboGears, but IMO, I don't think it is ever going to be different. (If anything, for me that's added value. I have complete control over my websites. It's lovely when negotiating with a designer to be able to say No, and they can't do anything about it). Ed --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
