in reply to Reusable template components with HTML::Template

A possibly non-obvious "other means" is to produce the table HTML by using a separate HTML::Template instance that uses its own template for the table part. This looks like 
sub tableHTML {
    my %table_data = @_;
    my $template = HTML::Template->new(filename => 'table.tmpl');
    $template->param(%table_data);
    return $template->output;
  }

[download]
You now have the basis for a reusable component that you can pull out any time you need to embed tables in a template. Variations include passing a query into the component, which then extracts data from some data source. This technique also extends nicely to other types of components.

One thing that concerns me about this approach is that you now have to worry about managing a template widget library. Either you copy table.tmpl into every project directory that needs it, or you introduce some scheme for looking these widgets up every time they're referenced -- and doing version control ala "DLL Hell". (There may be a third way that escapes me at the moment; I suppose you could symlink to table.tmpl every time you need it, but that seems to me like the worst of both worlds.)

This is hardly an insurmountable problem, but I don't think it's trivial, either. (Maybe I'm wrong; if so, would someone point me to the trivial solution please? :-) So it seems to me that this "template widgets" approach would be more useful for a large, relatively heavyweight project than for something smaller... and my point of view is no doubt coloured by the fact that I'm mostly interested in smaller projects.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
% man 3 strfry

Replies are listed 'Best First'.
Re^2: Reusable template components with HTML::Template
by dws (Chancellor) on Aug 04, 2004 at 01:43 UTC

    Either you copy table.tmpl into every project directory that needs it, or you introduce some scheme for looking these widgets up every time they're referenced

    I consider reuse within a single project to be a sufficient win, so each project gets its own copy of whatever template fragments that project needs. This also allows per-project look-and-feel tweakage.

[reply]
      I consider reuse within a single project to be a sufficient win, so each project gets its own copy of whatever template fragments that project needs. This also allows per-project look-and-feel tweakage.

      Fair enough, and definitely a win over hand-coding table loops wherever they're needed, but:

      1. Isn't per-project presentation tweakage a CSS problem, not an HTML problem? (Yes, I'm aware that I'm being a bit of an ivory-tower theoretician here, and that CSS isn't a universally applicable solution, but still.)
      2. Per-project templates don't seem to mix well with global code (I presume your tableHTML function is in a module somewhere) -- if your code changes in such a way that it needs an updated table.tmpl, you have to remember to change all the template copies, and that sounds like a monumental pain in the ass if production code is affected.
      Of course, I'm just picking nits here. In general, I like the idea.

      --
      F o x t r o t U n i f o r m
      Found a typo in this node? /msg me
      % man 3 strfry

[reply]
[d/l]
[select]

        if your code changes in such a way that it needs an updated table.tmpl, you have to remember to change all the template copies, and that sounds like a monumental pain in the ass if production code is affected.

        That is exactly why I said that this technique is a demonstration of presentation logic seeping back into the application. It's why I argue for a more powerful template language.

        Having per-project presentation tweaked solely by CSS is nice in theory, but doesn't cut it in practice. That does not mean you should mix presentational markup into your generated HTML; you should still generate semantic markup and use CSS to style it — the most immediately obvious benefit is that you won't need to touch your templates as often.

        Makeshifts last the longest.

[reply]

        1. Isn't per-project presentation tweakage a CSS problem, not an HTML problem?

        CSS is a problem all by itself. But yes, you can do a lot of look-and-feel adjustment by first being careful to emit the right attributes so that you the right hooks to hang CSS on, and then tweaking CSS. But it's not a 100% solution, especially if you decide to do things like emit Javascript for dynamically sorting tables.

        2. Per-project templates don't seem to mix well with global code.

        I'll cop to a bias here. I used to worry a lot about cross-project code, portable libraries, building frameworks, and so forth. But the time investment never seemed to pay off. Now I worry a lot more about making things usable within a project. YMMV, but worrying about use before worrying about reuse has paid off for me.

[reply]

In Section Meditations