Re^3: object-oriented composition of model-view with HTML::Seamstress

[Rhandom]

I read your definition of Perl layer below. The first comment is that Perl layer is not a fine-grained term.

I actually thought it was. My perl layer was essentially as simple as

my $data = get_data();
my $t    = Template::Alloy->new;
$t->process("bullet.tt", $data);

I would be inclined to say that there isn't a lot of ambiguity where the Perl layer is in the example I gave. The part where you can't see a fine separation has more to do with the model that Seamstress uses (which is an argument in your favor for using Code layer vs Presentation layer - much of your presentation layer is perl). Seamstress requires you to use perl to manipulate your data. My example using TT syntax didn't.

The second comment is that Perl is the practical extraction and report language. It excels at manipulating data. I therefore refuse to use a template system for manipulating data.

I think you are mistaking "changing data" with "manipulating data". You'll notice in my example I didn't change a thing about the data - I just accessed the array in a different order.

The comment about the "practical extraction and report language" being used to manipulate data is a good one. The native language is the best for obtaining, changing and/or sorting the data. But if we are extolling the merits of the "reporting" language, why do you not also use perl to actually do the reporting. Well, that is obvious - we need to separate our concerns and perl's internal facilities for translating data into HTML are not nearly as easy to use as a templating system.

Model actions belong in model, not anywhere else. And the model is best done in pure perl.

I concur. My model - the data arrayref in this case - is entirely in pure perl. And my view is entirely in the templating language.

Your sample tt code mixes concerns. Data processing should be testable completely offline.. and completely free of any view. Mine is. Yours isn't.

Um. Check again. All of my "data processing" was accomplished in the [1 .. 10] - I can test that offline completely. It is entirely free of view. Re-formatting how it is displayed is a concern of the view. The data doesn't change.

What is external whitespace?

That would be the whitespace outside of the HTML tags. TT syntax gives you full control over whitespace (see the PRE_CHOMP and POST_CHOMP operators in TT documentation). Pretty much all other template systems I've seen make you place your HTML tags/elements in odd configurations to make the output look nice. To some, external whitespace really doesn't matter - but as somebody who has had to debug a large amount of HTML source - it matters to me.

For extra credit - make the template decide conditionally that if you have less than n items use the bullet list - otherwise use the table. That's really just basic Perl:

I think you missed the point. Sure I could do that in Perl - the point is that I don't have to. If the HTML design team wants different criteria - I don't have to touch the perl code.

Well you didnt do it.

I apologize - I figured it was obvious in the TT languages. The way I would do it is I'd remove the HTML tags from the template. And then I'm done. All of the HTML DOM based template systems work with XML/HTML only and don't have facilities for making other non-XML/HTML things easy. And just for completeness - here is the template for the first example that would be suitable for use in a text email:

[%- FOR i IN items %]
 * [% i %]
[%- END %]

It's a good example. But once you see my code, please point out the perrin-rhandom syndrome in the push-style approach or recant the criticism.

While your code is well written and nicely formatted, and the logic is impeccable - it just doesn't look like fun. Obviously Seamstress is very capable and you have built a very fine piece of software - but I'd rather get my data ready and hand off to the template and let the template do what it is good at. The amount of hoops you had to jump through in the "Perl Layer" to complete some of the sample problem only seems to confirm the issue.

Update 2 s/specifying/manipulating the data/ Again a request I cannot comply with. I will never forget the time that Ovid tried to justify things like this, by calling it "presentation logic" and saying that a "presentation tool" like tt would be good for it. I disagreed with him then and with you now. No one should request data processing anywhere but a data processing giant (Perl).

Once again you are confusing processing the data with presenting it. Perhaps my use of "manipulate" has been wrong - I have intended it in the form of "format" the data or "manipulate it into display shape" while you seem to have interpreted it as "change the data." While TT does let you change the data itself - this is normally a bad idea except for the cases when it isn't. But you do have the option when the occasion requires it. Either way - the presentation layer must have the ability to layout the data however it wants to.

And I am grateful to have had a chance to shake the rust off myself :)

I'm glad I could in someway provide some benefit to you - even if very indirectly. Seamstress is a fine piece of work. For my use cases it seems more academic than practical - but my use cases probably vary greatly from yours.

In the end, I should've clued in a little earlier that I shouldn't get involved in a religious debate about templating systems. I apologize for taking up everybody's valueable time. Hopefully some parts of this discussion have been helpful to somebody out there.