Jorge Godoy wrote: > 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.
No problem, you are right. Anyway if you have some ideas put them on that 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? Yes, that's not a solution and wasn't meant to be, I'm just tossing around some ideas. > > 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. You should be able to make your own package structure. Dunno if this is a good solution anyway. > 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... I must admit that this does not seems quite immediate to me. If I understand this right, you also loose the main selling point of widgets since your are just adding some attributes to an already defined element (<input), a form will just look as before not as a single embedded widget. Yes, you gain the ability to give the template to your designer. Maybe, for now, the solution you can use is to cook up a code generation solution using the source() method provided by every widget. The ToolBox widgets browser will help once ready. Ciao Michele
