A day's worth on research reveals much, and it affirmed my suspicion that chosing one of them templating systems is a wicked problem. Every choice has its consecuences you cannot foresee. Lack of experience and knowledge ever lead me to take steps as small as possible, and the more cautious I am with wicked problems; so, if I don't find the right tool for this approach (due to lack of time, experience - not knowing how to help myself -, laziness, tiredness, whatever) I roll my own which more often than not I can throw away fast (or which offhand is so crufty that it must be refactored anyways :-).

It is not easy. Which is the right way to go? A clean approach to W3C compliant pages is that of HTML_Tree (or HTML::Seamstress). Petal looks very powerful, but its syntax is not very intuitive. HTML::Template is scared about callbacks; Catalyst messes with attributes because it's cool (I apologize in advance for that statement) etc. All of them in themselves mix design with function: <TMPL_VAR foo> is a design choice, as is the language of Petal. What is "standard" here? Each has it's own idea of why you must subclass what when, and the interfaces are deliberate.

What suits the needs of a project which you don't know better (four sheets of draft don't say much) - DOM parsing, pipeline or callback model? a mix? what about caching? What impact on load has your decision? Are changes forseeable, and to what extent will they go? Who are the people you are developing for? what are their skills? An example -

Not long ago I advocated the use of lucene for an intranet search engine to a company, after having been told about the profile of their IT department. Gosh, we even had to read them the manual pages at the phone. It turned out that the Java expertise rested on the shoulders of some few overladen with work. Now I'm the bad guy which gave wrong counsel.

And so on. A decision matrix would be handy.

Templating is well-covered, and the modules out there are quite evolved and mature, and that is just their^H^H^H^H^Hmy problem. TIMTOWTDY is fine, but it is lost in the process of evolving and maturing of those bundles. I am supposed to inherit from Class::Prototyped in one, and from Class::NEXT in the other. What if I want to use Spiffy?

No, I wouldn't say it doesn't matter lest I do decisions which I would later regret and get stuck with obscure bugs trying to get features work which I definitely must have, and which might be well a "bug by design" - and having to deal with included code which I must "trust" because I don't understand it - and I don't understand it because I don't have the time to walk it's guts (well, that holds for perl as a whole, but here the situation is different: when I first worked with it, it was version 4 patchlevel 36, and at that time I trusted it because I was naive. Now I trust it by experience and because it's seasoned :-). Quote from above report:

In the meantime, I seem to have a workaround – I just undef $template->{driver} in my scripts prior to $template going out of scope. It's an ugly solution, but I'm trying to avoid switching to TT as we have too many templates to change at the moment, and I think the HTML designers would throttle me if I introduced a new template system to them.

Bottom line: rather than a complex toolkit I would have small modules with the least inheritance possible, which address each a well defined problem, having defined and agreed-upon interfaces and a complete documentation. I'm still adept to the old UNIX philosophy of small is beautiful which led to specific tools for specific purposes that can be combined following rather simple rules, and I would use those rather than an "all-in-one device suitable for every purpose", philosophy of some wicked company which does e.g. office software (heh, I'm trolling for baits :-).

Speaking of MVC (which seems to be a paradigma widely adopted for web programming) I would rather see Web::Model, Web::View, Web::Controller and Web::Engine or such than any of them toolkits. Then it would be about time to subclass with e.g. Web::Controller:DBI or Web::Controller::CGI. All other approaches seem cruft to me (at the current state of my garlic).

That said, although my posted code is crufty and never was a module for release I don't think its ideas must be thrown away (mainly because they're already done).

One more word - the "don't do that, it's already done" argument doesn't make much sense. If it were for that we would never have seen SysV or Linux, but would be all happy using *BSD.

greetings,
shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

All of your points cover the code you write too, except possibly for the intimate understanding of the guts of the code. Thus I cancelled them out in the equation.

My core business isn't writing a templating system. It's writing and editing technical documentation. Thus it's a risk for me to write a templating system. However, part of producing technical documentation is managing and presenting and encoding and formatting text appropriately, so when it came time to produce attractive, well-formatted output, I faced a problem in which (I still believe) creating my own translation utility was the right solution, even though others exist.

I don't particularly want to support it (I wish someone else did), but I understand it and now it exists and I can add features if and when I need them. However, a short period of time into my experiment revealed that I really don't want to write, port, or refine a linebreaking algorithm. Thus I rely on someone else's. It's not perfect, but I have confidence that building on that core will be much easier than reinventing that work.

It's just a matter of what's important. It's really difficult for me to believe that, over time, building your own mini templating system will really pay off. I could be wrong. Like I said, it's not my decision and I definitely know very little about your environment... but I do like to think I understand some of the risks of writing and maintaining software.

It isn't my business either. In fact, I don't want to write a templating system, I want to use one ;-)

What I did I did of need, and publishing it was encouraged by what Ovid and BrowserUk wrote on simple Modules, together with the recent perl vs. PHP thread.

The module adresses nothing but turning a glove inside out - HTML containing perl into perl containing HTML, stuff that into an anonymous sub and make that available in various ways (OO, functional, AUTOLOAD) in whatever the right namespace is, and done. Nothing else. Extra functionality must not be added. It should remain simple but be well documented and tested, have its assumptions and conventions addressed and its limitations outlined.

I'm trying to incite a simple and concise implementation of the core of MVC for the web, barebone, without too much features. Splitting up CGI, for that matter. And I did start with one aspect of it - views with embedded perl, usable for

• just printing
• printing with simple variable interpolation
• all other stuff that perl does
• re-compiling upon changes of the source via timestamp checks

(Next could come DOM parsing or XML generation and such. But at which stage this should happen is not clear.)

Again, I don't want to reinvent the wheel but get a wheel without a car around just in case I want a nifty chopper.

A controller package should be the same. CGI::Prototyped is close to what I seek, but so is CGI::Application. All that's view related should be a stub in the module, and done. But the "how" - the interface - must be broadly discussed and done in the most standard perl way; how the controller interacts with model and view parts; and the assumptions each part has of the other's behaviour. There were some discussions about traits here; prototypes.. hmm.

I don't know about the history of the various toolkits, but I think if were that discussed, we would not have (x+1) different templating systems or MVC engines, but the MVC basics implemented in a simple and standard way.
Something like DBI for the web.

That's why I RFC'ed in the first place. I am looking for some "generic" approach and wanted to check the resonance.

<p style="rant=on; display=volatile">
Much effort was invested by many people in their modules, which are now seasoned (which isn't the same as mature), and they appearently didn't come together to agree upon their dream's commons, and now I'm blamed for coming late doing something similar out of a fix?

I don't care about my ($module) being accepted, appraised, developed or downvoted. Heck, if my module is of no use, it will simply vanish and no harm done, or been replaced by a better one. After all, 360+ lines of code and something learned.

But I'm really pissed off not because some PHP apologists claim that "there ain't such thing as PHP in perl", but by the fact that because each of them toolkit people defend their ideas as best, the former are damned right.
</p>

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}