in reply to Re^4: RFC: Templating without a System
in thread RFC: Templating without a System

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.

Replies are listed 'Best First'.
Re^6: RFC: Templating without a System
by shmem (Chancellor) on Jun 21, 2006 at 21:40 UTC
    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}
[reply]
      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.

      ++ for that alone. At last, a defense against the "Don't reinvent the wheel" mantra.

      I don't do web stuff, so I won't comment on the efficacy of your module or your inside out approach, but I definitely do support your search for a simple alternative to toolkits that consist of 200+ modules.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Meditations