On 7/28/05, Brett Sanger <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 28, 2005 at 03:02:17PM -0400, Jesse Erlbaum wrote:
> > means, assume away. If you're using TT, then chances are your HTML
> > person also has Perl chops.
>
> Not remotely. Just because there is power to abuse does NOT mean it
> should be. Someday I vow to write a TT intro that reflects that, where
> the current docs are practically a list of thigns to avoid.
I have to agree with Brett here. I find that more often TT is easier
to understand than HTML::Template, because of the clear tag structure
(html is html, template tags are template tags), and the magic dot
notation (shows more structure in your variables while giving much
more flexibility in the template). However as a developer, you have
to be a bit more dilligent in keeping your programming logic out of
the templates. It is not a difficult task though.
And the converse is also true though. TT is much better at keeping
display logic out of your code which I think is just as important
(formatting numbers and dates being one simple example).
> > If you don't mind putting presentation dependencies into your Perl
> > code, then automate away. (It's anathema to me, but maybe it works
> > for your environment.)
>
> No, it's against my personal practices as well. I just begin most
> projects with templates that are something like (these aren't really my
> variable names):
>
> [% FOREACH Field = Record.Fields %]
> [% IF loop.first %]
> <table border="0">
> [% END %]
> <tr>
> <td>[% Field %]:</td>
> <td>[% Record.$Field %] </td>
> </tr>
> [% END %]
>
> Which works just fine, and is reasonably durable, but not pretty. But
> after the designer is done, many fields are treated differently, the
> loop is entirely gone, and every change at a higher level involves
> changing several templates. I was unable to think of a specific way to
> fix this that wasn't more work. (such as tagging the data with
> metadata, and "simply" specifying how that metadata would afffect the
> display...sort of a CSS for building HTML). I just hoped that someone
> was smarter than I was :)
I have actually been trying to move more of the design stuff out of
the templates, and getting my designers to put them in CSS instead.
What you can do is define a very clear 'class' and 'id' naming
convention for all of your data, and then just place your data in
<div> or <span> tags. Then the only thing that becomes important in
the templates that the designer may want to alter is the ordering of
the data.
<div class="records" id="record_[% Records.id %]">
[% FOREACH Field = Record.Fields %]
<div class="fields" id="field_[% Field.id %]">
<div class="field_label" id="field_label_[% Field.id %]">
[% Field %]:
</div>
<div class="field_value" id="field_value_[% Field.id %]">
[% Record.Field %]
</div>
</div>
[% END %]
</div>
That looks a bit busy, but it is just an example. With that and a CSS
stylesheet, you can structure the data in almost any way you like.
You basically get three levels for your app:
Programming: perl code
Layout: templates (and somewhat in the stylesheets)
Design: stylesheets
It is not easy to get to this level, and I haven't been successful in
moving everything to this model, but it does give you that third level
of flexibility in your design. It can work against you sometimes as
well though, so I wouldn't use it in every situation (and of course I
should note that this is easy to do in HTML::Template as well).
Another benefit of this setup is that you can reuse the same template
and apply a different CSS stylesheet to it to display it in a
completely different manner, solving one of your dilemas.
Cheers,
Cees
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
