Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Bricolage: users

Things you wish you'd done in your templates

 

 

First page Previous page 1 2 Next page Last page  View All Bricolage users RSS feed   Index | Next | Previous | View Threaded


rolfm at denison

Oct 7, 2008, 1:01 PM

Post #1 of 28 (8519 views)
Permalink
Things you wish you'd done in your templates

In the near future I'm going to be rewriting and revising our
templates to make them cleaner, more efficient, and easier to
maintain. We're also refactoring our markup with more a consistent
class/id structure and a reworking how we handle styles.

So the question I have for the list is, what are some things you wish
you'd done in your templates? Or, if you had the opportunity to start
all over again, how would you do things differently?

-Matt


bret at pectopah

Oct 7, 2008, 1:08 PM

Post #2 of 28 (8353 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

Ooh! I've got one!

After six-or-so Bricolage sites, I've come to love <%init> blocks more
and more. If you use them to get most of the line-noisy perl out of the
way and assign values to friendly-looking variables like $text and
$sidebar, the resulting template is vastly easier to edit for
aesthetics, because it still looks like HTML.

Also, you can stick the <%init> block at the bottom, so what you see
when you start editing looks more reasonably like the template's output.

Anyway, that's one thing.


Cheers,

Bret



On Tue, 2008-10-07 at 16:01 -0400, Matt Rolf wrote:
> In the near future I'm going to be rewriting and revising our
> templates to make them cleaner, more efficient, and easier to
> maintain. We're also refactoring our markup with more a consistent
> class/id structure and a reworking how we handle styles.
>
> So the question I have for the list is, what are some things you wish
> you'd done in your templates? Or, if you had the opportunity to start
> all over again, how would you do things differently?
>
> -Matt
>
--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret [at] pectopah
www.pectopah.com


simonw at digitalcraftsmen

Oct 7, 2008, 1:16 PM

Post #3 of 28 (8376 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

Matt Rolf wrote:
> So the question I have for the list is, what are some things you wish
> you'd done in your templates? Or, if you had the opportunity to start
> all over again, how would you do things differently?

I wish we made better use of utility templates to hide some of the
complexity. We usually end up with large amounts of validation and other
logic that should, really, be in the business logic not in the templates.

But since we don't have pluggable validation yet, we have to put it in
the templates.

If we made better use of utility templates to hide that validation we
could at least make the main templates more presentational than they are
now and therefore easier to give to a designer/html wrangler to work with.

S.

--
Digital Craftsmen Ltd
Exmouth House, 3 Pine Street, London. EC1R 0JH
t 020 7183 1410 f 020 7099 5140 m 07951 758698
w http://www.digitalcraftsmen.net/


chris.schults at pccsea

Oct 7, 2008, 1:47 PM

Post #4 of 28 (8358 views)
Permalink
RE: Things you wish you'd done in your templates [In reply to]

> After six-or-so Bricolage sites, I've come to love <%init> blocks more
> and more. If you use them to get most of the line-noisy perl out of
the
> way and assign values to friendly-looking variables like $text and
> $sidebar, the resulting template is vastly easier to edit for
> aesthetics, because it still looks like HTML.
>
> Also, you can stick the <%init> block at the bottom, so what you see
> when you start editing looks more reasonably like the template's
> output.

I second what Bret said. When I moved from working with Bricolage at
Grist to PCC Natural Markets, I learned about and started using <%init>
blocks, which made a big difference.

And as Simon wrote, better use of utility templates. I wish I had spent
more time thinking about how I'd use them.

Chris


rolfm at denison

Oct 7, 2008, 1:54 PM

Post #5 of 28 (8368 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Oct 7, 2008, at 4:47 PM, Schults, Chris wrote:

>> After six-or-so Bricolage sites, I've come to love <%init> blocks
>> more
>> and more. If you use them to get most of the line-noisy perl out of
> the
>> way and assign values to friendly-looking variables like $text and
>> $sidebar, the resulting template is vastly easier to edit for
>> aesthetics, because it still looks like HTML.
>>
>> Also, you can stick the <%init> block at the bottom, so what you see
>> when you start editing looks more reasonably like the template's
>> output.
>
> I second what Bret said. When I moved from working with Bricolage at
> Grist to PCC Natural Markets, I learned about and started using <
> %init>
> blocks, which made a big difference.
>
> And as Simon wrote, better use of utility templates. I wish I had
> spent
> more time thinking about how I'd use them.

All these responses have been good! Using more <%init> blocks is not
something I'd thought of.

And utility templates = friend.


phillip at communitybandwidth

Oct 7, 2008, 3:02 PM

Post #6 of 28 (8360 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On 7-Oct-08, at 4:54 PM, Matt Rolf wrote:

>
> On Oct 7, 2008, at 4:47 PM, Schults, Chris wrote:
>
>>> After six-or-so Bricolage sites, I've come to love <%init> blocks
>>> more
>>> and more. If you use them to get most of the line-noisy perl out of
>> the
>>> way and assign values to friendly-looking variables like $text and
>>> $sidebar, the resulting template is vastly easier to edit for
>>> aesthetics, because it still looks like HTML.
>>>
>>> Also, you can stick the <%init> block at the bottom, so what you see
>>> when you start editing looks more reasonably like the template's
>>> output.
>>
>> I second what Bret said. When I moved from working with Bricolage at
>> Grist to PCC Natural Markets, I learned about and started using <
>> %init>
>> blocks, which made a big difference.
>>
>> And as Simon wrote, better use of utility templates. I wish I had
>> spent
>> more time thinking about how I'd use them.
>
> All these responses have been good! Using more <%init> blocks is not
> something I'd thought of.
>
> And utility templates = friend.



Great question / thread! :-)

I recently engaged in the exercise of standardizing my templates too,
here are the tricks I came up with:

+ Per the notes above, put the <%init> block immediately following the
HTML, and use the <%init> block to set as many useful, and easy-to-
ready, variables as possible.

+ I then use several <%method> blocks to provide some other useful
magic that is passed UP the chain into the autohandler, e.g.:

<%method .head>
... for stuff that I want to inject into the <head> tag, e.g.: special
javascript, etc.
</%method>

<%method .body></%method> for attributes that I want to add to the
<body> tag, e.g.:

<%method .body>onload="load()" onunload="GUnload()"</%method> for a
page that contains a Google map, etc.

<%method.rss></%method> -- per David's examples of how to manipulate
the RSS feed link, etc.

+ Also, I usually just include a <%cleanup></%cleanup> block in my
default template to remind myself to do any necessary clean-up tasks,
i.e., publish another, etc.

+ And, finally, I also include a <%doc> section to provide any
necessary commentary on the functionality of that specific template

I find that having these all there from the get-go (in a default
template that I start with) helps me remember to do all the necessary
work that makes passing off the project, or remembering the details
myself later, much easier.

And a couple of CSS tricks that I rely on are putting an ID and
classes on the body tag, which allows styling at a section-by-section,
or page-by-page level.

Brad Harder put together a helpful template (included below) that sets
the class of the body to be a category list, e.g.: <body class="parent
child child child">, which provides a great set of hooks for section
and sub-section specific styles. And I usually set the ID to be the
story slug, or story "ID" in Bricolage, which allows very fine-grained
control (if necessary), e.g.:

body#ID h1 { style for h1 of a story with this body ID} or body.CLASS
h1 {style for h1 of stories in category X}

I use it like so (from the autohandler):

<%init>
my $cat_uri = $burner->get_cat->get_uri;
my $bodyclass = $m->comp("/util/mk_class.mc");
$bodyclass = "front" if $cat_uri eq '/';
</%init>

And the body tag appears like:

<body <& SELF:.body &> id="<% $story->get_slug || $bodyclass %>"
class="<% $bodyclass %>">

The template follows:

<%doc>

=head1 NAME

mk_class.mc - Outputs a class tag based on the current directory tree.

=head1 SYNOPSIS

my $bodyclass = $m->comp("/util/mk_class.mc");

<% $bodyclass %>

=head1 DESCRIPTION

Outputs a list of path fragments based on the current directory path,
e.g.: /dir1/dir2/dir3/ would produce dir1 dir2 dir3.

This can be used in the body tag to assist with stylesheet-based
layout on a per-section basis.

=head1 AUTHOR

Brad Harder <brad [at] methodlogic>

=head1 COPYRIGHT AND LICENSE

Copyright 2008 by Brad Harder and Method Digital Logic

This library is free software; you can redistribute it and/or modify
it under
the terms of the GNU Lesser General Public License as published by the
Free
Software Foundation, version 2.1 of the License.

This library is distributed in the hope that it will be useful, but
WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS
FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License
for more
details.

You should have received a copy of the GNU Lesser General Public
License along
with this library (see the the license.txt file); if not, write to the
Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307
USA.

=cut

</%doc>

<%perl>
my $cat = $burner->get_cat();

my $return_class_string=$cat->get_uri();
$return_class_string=~tr/A-Z/a-z/;
$return_class_string=~s/\// /g;
$return_class_string=~s/^ *//;
$return_class_string=~s/ *$//;

return($return_class_string);
</%perl>


Hope that helps, and hope someone is documenting all this on the
Wiki! ;-)

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.communitybandwidth.ca


john.durkin at gmail

Oct 7, 2008, 3:24 PM

Post #7 of 28 (8379 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

Maybe this is super-obvious - but it wasn't happening in the first bric
system that I inherited... I like to use templates to produce files that I
include on the page with php (like a header.inc file, for instance), so that
when you need to change something sitewide you don't have to republish every
single story... just republish the story that controls the include file. Of
course sometimes a sitewide republish can't be helped... but when you can do
so, using include files can save you a ton of time and headache. You can
also publish a story that controls an include file with soap from the
server's crontab, then you can create a frequently updated module that lives
on the page that doesn't load your production webserver down with a db query
every pageload. Instead, your template can query the db at publish time.
This is good for things like 'most emailed stories!'...

jd




On Tue, Oct 7, 2008 at 3:02 PM, Phillip Smith <phillip [at] communitybandwidth
> wrote:

>
> On 7-Oct-08, at 4:54 PM, Matt Rolf wrote:
>
>
>> On Oct 7, 2008, at 4:47 PM, Schults, Chris wrote:
>>
>> After six-or-so Bricolage sites, I've come to love <%init> blocks more
>>>> and more. If you use them to get most of the line-noisy perl out of
>>>>
>>> the
>>>
>>>> way and assign values to friendly-looking variables like $text and
>>>> $sidebar, the resulting template is vastly easier to edit for
>>>> aesthetics, because it still looks like HTML.
>>>>
>>>> Also, you can stick the <%init> block at the bottom, so what you see
>>>> when you start editing looks more reasonably like the template's
>>>> output.
>>>>
>>>
>>> I second what Bret said. When I moved from working with Bricolage at
>>> Grist to PCC Natural Markets, I learned about and started using <%init>
>>> blocks, which made a big difference.
>>>
>>> And as Simon wrote, better use of utility templates. I wish I had spent
>>> more time thinking about how I'd use them.
>>>
>>
>> All these responses have been good! Using more <%init> blocks is not
>> something I'd thought of.
>>
>> And utility templates = friend.
>>
>
>
>
> Great question / thread! :-)
>
> I recently engaged in the exercise of standardizing my templates too, here
> are the tricks I came up with:
>
> + Per the notes above, put the <%init> block immediately following the
> HTML, and use the <%init> block to set as many useful, and easy-to-ready,
> variables as possible.
>
> + I then use several <%method> blocks to provide some other useful magic
> that is passed UP the chain into the autohandler, e.g.:
>
> <%method .head>
> ... for stuff that I want to inject into the <head> tag, e.g.: special
> javascript, etc.
> </%method>
>
> <%method .body></%method> for attributes that I want to add to the <body>
> tag, e.g.:
>
> <%method .body>onload="load()" onunload="GUnload()"</%method> for a page
> that contains a Google map, etc.
>
> <%method.rss></%method> -- per David's examples of how to manipulate the
> RSS feed link, etc.
>
> + Also, I usually just include a <%cleanup></%cleanup> block in my default
> template to remind myself to do any necessary clean-up tasks, i.e., publish
> another, etc.
>
> + And, finally, I also include a <%doc> section to provide any necessary
> commentary on the functionality of that specific template
>
> I find that having these all there from the get-go (in a default template
> that I start with) helps me remember to do all the necessary work that makes
> passing off the project, or remembering the details myself later, much
> easier.
>
> And a couple of CSS tricks that I rely on are putting an ID and classes on
> the body tag, which allows styling at a section-by-section, or page-by-page
> level.
>
> Brad Harder put together a helpful template (included below) that sets the
> class of the body to be a category list, e.g.: <body class="parent child
> child child">, which provides a great set of hooks for section and
> sub-section specific styles. And I usually set the ID to be the story slug,
> or story "ID" in Bricolage, which allows very fine-grained control (if
> necessary), e.g.:
>
> body#ID h1 { style for h1 of a story with this body ID} or body.CLASS h1
> {style for h1 of stories in category X}
>
> I use it like so (from the autohandler):
>
> <%init>
> my $cat_uri = $burner->get_cat->get_uri;
> my $bodyclass = $m->comp("/util/mk_class.mc");
> $bodyclass = "front" if $cat_uri eq '/';
> </%init>
>
> And the body tag appears like:
>
> <body <& SELF:.body &> id="<% $story->get_slug || $bodyclass %>" class="<%
> $bodyclass %>">
>
> The template follows:
>
> <%doc>
>
> =head1 NAME
>
> mk_class.mc - Outputs a class tag based on the current directory tree.
>
> =head1 SYNOPSIS
>
> my $bodyclass = $m->comp("/util/mk_class.mc");
>
> <% $bodyclass %>
>
> =head1 DESCRIPTION
>
> Outputs a list of path fragments based on the current directory path, e.g.:
> /dir1/dir2/dir3/ would produce dir1 dir2 dir3.
>
> This can be used in the body tag to assist with stylesheet-based layout on
> a per-section basis.
>
> =head1 AUTHOR
>
> Brad Harder <brad [at] methodlogic>
>
> =head1 COPYRIGHT AND LICENSE
>
> Copyright 2008 by Brad Harder and Method Digital Logic
>
> This library is free software; you can redistribute it and/or modify it
> under
> the terms of the GNU Lesser General Public License as published by the Free
> Software Foundation, version 2.1 of the License.
>
> This library is distributed in the hope that it will be useful, but WITHOUT
> ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> FITNESS
> FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for
> more
> details.
>
> You should have received a copy of the GNU Lesser General Public License
> along
> with this library (see the the license.txt file); if not, write to the Free
> Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> 02111-1307
> USA.
>
> =cut
>
> </%doc>
>
> <%perl>
> my $cat = $burner->get_cat();
>
> my $return_class_string=$cat->get_uri();
> $return_class_string=~tr/A-Z/a-z/;
> $return_class_string=~s/\// /g;
> $return_class_string=~s/^ *//;
> $return_class_string=~s/ *$//;
>
> return($return_class_string);
> </%perl>
>
>
> Hope that helps, and hope someone is documenting all this on the Wiki! ;-)
>
> --
> Phillip Smith,
> Simplifier of Technology
> Community Bandwidth
> http://www.communitybandwidth.ca
>
>
>
>


david at kineticode

Oct 7, 2008, 9:08 PM

Post #8 of 28 (8366 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Oct 7, 2008, at 15:02, Phillip Smith wrote:

> I find that having these all there from the get-go (in a default
> template that I start with) helps me remember to do all the
> necessary work that makes passing off the project, or remembering
> the details myself later, much easier.

Hrm. I wonder if it'd be useful for new templates to be created like
this:

<%once>;
# Stuff to run when template compiles.
</%once>
<%args>
# Arguments passed to the template.
</%args>
<%init>;
# Set up variables.
</%init>
</%cleanup>
# Do any stuff when you're finished.
</%cleanup>
<%filter>
# Change stuff to the output before you output it.
</%filter>
<%doc>

=head1 Name

My Template

=head1 Description

What does this template do, and why?

=cut
</%doc>

Thoughts?

> The template follows:

Nice!

> <%perl>
> my $cat = $burner->get_cat();
>
> my $return_class_string=$cat->get_uri();
> $return_class_string=~tr/A-Z/a-z/;
> $return_class_string=~s/\// /g;
> $return_class_string=~s/^ *//;
> $return_class_string=~s/ *$//;
>

I'd do this (one liner equiv to the above, since get_uri never returns
a string with leading or trailing space):

return join ' ', split /[/]/, lc $cat->get_uri;

Best,

David


david at kineticode

Oct 7, 2008, 9:10 PM

Post #9 of 28 (8361 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Oct 7, 2008, at 15:24, John Durkin wrote:

> Maybe this is super-obvious - but it wasn't happening in the first
> bric
> system that I inherited... I like to use templates to produce files
> that I
> include on the page with php (like a header.inc file, for instance),
> so that
> when you need to change something sitewide you don't have to
> republish every
> single story... just republish the story that controls the include
> file.

No, not super obvious. This should be said over and over again. You
can also control such includes as media documents, as appropriate.

> Of
> course sometimes a sitewide republish can't be helped... but when
> you can do
> so, using include files can save you a ton of time and headache.
> You can
> also publish a story that controls an include file with soap from the
> server's crontab, then you can create a frequently updated module
> that lives
> on the page that doesn't load your production webserver down with a
> db query
> every pageload. Instead, your template can query the db at publish
> time.
> This is good for things like 'most emailed stories!'...

+1

Best,

David


lannings at who

Oct 8, 2008, 1:38 AM

Post #10 of 28 (8365 views)
Permalink
RE: Things you wish you'd done in your templates [In reply to]

On Tue, 7 Oct 2008, Schults, Chris wrote:
>> After six-or-so Bricolage sites, I've come to love <%init> blocks more
>> and more. [!]
>> Also, you can stick the <%init> block at the bottom, so what you see
>> when you start editing looks more reasonably like the template's
>> output.
>
> I second what Bret said. When I moved from working with Bricolage at
> Grist to PCC Natural Markets, I learned about and started using <%init>
> blocks, which made a big difference.
>
> And as Simon wrote, better use of utility templates. I wish I had spent
> more time thinking about how I'd use them.

Although I'd tend to use utility templates too,
I don't like them very much in principle;
see http://www.masonhq.com/?ModulesInsteadOfPerlComponents .
I'd prefer that kind of thing to be done
in a Perl module, then you just "use Whatever qw(anyway)"
in a <%once> block (and put in PERL_LOADER in bricolage.conf).
(I'm not sure that <%once> blocks
and <%init> blocks are actually different
in Bricolage.) It's a bit uglier putting it
in a component, plus it's less efficient
and less test-friendly.
Another ugly thing I end up doing is putting
sub definitions in <%once> blocks.
Those should also be in a separate module.
The problem with putting things in Perl modules
though is you end up having to restart the server
or something, whereas with utility templates
it's just a matter of calling another component.
It's the wrong kind of laziness, though, IMHO.


david at kineticode

Oct 8, 2008, 8:51 AM

Post #11 of 28 (8351 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Oct 8, 2008, at 01:38, Scott Lanning wrote:

> Although I'd tend to use utility templates too,
> I don't like them very much in principle;
> see http://www.masonhq.com/?ModulesInsteadOfPerlComponents .
> I'd prefer that kind of thing to be done
> in a Perl module, then you just "use Whatever qw(anyway)"
> in a <%once> block (and put in PERL_LOADER in bricolage.conf).
> (I'm not sure that <%once> blocks
> and <%init> blocks are actually different
> in Bricolage.)

If you burn multiple pages in a story, %once will only execute before
the first page, while %init will execute before every page.

> It's a bit uglier putting it
> in a component, plus it's less efficient
> and less test-friendly.

I tend to agree, but to allow users to manage everything through
Bricolage, esp. those who know nothing about Perl modules, utility
templates are better.

> Another ugly thing I end up doing is putting
> sub definitions in <%once> blocks.
> Those should also be in a separate module.

Never put sub defs in %once blocks. Do put lexical subs in %once blocks:

<%once>
my $sub = sub { ... };
</%once>
<%perl>
$sub->();
</%perl>

> The problem with putting things in Perl modules
> though is you end up having to restart the server
> or something, whereas with utility templates
> it's just a matter of calling another component.
> It's the wrong kind of laziness, though, IMHO.

It depends on who's using them.

Best,

David


bharder at methodlogic

Oct 8, 2008, 8:00 PM

Post #12 of 28 (8347 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Tue, Oct 07, 2008 at 06:02:44PM -0400, Phillip Smith wrote:
>
> On 7-Oct-08, at 4:54 PM, Matt Rolf wrote:
>
> >
> >On Oct 7, 2008, at 4:47 PM, Schults, Chris wrote:
> >
> >>>After six-or-so Bricolage sites, I've come to love <%init> blocks
> >>>more
> >>>and more. If you use them to get most of the line-noisy perl out of
> >>the
> >>>way and assign values to friendly-looking variables like $text and
> >>>$sidebar, the resulting template is vastly easier to edit for
> >>>aesthetics, because it still looks like HTML.
> >>>
> >>>Also, you can stick the <%init> block at the bottom, so what you see
> >>>when you start editing looks more reasonably like the template's
> >>>output.
> >>
> >>I second what Bret said. When I moved from working with Bricolage at
> >>Grist to PCC Natural Markets, I learned about and started using <
> >>%init>
> >>blocks, which made a big difference.
> >>
> >>And as Simon wrote, better use of utility templates. I wish I had
> >>spent
> >>more time thinking about how I'd use them.
> >
> >All these responses have been good! Using more <%init> blocks is not
> >something I'd thought of.
> >
> >And utility templates = friend.
>
>
>
> Great question / thread! :-)
>
> I recently engaged in the exercise of standardizing my templates too,
> here are the tricks I came up with:
>
> + Per the notes above, put the <%init> block immediately following the
> HTML, and use the <%init> block to set as many useful, and easy-to-
> ready, variables as possible.
>
> + I then use several <%method> blocks to provide some other useful
> magic that is passed UP the chain into the autohandler, e.g.:
>
> <%method .head>
> ... for stuff that I want to inject into the <head> tag, e.g.: special
> javascript, etc.
> </%method>
>
> <%method .body></%method> for attributes that I want to add to the
> <body> tag, e.g.:
>
> <%method .body>onload="load()" onunload="GUnload()"</%method> for a
> page that contains a Google map, etc.
>
> <%method.rss></%method> -- per David's examples of how to manipulate
> the RSS feed link, etc.
>
> + Also, I usually just include a <%cleanup></%cleanup> block in my
> default template to remind myself to do any necessary clean-up tasks,
> i.e., publish another, etc.
>
> + And, finally, I also include a <%doc> section to provide any
> necessary commentary on the functionality of that specific template
>
> I find that having these all there from the get-go (in a default
> template that I start with) helps me remember to do all the necessary
> work that makes passing off the project, or remembering the details
> myself later, much easier.
>
> And a couple of CSS tricks that I rely on are putting an ID and
> classes on the body tag, which allows styling at a section-by-section,
> or page-by-page level.
>
> Brad Harder put together a helpful template (included below) that sets
> the class of the body to be a category list, e.g.: <body class="parent
> child child child">, which provides a great set of hooks for section
> and sub-section specific styles. And I usually set the ID to be the
> story slug, or story "ID" in Bricolage, which allows very fine-grained
> control (if necessary), e.g.:
>
> body#ID h1 { style for h1 of a story with this body ID} or body.CLASS
> h1 {style for h1 of stories in category X}
>
> I use it like so (from the autohandler):
>
> <%init>
> my $cat_uri = $burner->get_cat->get_uri;
> my $bodyclass = $m->comp("/util/mk_class.mc");
> $bodyclass = "front" if $cat_uri eq '/';
> </%init>
>
> And the body tag appears like:
>
> <body <& SELF:.body &> id="<% $story->get_slug || $bodyclass %>"
> class="<% $bodyclass %>">
>
> The template follows:
>
> <%doc>
>
> =head1 NAME
>
> mk_class.mc - Outputs a class tag based on the current directory tree.
>
> =head1 SYNOPSIS
>
> my $bodyclass = $m->comp("/util/mk_class.mc");
>
> <% $bodyclass %>
>
> =head1 DESCRIPTION
>
> Outputs a list of path fragments based on the current directory path,
> e.g.: /dir1/dir2/dir3/ would produce dir1 dir2 dir3.
>
> This can be used in the body tag to assist with stylesheet-based
> layout on a per-section basis.
>
> =head1 AUTHOR
>
> Brad Harder <brad [at] methodlogic>

Correction: bharder [at] methodlogic

> =head1 COPYRIGHT AND LICENSE
>
> Copyright 2008 by Brad Harder and Method Digital Logic
>
> This library is free software; you can redistribute it and/or modify
> it under
> the terms of the GNU Lesser General Public License as published by the
> Free
> Software Foundation, version 2.1 of the License.
>
> This library is distributed in the hope that it will be useful, but
> WITHOUT
> ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> FITNESS
> FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License
> for more
> details.
>
> You should have received a copy of the GNU Lesser General Public
> License along
> with this library (see the the license.txt file); if not, write to the
> Free
> Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> 02111-1307
> USA.
>
> =cut
>
> </%doc>
>
> <%perl>
> my $cat = $burner->get_cat();
>
> my $return_class_string=$cat->get_uri();
> $return_class_string=~tr/A-Z/a-z/;
> $return_class_string=~s/\// /g;
> $return_class_string=~s/^ *//;
> $return_class_string=~s/ *$//;
>
> return($return_class_string);
> </%perl>
>
>
> Hope that helps, and hope someone is documenting all this on the
> Wiki! ;-)

--

Brad Harder,
Method Logic Digital Consulting
http://www.methodlogic.net


lannings at who

Oct 9, 2008, 1:54 AM

Post #13 of 28 (8360 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Wed, 8 Oct 2008, David E. Wheeler wrote:
> Never put sub defs in %once blocks. Do put lexical subs in %once blocks:

I think that just avoids a warning, though.


acaul at rand

Oct 9, 2008, 7:49 AM

Post #14 of 28 (8358 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

I really wish we had abstracted more of the functionality to give the
content managers more control. Unfortunately, when everything has a 2-
hour turnaround time :), you can't always build a correct
architecture, and a lot of functionality gets put into the templates,
which then takes it away from the users.

__________________________________________________________________________

This email message is for the sole use of the intended recipient(s) and
may contain confidential information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message.


david at kineticode

Oct 9, 2008, 8:56 AM

Post #15 of 28 (8353 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Oct 9, 2008, at 01:54, Scott Lanning wrote:

> On Wed, 8 Oct 2008, David E. Wheeler wrote:
>> Never put sub defs in %once blocks. Do put lexical subs in %once
>> blocks:
>
> I think that just avoids a warning, though.

It also keeps the scope of the function within that one template,
rather than across all templates. The later can have unexpected results.

Best,

David


rolfm at denison

Oct 9, 2008, 8:24 PM

Post #16 of 28 (8359 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

I started this thread, so I should throw in some of our things.

1) I wish we'd picked a better naming convention for our elements and
templates so it was easy to distinguish between stories, subelements,
and utility templates, and what was associated with what. As it was,
we made it up as we went along.
2) I wish we had really learned Mason when we started. Instead, we
learned perl and many of our templates are large perl or init blocks.
Basically, our templates don't look too mark-up-y.
3) The component/module distinction would have been great to
conceptualize as well.
4) Only recently have we discovered the power of utility templates.
5) At the begining, we didn't use dynamic includes, and only gradually
came to use them.

That's what I can think of off the top of my head. Our code is really
ugly and hideous, and at this point is turning in on itself. So
that's . . . that's going to go away.

-Matt


rolfm at denison

Oct 13, 2008, 5:55 AM

Post #17 of 28 (8341 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Oct 8, 2008, at 4:38 AM, Scott Lanning wrote:

> Although I'd tend to use utility templates too,
> I don't like them very much in principle;
> see http://www.masonhq.com/?ModulesInsteadOfPerlComponents .
> I'd prefer that kind of thing to be done
> in a Perl module, then you just "use Whatever qw(anyway)"
> in a <%once> block (and put in PERL_LOADER in bricolage.conf).

This idea intrigues me. Just out of curiousity Scott, where do you
store your modules?

Furthermore, I think it would be very cool to take a few extremely
useful, limber utility templates and include them in the Bricolage
distribution. Two I can think of off the top of my head are the Image
Magik image manipulation template, and the Rich Text Paragraph
template (which we have perl-ized). By including a couple of these
along with instructions on how to use them, we could drastically
increase the out-of-the-box usefulness of Bricolage.

Thoughts?

-Matt


david at kineticode

Oct 13, 2008, 9:56 AM

Post #18 of 28 (8342 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Oct 13, 2008, at 05:55, Matt Rolf wrote:

> This idea intrigues me. Just out of curiousity Scott, where do you
> store your modules?

I expect that he installs them like Perl modules from CPAN.

> Furthermore, I think it would be very cool to take a few extremely
> useful, limber utility templates and include them in the Bricolage
> distribution. Two I can think of off the top of my head are the
> Image Magik image manipulation template, and the Rich Text Paragraph
> template (which we have perl-ized). By including a couple of these
> along with instructions on how to use them, we could drastically
> increase the out-of-the-box usefulness of Bricolage.

Well, the sample templates included in the distribution have needed to
be updated since version 1.0. I welcome submissions to change them,
although I do think that they should work out-of-the-box, with no
extra module dependencies.

Best,

David


rolfm at denison

Oct 13, 2008, 10:37 AM

Post #19 of 28 (8332 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Oct 13, 2008, at 12:56 PM, David E. Wheeler wrote:

> Well, the sample templates included in the distribution have needed
> to be updated since version 1.0. I welcome submissions to change
> them, although I do think that they should work out-of-the-box, with
> no extra module dependencies.

Yeah, I guess what I was saying is that they should be installed as
modules either within or without the bricolage source code. then you
could use them like regular api calls in whatever templates people
build.

-Matt


rolfm at denison

Oct 14, 2008, 6:44 AM

Post #20 of 28 (8324 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

Has anyone set up their templates to create markup classes or ids
automatically depending on the element key_name? If so, how has it
worked out? Has it made managing new elements and ids easier?

-Matt


david at kineticode

Oct 14, 2008, 9:39 AM

Post #21 of 28 (8321 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Oct 14, 2008, at 06:44, Matt Rolf wrote:

> Has anyone set up their templates to create markup classes or ids
> automatically depending on the element key_name? If so, how has it
> worked out? Has it made managing new elements and ids easier?

I've done that. It works pretty well, depending on the circumstance.
It's especially useful to map element key names to div or span classes.

Best,

David


phillip at communitybandwidth

Oct 15, 2008, 6:35 AM

Post #22 of 28 (8316 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On 14-Oct-08, at 12:39 PM, David E. Wheeler wrote:

>> Has anyone set up their templates to create markup classes or ids
>> automatically depending on the element key_name? If so, how has it
>> worked out? Has it made managing new elements and ids easier?
>
> I've done that. It works pretty well, depending on the circumstance.
> It's especially useful to map element key names to div or span
> classes.

Something I've started doing recently that's similar is roughly:

$m->print(' <h4 id="', $e->get_id,'">', $e-
>get_data, "</h4>\n");

This would be for a sub-heading in a page / story / article.

Which makes it possible to quickly link to sub-sections of a page,
e.g.: www.domain.com/path/filename.html#id

I've also thought of doing this for the paragraph element, where it
makes sense to have that level of granularity / addressability.


--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.communitybandwidth.ca


waldo at vqronline

Oct 15, 2008, 12:05 PM

Post #23 of 28 (8320 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

Bricoleurs,

Have any of y'all completely eschewed Bricolage's templating (for the
purpose of outputting HTML), just had it export data as XML or some
other non-display format, and used a third-party app to render that
data as HTML? I'm playing with just such a setup now, and I wonder if
somebody might have some pointers on the benefits or the pitfalls that
await me.

Best,
Waldo

---
Virginia Quarterly Review
One West Range, Box 400223
University of Virginia
Charlottesville, VA 22904-4223


david at kineticode

Oct 15, 2008, 4:24 PM

Post #24 of 28 (8302 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

On Oct 15, 2008, at 12:05, Waldo Jaquith wrote:

> Have any of y'all completely eschewed Bricolage's templating (for
> the purpose of outputting HTML), just had it export data as XML or
> some other non-display format, and used a third-party app to render
> that data as HTML? I'm playing with just such a setup now, and I
> wonder if somebody might have some pointers on the benefits or the
> pitfalls that await me.

I've output RSS.

But really, what you're talking about is no different than regular
templates. You can:

* Output HTML for serving by Apache
* Output SSI for processing by mod_include
* Output Mason for processing by HTML::Mason
* Output PHP for processing by mod_php
* Output XML for processing by XSLT

See? It's the same thing. So go for it!

Best,

David


john.durkin at gmail

Oct 16, 2008, 5:08 PM

Post #25 of 28 (8302 views)
Permalink
Re: Things you wish you'd done in your templates [In reply to]

I haven't *completely stopped* putting HTML into my mason templates (and
php) - but I certainly use bric to output php code, snippets of html as text
files to include via php, javascript, js datafiles, xml datafiles including
rss, and many other output formats as needed... The great thing about bric
is that you CAN do what you're wondering about and more... bric can be used
to manage and relate stories, media, users, etc., and spit out data in any
arbitrary format you desire - to any location you configure.

btw. - for outputting XML you should turn on XML::Writer in the
bricolage.conf and use it, it's very convenient.

On Wed, Oct 15, 2008 at 4:24 PM, David E. Wheeler <david [at] kineticode>wrote:

> On Oct 15, 2008, at 12:05, Waldo Jaquith wrote:
>
> Have any of y'all completely eschewed Bricolage's templating (for the
>> purpose of outputting HTML), just had it export data as XML or some other
>> non-display format, and used a third-party app to render that data as HTML?
>> I'm playing with just such a setup now, and I wonder if somebody might have
>> some pointers on the benefits or the pitfalls that await me.
>>
>
> I've output RSS.
>
> But really, what you're talking about is no different than regular
> templates. You can:
>
> * Output HTML for serving by Apache
> * Output SSI for processing by mod_include
> * Output Mason for processing by HTML::Mason
> * Output PHP for processing by mod_php
> * Output XML for processing by XSLT
>
> See? It's the same thing. So go for it!
>
> Best,
>
> David
>

First page Previous page 1 2 Next page Last page  View All Bricolage users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.