I've been coding and maintaining CGI::Ex::Template (part of the CGI::Ex suite) for year and a half now. The module has grown and matured and is in need of moving into its own namespace. I think it actually needed to move into its own space a year ago.

So, the big question is, can anybody think of a good namespace. Asking for a namespace in the Template, CGI, or HTML namespaces is pretty hard these days - at least if you would like the name to mean anything.

I hear everybody going, "Oh great another template module - just what we need." Well you're right. It is another template module. So why am I bothering? Here are some of the features of the version 2.13 which was uploaded today (based on my biased opinions): Here are some of the cons: So, at this point I have no idea really what to call it. It does templates. It does different kinds of templates. It can be used in CGI's but doesn't have to be. It can be used to do HTML but doesn't have to be. So here are some seed ideas: Or should I keep the name the same and move it to its own distribution (I don't really like the name now - it doesn't always have to pertain to CGIs).

Ideas?

my @a=qw(random brilliant braindead); print $a[rand(@a)];

Replies are listed 'Best First'.
Re: Moving A Template Module Namespace
by clinton (Priest) on May 23, 2007 at 15:18 UTC
    Hi Paul

    I've been wanting to ask you this for a while. Why did you develop this module? Why not just improve Template?

    Please don't get me wrong. I'm on the Template Toolkit mailing list, and I see the efforts you have made to provide direction and patches to the new TT3, but I'm interested to hear what your motivation was in developing it in the first place?

    It seems as though you have put in an enormous amount of effort (mostly alone) for a module which will likely always be in second place, just because it is fighting with Template Toolkit for the spotlight.

    I repeat, please don't misunderstand me - I am not trying to diss you or your templating engine in any way.

    And on the subject of names, I would agree with philcrow's response (Re: Moving A Template Module Namespace) - the best chance that your module has of being recognised in its own right, is with a separate, memorable name.

    good luck

    clint

[reply]
      No offense taken whatsoever. At times I have asked myself the same thing. I'm sure in the future I may also ask the same thing.

      I will continue to help out the Template Toolkit in anyway that they will receive the help. The TT mini-language is a great thing and has done much good for the perl community. I applaud Andy Wardley for having such foresight in his design of the Template::Toolkit module. I have tried to contribute and have emailed Andy directly about CGI::Ex::Template. He is aware of CGI::Ex::Template and has read at least some of the code. He has a living to make. He controls the destiny of the Template::Toolkit dialect. He has to make the best decisions that he can for what he has time to work on. If he would like to use some of the code that is great but if not that is fine too.

      Let me quote a little of the CGI::Ex::Template POD.
      CGI::Ex::Template happened by accident (accidentally on purpose). The CGI::Ex::Template (CET hereafter) was originally a part of the CGI::Ex suite that performed simple variable interpolation. It used TT2 style variables in TT2 style tags "[% foo.bar %]". That was all the original CGI::Ex::Template did. This was fine and dandy for a couple of years. In winter of 2005-2006 CET was revamped to add a few features. One thing led to another and soon CET provided for most of the features of TT2 as well as some from TT3. CGI::Ex::Template is a full-featured implementation of the Template::Toolkit language.

      I didn't start out to have a full, from scratch rewrite of Template Toolkit. I started a template engine back in 1999. It was custom and proprietary and by the time it was done evolving it had a lot of the features that Template::Toolkit had. We had rolled our own because Template::Toolkit barely existed at the time and wasn't widely known, and because we had an extremely custom need. That company did and does today (though I'm no longer there) serve millions of dynamic hits each day (even their banner treatment is templated). Those hits are customized based on the preferences of a couple hundred separate companies and on the user preferences. The system had to be extremely granular and recursive. And it had to be extremely fast. Template Toolkit is "fast enough" for most applications - and is always fast enough if it is in a mod_perl environment. But I did and still do work in hybrid CGI/mod_perl environments. Template Toolkit sometimes is the bottleneck.

      Well, anyway - back to CGI::Ex::Templates story... CGI::Ex::Template (CET) began simply as the perldoc mentions. It grew until it encompassed all that TT can do. But CET has always done it "lighter" (for whatever definition of lighter) and "faster" (for whatever definition of faster). In some discussions with Andy he mentioned that CGI::Ex::Template didn't use a regex based grammar. I originally had intended to - but micro-optimized myself out of it. After rereviewing it, I rewrote everything and ended up with the current parsing engine that is all regex based. I then realized that I could layer other parsers easily on top, and so just recently I added the HTML::Template::Expr dialect. My current goal, is that within a few weeks it will be able to do TT1, TT2, TT3, HTML::Template, HTML::Template::Expr, ASP style, Velocity, and Text::Tmpl style -- all from the same engine/parser/runtime.

      Some of the motivation for this is "simply because I can."

      My other real motivation is I work at a shop right now that has HTML::Template::Expr templates as well as Text::Tmpl templates and since I've begun working there has Template::Toolkit templates. Some of the problems this brings is that we have to modify the same html in various template syntaxes, we have to use HTML::Template::Expr which is heavy and slow but at least brings advanted features to HTML::Template, and we have to load all of the various engines into memory. There is a lot of duplication in features between the various engines.

      So while it wasn't always my goal, now, by adding one more templating system, I can handle all of the various dialects with one set of configuration and with one set of compiling and caching options. I can even including templates from the various dialects in other dialects. I can maintain one header in one dialect, compile it, cache it, and use it in all of the other dialects.

      I don't do a lot of marketting for my modules. If people would like to use my modules that is great. If other projects can use my modules that is wonderful. I'll try to document them and make them as easy to use as possible. I think CGI::Ex::Template is a good module. My opinion is that it has a lot to offer to the other templating project camps. CGI::Ex::Template may always play second fiddle, but that is fine. I'll try to let people know about my modules, and if they have enough motivation to use them that is great. But in the end, I am a consumer of my goods and it is good enough for what I am looking for.

      As a final note - it is all sort of funny. I think I have a very good template module in a very crowded template world (CGI::Ex::Template). I think I have a very good application framework in a very crowded application framework world (CGI::Ex::App - which nobody has heard of - but that's fine). I think I have a better form filler than the defacto standard module (CGI::Ex::Fill - that nobody nor their dog has heard of - but that is fine also). I have an ok generic server engine (Net::Server) which gets more attention even though it is old crufty code and I put only a little time into it. But all of these projects only offer cursory support my current work projects which provide for my living. The module I want to write is large, and world changing, .... and always on the shelf (the funny thing is I have a name picked - but it is meaningless).

      Gee - I think you touched a nerve. Sorry for the long response.

      ++ for your very good question.

      my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]
[d/l]
        Even from my first reading of your original post, I didn't have the same viceral negative reaction to your templating system as I usually have to others. I've now figured out the reason.

        You have recoded a templating system, but you have not invented a templating syntax. Instead, you've borrowed the syntaxes of other templating systems. This is genius. Most of what I don't like about new templating systems is their idiosyncratic syntax, which their authors invariably defend as better when it is merely different.

        Here you are with a pluggable meta-templating system apparently robust and complete, having never given in to the urge to design your own template syntax. Cue Applause.

        As a user of template systems, I don't ultimately care about the implementation details (unless they make the system too slow to use or interfere with robustness). Rather, I care about the syntax, mostly that I don't have to learn a new syntax.

        While you have not layered on top of existing templating systems -- in the way the DBI layers on top of various databases, because you have reimplemented the parsing -- you have created a generic facade from the template user's perspective.

        Were I to market your system, I would focus on that. I would not say, "I've written my own templating system." Instead I would say, "No new syntax to learn here, just speed and flexibiliity to gain." In other words, focus on how users will approach the system not on how the internals work.

        I wish you good luck indeed, whatever you call it.

        Phil

        The Gantry Web Framework Book is now available.
[reply]
        I've had just a quick glance at the module. Apparently it has over 3300 lines of code (including docs, interspersed between the code) and it takes up more than 120kBytes. That's quite a lot, especially for a "lightweight" templating module.

        What I was hoping for, is something that (AFAIK) TT2 does provide, and that is preprocessing a template file and turn it into a plain Perl source file, and save that to disk. The template is actually converted into a Perl module. That way, when the template doesn't change, the templating module doesn't even have to be loaded into memory, and output generation can happen at full speed. That sounds like the most promising approach for CGI applications, to me, as it is lightweight, and templates don't change too often.

        So... what is your opinions on these thoughts? Did I miss something, or did you think about it and found it was just not worth the trouble, or... ?

[reply]
        I'm feeling the Template name-space is ideal for this. My thoughts will follow this route, but the subnames could go elsewhere I suppose.

        I usually work these naming issues out best by brainstorming. So, I'll riff on a few ideas here in a response, and take or leave any of them. Sometimes the reasoning behind one is as useful in finding another one as the possible name itself.

        My first instinct was Template::Multitool (I'm a fan of Swiss Army and Leatherman inspired toolsets).

        I do like Template::Pluggable, although you're not really plugging the others in so much as accepting their syntax as a layer, are you? Maybe Template::(Multi|Poly)Syntactic makes sense, although it's not the shortest or simplest.

        Say, since you're doing multiple Toolkits, perhaps you've built a whole Workshop. Template::Workshop, maybe.

        Template::Agnostic perhaps goes too far, but it makes for an interesting name.

        I almost want to recommend Template::Berlitz, but I wouldn't want to steer you towards trademark issues. Template::Cooperative works for the aspect that more than one templating dialect can be used together, but not for much else.

        Template::Retool is kind of a pun on TT, but it's also serves the notion that a large project may not be able to move from one templating module to another all at once. By using something that accepts more than one dialect, a project can go piecemeal if necessary.

        Template::Dialects gets to one of the core features, in that it's different dialects of templating with which the module deals.

        There you have my initial thoughts. I won't be offended if you hate any or all of them.
[reply]
Re: Moving A Template Module Namespace
by philcrow (Priest) on May 23, 2007 at 12:47 UTC
    I vote for DaintyFlower. Names get meanings as people use them. Make a public svn, start a mailing list, write about it for perl publications, meditate on it here. Either, we won't want to switch to it, in which case the name is immaterial. Or, we will like what we read and try it, in which case the name is almost immaterial. Only new people searching for templates might miss it and then only if the docs don't have the word template promonently placed.

    The chief advantage of DaintyFlower (or other similar names) is their googlibility. Searching for perl template is likely to work, searching for DaintyFlower is sure to.

    Others I might like as more straightforward: Template::Pluggable, Template::Flex, or Template::YATS. Best of all: Template::DaintyFlower.

    Phil

    The Gantry Web Framework Book is now available.
[reply]
      So if it is to be Template::DaintyFlower style, are there any other good suggestions of random names? DaintyFlower was just a random suggestion. My internal random name generator isn't outputting as much as I'd like.

      Seriously - any random or non-sensical suggestions will be entertained. I think I am looking for short/easy to say/hard to misspell ideas (prefixed with Template:: is fine).

      my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]
        How about HotHouse? It's a little shorter and suggests a broader utility than one fragile flower. Or, for a stronger plant: FlyTrap. Perhaps you could take a tour through a thersarus starting with template and prototype.

        Phil

        The Gantry Web Framework Book is now available.
[reply]
Re: Moving A Template Module Namespace
by Jenda (Abbot) on May 23, 2007 at 08:30 UTC
[reply]
Re: Moving A Template Module Namespace
by simon.proctor (Vicar) on May 23, 2007 at 09:37 UTC
    Have you considered supporting the velocity syntax as well?
[reply]
      I hadn't heard of it until you mentioned it. It is sort of funny but it looks like template toolkit it sheeps clothing.

      That particular template style should be no problem to incorporate. I'll include it in the next release - whatever name I end up releasing under.

      I'll also be releasing ASP also - there are plenty of perl ASP variants - may as well be able to use them with other templates too.

      my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]
Re: Moving A Template Module Namespace
by shmem (Chancellor) on May 23, 2007 at 07:54 UTC
    The module [...] is in need of moving into its own namespace.
    Why?

    --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]

      I think the answer is quite obvious... having the module under the CGI namespace may prevent developers from adopting it for the simple fact that nobody wants to be tied to this protocol nowadays.

[reply]
Re: Moving A Template Module Namespace
by 2xlp (Sexton) on May 24, 2007 at 22:47 UTC
    I like the Template::Flex and Template::Pluggable suggestions

    You could also do something like Template::Interface or Template::Provider

    If you have a lightweight, extensible engine.. I'd suggest supporting TAL. There are 2-3 TAL implementations in Perl already, but a new option is always good.
[reply]
Re: Moving A Template Module Namespace
by gloryhack (Deacon) on May 25, 2007 at 03:43 UTC
    Tyrannosaurus::Sex "A big f'in opportunist that will eat anything that comes its way". It doesn't even have to work if it has a really cool name. The "::Sex" part is just an excuse to work in the "f'in" part, naturally. Gotta have that in there to make the name *really* cool. Samuel L. Jackson would learn Perl just so he could use a module by that name.
[reply]
Re: Moving A Template Module Namespace
by sfink (Deacon) on May 29, 2007 at 15:54 UTC
    I'm good at randomness but bad at naming.
    • Platypus ("website powered by platypus")
    • RubberCookie (got there from cookie cutter templates)
    • MeatCookie (just like the sound of it)
    • RubberGuppy (try pronouncing RBGPTE)
    • Guppy (drop the regex-based part)
    • Gargoyle
    • Template::Chameleon
    • Chameleon
    • GrapeBrains
    • LeadFoot
    • FloatingInk
    • Inkpad
    • AngryFuzzyHippopotamusBadHairDay
    • ...I think I'd better stop.
    My vote would be RubberGuppy. Probably a good thing I don't get to decide.
[reply]
Re: Moving A Template Module Namespace
by girarde (Hermit) on May 29, 2007 at 16:30 UTC
[reply]
[d/l]
[select]

Back to Meditations