Re^2: Control break with Template::Toolkit

[roboticus]

sundialsvc4:

My take on it would be to use the right tool for the job. With good organization and separation of concerns it makes it easier for the maintenance programmer to easily determine which code needs to be modified to handle a task. However organization and the proper separation of concerns is related to what you do in your job, so you can't seriously lay out a blanket statement like that. If the OP is a back-end programmer who's expected to generate a report once a year or so, then suggesting they do nearly all the work in Perl could be reasonable. In fact, that person could even be justified in ignoring Template altogether as the overhead of learning it could be more effort than it's worth.

Generating reports is a very common task, and OP may be starting out in a position where they'd often be generating reports for people. In that situation, since generating reports is such a common task, it would be better to use Template to handle report-related matters--and control-break handling is such a common report-related task that it would be silly to not let Template handle it for you, as choroba illustrated in his reply.

The original question even stated:

Now, I feel this should be a task frequent enough so as to guarantee that TT would provide some means to accomplish it directly from the sorted tuples, without resort to the weird transformation I have done. Alas, I have perused the whole TT book by Wardley et al not to find any hint of this.

So in this case, the OP is clearly interested in making proper use of the capabilities of both perl and Template::Toolkit. Suggesting that the OP should be satisfied with the situation as it stands feels unhelpful to me.

So if I'm using Template anyway, I would definitely avoid munging my data structure in perl to handle common report-related concerns like pagination, control breaks, text formatting, etc. That way, in the future they could hand that data structure off to make a web page, a spreadsheet, or whatever, without having to worry about doing/undoing other data structuring.

To reiterate: use the right tool for the job. In other words, leave calculation to perl and presentation for Template. I wouldn't reorganize a data structure in perl to handle control breaks any more than I would create a complex Template to generate a summary from a set of detail records, even when the calculations are simple--I'd do the summarization in perl and hand that to Template.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

[betacentauri]

Thank you all Monks for your responses! I think your discussion reflect that there is a compromise to be taken between placing too much logic (which seems a business tier concern) into the template, and on the other hand, building an extra elaborate API which caters only to some special use case. I was hoping that there would be some TT plugin to do this particular job, as it would keep the complexity hidden, my API simple, and perhaps be useful to many a user. Do you think it is an idea to push forward?

Thank you again!

[haj]

I would not expect such a plugin to exist, or worth writing. We have just covered one very special use case: categorizing sorted four-element arrays according to their third element, and formatting them as plain text. You may have noted that choroba's output is different from mine, but we don't know whether it matters.

I myself would wrap the formatting into my template processing, either as a MACRO, where the transformation is done in TT language, or as a FILTER, where the transformation is done in a Perl module. Macros and filters can be predefined to the TT object, so the data template would just read [% categorize(data) %] with a macro, or [% data | categorize %] if you implement the formatting as a filter.