Kevin Dangoor wrote: > Hi Michele, Hi Kevin,
> > Thanks for taking the time to write this. I know how long it can take > to write something in a non-native language. Thank you for giving me your attention. > > 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). Agreed. See below for an idea regarding forms, widgets and quickstart. > > [...] > > > 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. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It's also great to see how much your are open to hear and discuss other people opinions, this also explain the impressive traffic statistics of this google group and the friendly and growing community. > 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 Big point IMO > 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 Another great thing I haven't tough about (shame on me). Consistent... I love this word. > 3) easily drop in new functionality created by others - widgets are > just Python classes and can be distributed like any other module Again that's great. See below for my idea regarding this. > > 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). See below. > > Finally, I am really hoping to make it possible to generate a template > file that is functionally equivalent but fully customizable. Great to hear that. > > > 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. Indeed you are right again. > > 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") This is a feature I didn't notice, and I think that's a quite important feature, If i got it right you are directly referencing a Kid template, right? Now I will not say again "see below" but I will describe my ideal scenario: Since you can reference a widget template this way, I think that maybe you should not hardcode it in the source code like you're doing ATM. So, regarding quickstart, customization by designers and consistency... What about extending the quickstart command so that it creates a new widgets directory under the application template folder: apppackage.templates.widgets |__ form.kid |__ textfield.kid |__ colorpicker.kid by default this folder will just contain the TG implementation of widgets, so for instance form.kid will look like this: <form xmlns:py="http://purl.org/kid/ns#"; name="${widget.name}" action="${action}" method="${getattr(self, 'method', 'post')}"> <table border="0"> <tr py:for="widget in widgets"> <td> <span py:if="widget.label and widget.labeltext" py:replace="widget.label.insert(widget.labeltext)"/> <span py:if="not widget.label or not widget.labeltext" py:replace="'&#160;'"/> </td> <td>${widget.insert(getattr(self, widget.name, None), input_values, widget_error.get(widget.name, None))}</td> </tr> <tr> <td> </td> <td>${submit.insert(submittext)}</td> </tr> </table> </form> Now, I think you can just rename TableForm to be Form and (dunno if it's possible) use as a reference the kid template of the application (instead of hardcoding it on as a class attribute, again Controller and View separation). Designers will now be able to just dive into the application widgets folder and start customizing things. As you said this will ensure consistency without copy/paste. To make this work there should be a very good and simple plugin system for widgets so that you can easily deploy them on your TG app (with their templates, javascript and css). That's why I think quickstart should just copy on the application template folder all widget provided by TG itself, this is quite important to give designer an easy way to customize without the need of copy/paste the base template that TG uses by default from some others (obscure) locations. Hope I've been able to express my idea. :D > > > Maybe the simplest solution it's also the right one? > > "Is simplicity best, or simply the easiest?" (Martin Gore) Nice citation. :D > > 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. You have convinced me. > > 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). Probably this is also related to what I've outlined before. > > > 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! Thank you! I suffer TG dependency since a while, so It's quite hard to study, but now I have to go! :-) > > Kevin Ciao Michele
