"Michele Cella" <[EMAIL PROTECTED]> writes: > Hi Jorge, > > This is actually a problem, and sometimes ago there was a discussion > about this: > > http://tinyurl.com/cd525
It looks more like a "one" post than a discussion :-) At least for the code generation part... > I've also made a wiki page to collect feedback like your: > > http://trac.turbogears.org/turbogears/wiki/WidgetsBrainStorming > > As I noted on the wiki page the ability to give a valid kid file to > designers to be customized is vital and is (and would be for widgets) a > killer feature provided by TG. I think that Wikis are good for storing results of what has been discussed, but very bad at discussing subjects. We loose de dynamics that we have either in email or netnews, besides it is worse to see the thread evolution and you have to keep on checking the website + the ML... If you don't mind, I prefer discussing things here and then we can put the results of our discussion at the Wiki. > ATM you can override/customize the template used by your form widget by > passing a new template argument to the widget constructor (template can > be an inline string definition or a package containing a kid template). > You can find the original template in the turbogears.widgets package, > once the ToolBox is ready it will assist you for this step. > > Today I was thinking (but I'm not sure) that maybe we should be able to > specify a different template at widget insert time (not or not only at > instantiation time), an example using the new syntax I proposed on the > wiki page: But how would this solve the problem of my webdesigner customizing the way the form looks? How would he edit the resulting HTML without touching my "controllers" code? And how would I use the widget generation system allowing him to do that? Now I create the templates and they work very nice. I have to write some HTML but then, the webdesigner can do all what he wants and later I can put in code (if I haven't done so before) to make it more dynamic. > <widget name="contact_form" > template="myapp.templates.widgets.contact_form" /> > > The ability to specify a template on the view side will help designers > find what thing they need to customize and ensures a clean MVC > separation. > > Problems remain for complex widgets like forms (that contain other > widgets). Or a website that implements a bunch of scripts, such as mine. I have several database tables and I'm creating a web interface for a system that exists as a GUI now. So basically, every "window" on the GUI maps to a new template with 2 or more forms plus some code to view data that is already at the databse. > Another solution can be a script that let's the developer (you) fetch a > given template to be customize: > > tg-admin customize widget FormTable myformtable.kid > > you can then place all widgets templates on a directory so that your > designer can customize them along others template: > > templates > |_ index.kid > |_ blog.kid > |_ widgets > |_ textfield.kid > |_ textarea.kid > > this is like the solution I proposed on the discussion about code > generation, but there are some problems regarding TG new releases and > keeping thing in sync. I believe it would be better having something like: templates |_ index.kid |_ blog.kid |_ forms |_ formName |_ textfield.kid |_ textarea.kid This would make it possible to have different customizations for each form. Dunno who'll need that, but if someone needs it, it is possible to have it. > If you (or others) have opinions please add them to the wiki page, it's > important to make widgets easy to use and to customize, and Kevin is > interested on any feedback. As I said, I prefer adding results of discussions to the wiki insteado fo the discussion itself. I still think that this is harder than adding the validator in my class method and having the widget complemented at the template. Something along the lines of your py:match example but allowing me to override and add new attributes and content, keeping what the designer added himself untouched. Lets say that I add some 'py:attrs="proc=False"' to a few fields that looks like: <input class='exampleInput' size='10' py:formField='myWidgetInstance' /> Then the resulting HTML could be: <input class='exampleInput' size='10' proc='False' /> If, OTOH, I had created a conflict with him, then code would have a higher priority. Lets say that I now add 'py:attrs="proc=False, size=15"' to: <input class='exampleInput' size='10' py:formField='myWidgetInstance' /> Then the resulting HTML could be: <input class='exampleInput' size='15' proc='False' /> Then, on every field of every form I could just use the "py:formField" attribute indicating the instance of my widget and it would be used there. This way I don't prevent the webdesigner from working and I can easily send data to my template and have "the right thing"(tm) done. It would even eliminate the need of a new directory or extra templates. And would benefit from the validator being declared with the widget instance instead of within the decorator... -- Jorge Godoy <[EMAIL PROTECTED]>
