Jorge, thank you very much for your thoughts, which I answer inline:
On Jan 29, 10:34 pm, Jorge Godoy <[EMAIL PROTECTED]> wrote:
> I didn't like this approach and left some of my comments on the website you
> posted.
> What I wrote there are the things that annoyed me the most at first sight.
Here is my answer to that:
1) No, I believe "py:replace" can be used with Formetto:
<span py:replace='f.Text(id="name", label="Title", size=58,
required=True)'>
<input type="text" id="name" name="name" maxlength="80"
class="textfield" size="58" /> *
</span>
2) Widgets only render as a <TR> when you provide a "label" attribute.
This is why custom positioning of the widgets is so easy with
Formetto. Don't want a table layout? Just don't use the "label"
attribute.
3) I shall follow PEP 8 starting today, thanks for that tip.
> I am also not please in having the validation part moved to the model instead
> of the controller. This would require one to actually have more code on the
> model and would defeat some of the introspection that ORM tools offer,
> demanding the one write code for validating things instead of letting the ORM
> introspect the information from the database.
More code in the model is certainly better than more code in the
controller as long as it is expressing model constraints (universal
truths that get reused). For instance, e-mail syntax validation should
be in the model. This way, when I type "tg-admin shell" and make
changes to the database, these changes are validated too.
Business rules should be in the model! Only glue code should be in the
controller!
What you say about defeating introspection isn't true: If you like
SQLAlchemy to autoload your Postgres database schema, it generates the
Table objects so you don't have to type them. But you still can and
should write the validating properties in the ORM classes, then call
the mapper function to set the synonyms.
So properties do not defeat introspection. If it autoloads a Unicode
field called Email with some length, it still hasn't loaded any e-mail
validation rules. These have to be added anyway, and the right place
is the model.
> You are also reducing the reusability of the code when you force a specific
> approach like you did. One can render widgets for several templates -- all
> that follow the Buffet API -- today, but has to use a XML templating system
> on your approach.
Formetto was made to scratch my itch and currently it depends on
Genshi. But this can be easily remedied.
Otherwise I don't see how Formetto is limited to XML templating
systems. I shall study Buffet in order to find out what you are
saying. Supporting an API should be an easy addition to Formetto.
> Also, as a counter argument of your MVC separation, you are inserting logic on
> the view and this should be either on the M or C parts, but not on the V.
> For example, I believe there is too much on your "authors" field.
Who said the view cannot contain any logic? Kid and Genshi support
Python code inside templates and that is a good thing. The original
MVC (from Smalltalk) was all code -- there was no concept of
templates.
Anyhow, if you so prefer, you can change the authors field from this:
${ f.Select(id="authors", label="Blog authors", required=True,
multiple=True, options = [(t.id, t.display_name, t in o.authors) for t
in editors]) }
...to this:
${ f.Select(id="authors", label="Blog authors", required=True,
multiple=True, options=shownAuthors) }
...and just move that list comprehension to the controller.
I think Formetto still looks good as these doubts start fading away...
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
