On 6/4/02 12:32 PM, Perrin Harkins wrote:
> The thing that worries me about a widget approach is that I would have
> the same problem I had with CGI.pm's HTML widgets way back: the
> designers can't change the HTML easilly. Getting perl developers out of
> the HTML business is my main reason for using templating.
My approach uses an intentionally limited subset of Mason as my "templating"
language. It looks something like this:
* Model: Regular Perl classes and objects.
* Controller: Regular Perl classes and objects, trivially wrapped in Mason
components to control access location (i.e. URL), object caching, and so on.
* View: Mason components that receive "widget"-like objects as well as
simple strings and other params.
To try to solve the "designers don't know Perl" problem, I just constrain
the API usage of the widget objects for designers. Example:
<tr>
<td><% $form->field('name')->html_label %></td>
<td><% $form->field('name')->html_field %></td>
</tr>
As concerned as I initially was by this syntax, the fact is that 99% of all
view objects have a series of exactly the same calls. Designers have no
clue what they do internally, but the fact is that the only part that really
changes is the field name. And there are very few, simple method names to
know: html_field, html_label, html_error, etc. In the simplest case,
there's even a few places where this works:
<% $form->field('name')->html %>
And handles the label (if any), field, and field-tied error message all in
one block. I guess the moral is that comfort != understanding. Designers
can get comfortable with even "ugly" syntax like the above very quickly
since it is repeated so often.
Yes, this means that all the nuts and bolts of what gets printed by those
calls is handled by the controller object (which produces the widgets,
populating them according to the data form the model objects), and therefore
the programmer. But IMO this is as it should be. The programmer flags
which form fields are "required", what HTML surrounds "error messages"
(usually just <span class="error">) and so on. The designers change the
contents of the style sheets, make the graphics, and arrange the widgets on
the page.
And in a pinch, the programmer does have the full range of Mason features
available. IMO, it's not much harder for designers to learn some small
subset of a larger syntax (like Mason/Perl-Widget-API) than it is for them
to learn an equal size subset (or entirety) of a "little language" like
template toolkit.
-John
