On 1/21/07, Ksenia <[EMAIL PROTECTED]> wrote:
> I am playing with Pylons several weeks now and it's been a big joy to
> use. Everything just fits together and I think because of Pylons I
> finally start to get what MVC is all about and see the advantage of
> clear separation.
> The piece that I am not sure where it should go, are widgets. The DRY
> is great, boring error handling is great, but: AFAIK the validation
> belons to the Model, but the UI belongs in the View, and the "gluing"
> of M with V belongs to Controller. So the widgets go right through all
> of the layers... Ok, I can live with that :) But than there is not
> anymore "only one way to do it". Where ends widget and starts the page
> template? Is it just form rendering? No, grid with records can also be
> a widget.... or should I just render it in the template file? Should I
> only make into a widget something that I want to reuse? I saw the
> thread about portlet-style site
> (http://groups.google.com/group/pylons-discuss/browse_frm/thread/2a52b3a490f5d211).
> Wow, I can even use subrequests. Than I don't need widgets at all - I
> can just collect all those /doc/view/123, /news/latest, /user/list,
> /user/view/myid into one page. But on the other hand, I can make all of
> them into child_widgets and create one big page widget to display
> them...
This always comes up with MVC: cases that don't clearly fit into any
of the categories. I have a search module in one (Quixote) project
that contains widgets, validators, searching code, etc, and I wanted
it all together in one module. I put it under 'controllers' at first,
then decided I wanted only true controllers there and moved it to the
top level alongside the 'controllers', 'model', and 'templates'
packages.
I haven't used ToscaWidgets, but assuming it's similar to Quixote
widgets, you can consider its rendering as a "default" rendering. In
other words, you don't have to use it if you have specialized layout
needs. In my organization, management gets these whims about how
exactly they want a widget to look like and where it should go, so I
make an initial template with semi-hardcoded widgets and give it to my
project manager to tweak. Widgets have five or six pieces of state
information:
- field name
- initial value (overridden by submitted value if we're
redisplaying the form)
- error message (empty if none)
- hint (e.g., "Hyphens are optional", "mm/dd/yyyy", "This is the
number on your mailing label")
- options (for select widgets)
- required?
With Quixote widgets (which I've thought about porting to Pylons), it
would look like this:
<td>My Label: ${w.render_content()} ${w.error} ${w.hint}</td>
.render_content takes care of all the other parts, rendering just the
<input> tag without the fancy <div>'s that .render would put around
it. I set the CSS class and any custom HTML attributes in the widget
constructor, which is a bit of intrusion from the view, but only a
little bit.
Not sure about non-form widgets or subrequests. I would probably use
reusable template snippets for the former (#def methods in Cheetah),
and handle the latter in the controller. If the controller chooses a
different template than usual, it looks to the user like a completely
different page, so it has the same effect as a subrequest. In Pylons
the controller chooses and calls the template directly, but TurboGears
has this bit of syntactic sugar:
# TG example, syntax may be wrong.
@expose("default_template")
def foo(self):
if NO_DATA:
return {"template": "no_data_template"}
return {"key1": [DATA_RECORDS], "key2", "value2"}
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---