Hi Michele, Thanks for taking the time to write this. I know how long it can take to write something in a non-native language.
On 11/4/05, Michele Cella <[EMAIL PROTECTED]> wrote: > I've just found this link to a post by the Ruby on Rails creator: > > http://www.loudthinking.com/arc/000533.html What he's saying here is exactly the way I view the quickstart feature as well. It gives you something to hold on to and build from and makes it clearer where to put things. Forms are different (see below). > > There are some interesting point he makes that made me think: > > 1) Structure generation done right (as RoR does) it's quite useful not > only as a quickstart but (probably) even more to support the > development process step by step by ensuring you are doing the right > thing without wasting time (even if you are already expert). > Quoting the post: "Structure generation drastically lowers the learning > curve by teaching the conventions through code instead of > documentation." Agreed. > 2) Form generation from the controller it's pretty nice, but doesn't > this break the MVC paradigm? > For example, suppose that I'm working with a designer and I want to > work only on the Model and Controller side, now I've got this template > that contains: > > ${form.insert(action=save)} > > how can my designer customize it? I can give him the TableForm.template > output and let him customize that, but: > - He won't be able to work with the kid template and take advantage of > the ability to completely view it in its browser (one selling point of > Kid) > - I will need to integrate its work (on the View side) inside of my > controllers (the C side) by subclassing the TableForm class and > overriding the template with the customized one (more unwanted work for > me) > - Probably I will need to do the same for some of the widgets... There's a balancing act that's playing out here. This is the challenge in API design, and I think the path I'm heading down is a good one, but it's great to hash it out in a discussion like this. You're correct that doing form generation does, to an extent, break the ability to just hand the designer a Kid template and say "make this look nice". But, consider the benefits: 1) as you mention, changes to the model can automatically be reflected in the view 2) widgets ensure consistent behavior and appearance throughout your application. every time you need a date picker, it will look the same, without cut and paste 3) easily drop in new functionality created by others - widgets are just Python classes and can be distributed like any other module Also, consider some things that make it not-so-bad to use widgets: 1) You can still do customization through CSS alone. 2) Widget templates are Kid templates, so a widget can be conveniently created by a designer. It should be possible to include the JS and CSS references in the widget template and have that automatically pull into the widget class (which is a plus to doing templates in XHTML - they're easily parsable). Finally, I am really hoping to make it possible to generate a template file that is functionally equivalent but fully customizable. > With code generation I will only need to give him the generated Kid > template. > > Yes, if you change something on your model you will need to regenerate > the template, but how does this compare to the customization and > adaptation work needed by the other solution? with the View side > appearing on my Controller side? And what about the learning curve > needed to teach yourself the right way to do the customization work > (subclassing vs plain editing of HTML). It's not quite as simple as "regenerat[ing] the template". Many templates may change. You can either regenerate them all and have the designer have to redo all of the customizations or you can manually update all of them to add the new fields. One other thing: you don't even need to subclass (though you will need to know what goes in to the template). If you want a text field that looks different, you can just do: widgets.TextField("name", template="myproject.templates.textfield") > Maybe the simplest solution it's also the right one? "Is simplicity best, or simply the easiest?" (Martin Gore) I'm not looking to do something maniacally complicated... but, I think that the advantages to the form generation approach with widgets, plus the relative ease of customization we can do for widgets makes it a good way to go. Only experience in use will tell us for sure. I do think that code generation will be an option as well, but that's the remaining area of widget building that i haven't fully explored yet to catch the pitfalls (and I see the pitfalls looming). > I don't want to start a flame, I'm only interest on hearing others > people opinions, it's important to get it right and make it easy if TG > wants to succeed. We haven't had a flame war yet on this list (w00t), and your nicely written message is not likely to incite one. I agree that this is a vital topic and it's worth getting right. > Please excuse me for my bad english, it's not my native language and I > took me a while to write this down, also excuse me if I will not reply > often but I'm preparing some important exams :-( Good luck with the exams! Kevin
