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
-~----------~----~----~----~------~----~------~--~---

Reply via email to