bret at pectopah
Oct 22, 2009, 9:11 AM
Post #2 of 4
(127 views)
Permalink
|
|
Re: Better separation of presentation and logic?
[In reply to]
|
|
Hi Phillip,
In the last few sites I've worked on (Sportsnet 5.0, IFEX), I've been
really aggressive about that separation, and I've been loving it. So
nearly every template has a big <%init> block to do all its story
listings and so on, and the chunk at the top is basically just HTML with
a few friendly-looking tokens in it, like <% $deck %>.
This overlaps your first and second questions, but I've also used more
utility templates lately, sometimes for controller tasks, but also
sometimes for "view" ones.
For example, the IFEX site runs in three languages, and will eventually
be expanded to five. Each language gets its own OC, but they all share
one set of templates. So those templates are full of calls to little
display utilities, like this:
<h1><& /util/render_headline.mc &></h1>
(render_headline.mc figures out what language we're speaking at the
moment, and then goes and finds the headline for that language in the
relevant container)
On cover pages, this means lots of stuff like this:
% foreach (@articles){
<& /util/render_full_teaser.mc, the_story => $_ &>
% }
In <%cleanup> blocks, I've been using calls to a common utility to do
all the triggered publishing. So /util/index_publisher.mc does all the
cover lookups and publishes, for example.
(And /util/archive_index_publisher.mc gets triggered by cron every three
minutes or so, to take care of archives that aren't as time-sensitive as
the covers.)
As for the warnings and the "you can't do that here" stuff, so far I've
mostly left that in the individual element templates, because it's been
element specific. Stuff like "please attach a contributor to this
column" only applies to columns, for example.
Still, the index_publisher is a big centralized thing too, even though
it's full of cases for particular element types. So I guess I swing both
ways.
Greg and I had a good conversation about the MVC approach the other day.
I hope I'm not misquoting him here, but his general argument was that
strict lines separating M/V/C make more sense with desktop apps than
with web ones. In particular, V and C can overlap, and it's common to
have people disagreeing about whether a given chunk of function belongs
to C or V.
Maybe it's a weasel answer, but I think a general striving for tidiness
is better than trying to strictly build your Bricolage installation
around the MVC paradigm.
Yeah, that's a weasel answer.
OK then,
Bret
On Thu, 2009-10-22 at 12:37 -0200, Phillip Smith wrote:
> Hello,
>
> Bit of a philosophical question today. :-)
>
> I'm wondering about two things:
>
> 1. How far do folks go in abstracting "logic" out of element templates
> that non-developers might work on? For example, would it be considered
> a best practice to _always_ try to limit the use of inline <%perl>
> blocks and, instead, to put those blocks (most often used to retrieve
> story lists and so on, I've found) into the <%init> section? So,
> instead of:
>
> <%perl>
> my @list = $m->comp(
> '/util/story_list.mc',
> max => 6,
> ...
> );
> for my $item (@list) {
> ... iterate through items and print the necessary bits
> }
> </%perl>
>
> It would be better to populate the array of stories in the <%init>
> section and just use basic mason to present the data, e.g.:
>
> <ul>
> % foreach $item (@list) {
> <li><% $item->get_name %></li>
> % }
> </ul>
>
> 2. How does that theory apply to abstracting other "logic" into
> utility templates? I've noticed that a lot of the logic that happens
> in the <%cleanup> block appears to be repeated across many similar
> templates, e.g.:
>
> # Just bail unless we're publishing or the current story has been
> published before
> return unless $burner->get_mode == PUBLISH_MODE
> && $story->get_publish_status;
>
> Would it be a good idea to move this into a /util/cleanup_generic.mc
> utility template for ease-of-maintenance? And, similarly, I'm finding
> myself more-and-more conscious of providing the Bricolage user/editor
> with helpful hints if they've not entered data correctly-- this often
> ends up in the <%init> and contains stuff like:
>
> $burner->throw_error("There is no contributor associated with this
> story! You can't have a story without a contributor. Please add a
> contributor.")
> unless scalar @contribs > 0;
> $burner->throw_error("Blog posts can only be created under the /blog/
> category. Please ensure this story is put in the right category. It
> appears to be in: $cat_url")
> unless $cat_url =~ /\/blog\//;
>
> Would it be a best practice to move this type of error checking into a
> utility template, which it could be managed from one file vs. in each
> individual template?
>
> And I guess the final question is: To what extent do people try to
> follow MVC-ish ideas in Bricolage? E.g., is it worth really thinking
> of the element templates as Views, utility templates as Controllers,
> and Bricolage as the Model (or something like that), where the utility
> templates handle most / all of the preparation of the data for a
> specific views, and the element templates simply present the data
> provided? (Am I off on a tangent here?)
>
> Thoughts appreciated.
>
> Phillip.
>
> --
> Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
> www.communitybandwidth.ca // www.phillipadsmith.com
>
>
>
>
>
>
>
>
--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret[at]pectopah.com
www.pectopah.com
|
