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