Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

RFC - Template::Empty

by redhotpenguin (Deacon)
on Feb 25, 2008 at 08:13 UTC ( #669956=perlmeditation: print w/ replies, xml ) Need Help??

Monks,

I'm tired of writing meta code in templating languages. I'm really good at writing Perl, and good at writing HTML, but I'm lousy at the templating languages (and I'm not too fired up to learn more about them).

I'm tired of form handling. I have written form handling modules, and they always get way too complicated. But then tonight I had an idea.

That idea is Template::Empty. If this sound crazy, just keep reading. It gets weirder.

HTML pages are easy to parse (please ignore server side includes for this rfc). The problem happens when you mix code and html in attempting to make them easy to write. Mixing code and html has done to many a programmer what mixing booze and pills has done to many a rockstar. The end result is never pretty.

So I introduce to you the concept of the empty template:

<html> <head> <title></title> </head> <body> <div id="messagebar"></div> <p>Please fill out this form</p> <p> <form action=""> Userame: <input type='text' name='username' value=''> </p> <p><input type='submit' name='submit'></p> </form> </body> </html>

Note first off that the title tag is empty. So now we need a template object to fill that in:

my $template = Template::Empty->load(file =>'index.html'); $template->title = 'Now we have a page title'. $template->form->action = $ctx->uri; $template->form->username->value = $default_user->username; $template->messagebar = 'Your last record was updated'; print $template->as_string;

There you have it. The class parses the html file once on load, and constructs a template object containing entities such as title which can be set, and form objects which can be manipulated. There are certainly libraries such as HTML::FillInForm, and Template, which can be used to implement the actual as_string() method which serializes the template output.

Of course, I'm sure this approach is fraught with its own nasty design issues, but it allows for a pure html template in some simple cases examined here. Feedback welcome.

Comment on RFC - Template::Empty
Select or Download Code
Re: RFC - Template::Empty
by Corion (Pope) on Feb 25, 2008 at 08:17 UTC

    This reminds me somewhat of Petal, in which you also have an "empty/sample template". Petal stores all the directives (like, which parts to repeat) in HTML attributes - I'm not sure how your template would know which parts to repeat (<tr> for table rows, <li> for list items etc.)...

      Seconded. If you want to avoid programming in your HTML files and you want HTML that can be previewed and editted in HTML tools then Petal is there already.
        fergal sayeth:
        If you want to avoid programming in your HTML files and you want HTML that can be previewed and editted in HTML tools then Petal is there already.

        Your second point I agree with: Petal does maintain HTML that can be previewed and edited in HTML tools.

        But I disagree with your first point. I think Petal allows for programming in HTML. Sure the syntax of the programming language looks a bit different, but it's still programming in my book. And in a previous post you literally said: "petal's loops" --- now since you said that Petal had loops and since loops are a programming construct, you can program in petal...

        begin round two of fergal versus princepawn :) -- round one took place here

        Let's compare HTML::Seamstress, Template and Petal briefly:

        condition

        petal

        <span tal:condition="true:user/is_authenticated"> Yo, authenticated! </span>

        tt

        [% IF user.is_authenticated %] Yo, authenticated! [% END %]

        seamstress

        <div class="auth_dialog"> <span sid="authed"> Yo, authenticated! </span> <span sid="not_authed"> NOT authed </span> </div>
        use html::auth_dialog; my $tree = html::auth_dialog->new; $tree->highlander (auth_dialog => [ authed => sub { $_[0]->authenticated } not_authed => sub { 1 } ], $model ); print $tree->as_HTML;

        loop

        petal

        <tag tal:repeat="element_name EXPRESSION"> blah blah blah </tag>

        tt

        [% FOREACH s IN EXPRESSION %] * [% s %] [% END %]

        seamstress

        There are a number of looping methods abstracted into HTML::Element::Library for use with Seamstress in a disciplined object-oriented fashion...
        <div class="elemid"> blah blah blah </div>
        my $li = $tree->look_down(class => 'elemid'); my @items = qw(bread butter vodka); $tree->iter($li => @items);
        I have beheld the tarball of 22.1 on ftp.gnu.org with my own eyes. How can you say that there is no God in the Church of Emacs? -- David Kastrup
        [tag://html,templating,seamstress]
        Enforce strict model-view separation in template engines via HTML::Seamstress The car is in the cdr, not the cdr in the car
      This reminds me somewhat of Petal,
      Actually not really, what the OP wants is much closer to my own HTML::Seamstress. Petal embeds a mini-language within HTML... Seamstress is pure Perl and pure HTML and nothing else.

      Seamstress takes its inspiration from XMLC and I am very grateful to lachoy for mentioning it. Petal takes its inspiration from TAL.

      To understand the difference between push-style templating (Seamstress) and pull-style templating (tt/mason/petal/html::template, etc) you should read Terence Parr's paper on the subject.

      I have beheld the tarball of 22.1 on ftp.gnu.org with my own eyes. How can you say that there is no God in the Church of Emacs? -- David Kastrup
      [tag://html,templating]
      Enforce strict model-view separation in template engines via HTML::Seamstress The car is in the cdr, not the cdr in the car
        ++

        Thanks for the link to the paper. I found it interesting. I also found it somewhat biased and amusing.

        I found it amusing because section 7.1 is labeled "Pull Strategy Violates Separation" - but he never treats the topic of whether "Push Strategy Violates separation."

        There are also statements such as "Strictly speaking the URL structure of the site belongs to the controller." This is nice in theory and is true in ideal situations. After 10 years of work in non-ideal situations I've found that it "strictly" isn't true. Sometimes templates contain links that take you in and out of the controller loop.

        The true bias is revealed when the last section of the paper is used to present his "new" templating system which does clear up some fuzzy boundaries - but doesn't provide anything truly remarkable over existing systems.

        Formal papers are nice in an academic sense, but that doesn't mean his experience has any direct bearing on the experience of others. He is welcome to argue his point, but in the end - all of the various models have managed to get the job done for people who have used them. Existing solutions are certainly good enough for all practical purposes.

        my @a=qw(random brilliant braindead); print $a[rand(@a)];
Re: RFC - Template::Empty
by stiller (Friar) on Feb 25, 2008 at 08:32 UTC
    It seems nice enough, but I think it's not needed. For a template as simple as your example, most if not all the existing is fine. For more complex examples (only include this section if...) then either one will have to switch from your to a more complex one, with a need to rewrite code and template.

    And this approach looses something I really like about Template: solid visual clues to the web-designers about what they must not change. E.g.:

    Username: <input type='text' name='username' value='' />
    vs:
    Username: <input type='text' name='username' value='[% default.use +rname %]' />
    And then all the other things you will have to implement to get a fairly complete template system. I toiled with making my own, but found I still had loads to learn about the existing templating systems.
    But that's just my $0.02
    Edit: typo in placing the default username in the name attribute.
    Update 12 hours later: I might be in for some serious reconsiderations.
Re: RFC - Template::Empty
by amarquis (Curate) on Feb 25, 2008 at 15:27 UTC

    I like it.

    stiller mentions above that "... this approach looses something I really like about Template: solid visual clues to the web-designers about what they must not change..." That's fine, because there are plenty of solutions out there that are geared towards the web designer and programmer being separate. This is a neat solution for those who are doing both ends of the design, as it eliminates the interim templating language step.

    Like you, I never had the patience to learn a templating module beyond the simple (but great) HTML::Template. That's not too ideal because for some things that HTML::Template doesn't handle, I end up mixing some HTML into my Perl and outputting that into the template.

    Again, I like it, and think it would be a good solution for people who do both the web design and the programming but want to keep their HTML and Perl somewhat separate.

      I agree with amarquis.

      I like the way that it allows you to write pure HTML, and pure Perl - without intermixing any of them.

      When I'm working on my own projects, I generally use HTML::Template - but even then, the custom tags and such always bothered me. It looks like Template::Empty would nicely clean that up, although I think it needs support for looping elements - like tr's, li's, etc. - before I'd be able to use it very effectively.

Re: RFC - Template::Empty
by sundialsvc4 (Monsignor) on Feb 25, 2008 at 15:47 UTC

    “Mixing code and HTML” a la PHP definitely turned out to be “a very-appealing mistake,” but I don't know that it's right to go to the opposite extreme.

    The essential mistake that PHP made was to attempt to completely-merge the output and processing stages. What was good for simple websites (such as were common when PHP was first invented) turned out to scale poorly, and as a consequence of this, PHP developers have adopted templating systems.

    I happen to like the approach that is used by systems such as Template Toolkit. This system has a moderately-complex meta-language but it's strictly for output-formatting. The “thinking” comes first, then the output-preparation follows. The two are not interleaved.

    In a curious way, I think that the approach you are recommending here does “interleave” these two concerns, in an improper way. It is simply the opposite-extreme: the display-preparation is simply shifted into Perl, and HTML-generation is reduced to a perfunctory, “empty,” non-task.

    The advantage of a good templating system, meta-language and all, is that a graphic designer can completely express a display task, given a description of what information has been pre-arranged into what variables. Meanwhile, the programmer can completely ignore that same display task, his-or-her concern only being to get the right information pre-arranged into the right variables. We all know that most “changes” that are requested, once a site has been first delivered, are cosmetic changes... involving a sometimes-substantial rearrangement and re-presentation of the same data. If what we are re-arranging is, indeed, “the same data,” then a suitably-smart templating system works to our advantage since once again it will be the graphic-designer who's doing most of the work. Changes to the underlying Perl-code are needed only for the new functionality, not to re-arrange the old functionality. I am not of the opinion that this “empty” approach would really allow that.

      the display-preparation is simply shifted into Perl, and HTML-generation is reduced to a perfunctory, “empty,” non-task.
      HTML is empty and a non-task... HTML-generation is not empty at all. How can you call writing methods to manipulate HTML empty?

      and what you call a "simple shift" from pull style to push style is proven to create a more powerful templating system: the weakest push-style system is the strongest pull-style...

      In a curious way, I think that the approach you are recommending here does “interleave” these two concerns, in an improper way. It is simply the opposite-extreme: the display-preparation is simply shifted into Perl, and HTML-generation is reduced to a perfunctory, “empty,” non-task.
      What you call the "opposite-extreme" is actually best practice for data processing: processor and processed are completely separated, allowing flexible object-oriented composition.

      Processing HTML need be no different than best practice for XML, databases, LDAP and so on .

      But I am the person running Wordpress blogs, and drooling over Drupal for all of my personal sites. So while we both agree from a philosophical standpoint on how "WRONG" PHP is, we really both need to shut up and out-deliver. When we have useable web products on par with PHP, then our products can do the talking instead of the idle and empty chatter we are engaging in here.

      I have beheld the tarball of 22.1 on ftp.gnu.org with my own eyes. How can you say that there is no God in the Church of Emacs? -- David Kastrup
      [tag://etl,templating]
      Enforce strict model-view separation in template engines via HTML::Seamstress The car is in the cdr, not the cdr in the car
        PHP's success has little to do with syntax, or model/view interleaving. PHP is successful because it is extremely easy to deploy and offers minimal sandboxing.

        I use CGI perl or mod_perl for all of my web based development. But I would not say that perl is as easy to deploy as PHP. If perl had a simple, more "secure-for-the-average-hosting-provider" sandboxing scheme, then you'd see perl more available and potentially as widely adopted as PHP is.

        A discussion of PHP vs Perl is barely related to a discussion of the merits of template systems.

        my @a=qw(random brilliant braindead); print $a[rand(@a)];
Re: RFC - Template::Empty
by Rhandom (Curate) on Feb 25, 2008 at 16:32 UTC
    It seems that there is always a knee-jerk reaction to not having control flow in your HTML - and sometimes rightfully so. I very often see posters decrying systems such as Template::Toolkit because it has its own language - which it does - which may or may not be a problem. But that is a separate issue from that introduced by the Tal, Seamstress, and now the "Empty" concept.

    The problem introduced by Tal, Seamstress, this new "Empty", and sometimes even HTML::Template with its "LOOP" construct - is that the Perl code has to know too much about the template.

    Obviously the Perl code has to know which variables the template is going to need. However the Tal and Seamstress models go a little further - the Perl code for these has to know a little (sometimes a lot) about how the template is going to present the data. We've made sure the logic is out of the presentation layer - but now we've made the code layer manipulate the presentation layer. I think this is worse than having control flow in the template.

    The nice thing about template systems with at least a minimal amount of language capability (such as Template::Toolkit) is that my Perl layer can generate data and pass it to the presentation layer. The presentation layer is then free to manipulate the data into a form suitable for presentation.

    In the end, it really is developer preference. But for myself I've found that Template::Toolkit syntax and particularly Template::Alloy (which I authored) if used properly are the perfect separation between model and view. And it is the perfect separation from both directions.

    my @a=qw(random brilliant braindead); print $a[rand(@a)];
      it was rhandomly stated:
      but now we've made the code layer manipulate the presentation layer. I think this is worse than having control flow in the template. I've found that Template::Toolkit syntax and particularly Template::Alloy (which I authored) if used properly are the perfect separation between model and view. And it is the perfect separation from both directions.
      If you would like to come up with an empirical measure of "perfect" or give examples which show how Alloy is better than Seamstress, I will be more than happy to provide fully working Seamstress counterparts.

      You chief expressed concern is:

      but now we've made the code layer manipulate the presentation layer.
      I dont know what a "code layer" is... please tell me what a code layer is, preferably with an example showing how horrible it makes the seamstress experience.

      for me, dynamic html consists of:

      accessing the model and storing it in an iterator or in-memory data structure

      my $records = Data::Object->load(welcome_data => $cookie->user) ;

      accessing the view and storing in a seamstress object (a subclass of HTML::Tree)

      my $tree = html::welcome->new;

      executing presentation logic

      $tree->replace_content(user_name => $records->[0]{user_name});
      That is clear, clean and simple and allows maximum independence of HTML developer and Perl programmer... I have zero need to touch the HTML. and complete ability to swap model loading and presentation logic using any of a number of object oriented techniques...
      I have beheld the tarball of 22.1 on ftp.gnu.org with my own eyes. How can you say that there is no God in the Church of Emacs? -- David Kastrup
      [tag://oop,html,templating]
      Enforce strict model-view separation in template engines via HTML::Seamstress The car is in the cdr, not the cdr in the car
        Thanks for the softball.

        Here is your job. I will give you an array of text strings. Without manipulating the data in the perl layer, please provide one template that shows them in a bullet list and another template that shows them in a table with three columns with data oriented in columns with one item per cell. On the column oriented version fill in &nbsp; wherever there isn't a defined value. Be sure external whitespace is nice and consistent.

        For extra credit - make the template decide conditionally that if you have less than n items use the bullet list - otherwise use the table.

        For extra extra credit - do this exercise - but do it in a text-only based email that will be sent to a user (ie - no html tags).

        ----- bullet.tt --------- <ul> [%- FOREACH i IN items %] <li>[% i %]</li> [%- END %] </ul> ----- columns.tt -------- [%- cols = 3; rows = items.size div cols; rows = rows+1 IF items.size % cols %] [%- FOR i IN [0 .. rows - 1] %] <tr> [%- FOR j IN [0 .. cols -1] %] <td>[% items.${ i + rows * j } %]</td> [%- END %] </tr> [%- END %] </table> ------ optional.tt [% PROCESS ${ items.size > 10 ? "columns.tt" : "bullet.tt" } %] ------ my_perl.pl ------ use Template::Alloy; my $t = Template::Alloy->new; my $data = { items => [1 .. 10], }; $t->process("bullet.tt", $data) || die $t->error; $t->process("columns.tt", $data) || die $t->error; __END__ prints <ul> <li>1</li> <li>2</li> <li>3</li> <li>4</li> <li>5</li> <li>6</li> <li>7</li> <li>8</li> <li>9</li> <li>10</li> </ul> <table> <tr> <td>1</td> <td>5</td> <td>9</td> </tr> <tr> <td>2</td> <td>6</td> <td>10</td> </tr> <tr> <td>3</td> <td>7</td> <td>&nbsp;</td> </tr> <tr> <td>4</td> <td>8</td> <td>&nbsp;</td> </tr> </table>


        Update To me the code layer would be your perl modules and your cgi script (or your mod_perl application). The example given is simplified and contrived - but represents real life situations.
        Update 2 s/specifying/manipulating the data/

        my @a=qw(random brilliant braindead); print $a[rand(@a)];
      The problem introduced by Tal, Seamstress, this new "Empty", and sometimes even HTML::Template with its "LOOP" construct - is that the Perl code has to know too much about the template.

      In TAL, Perl builds the data and TAL renders it. Quite like TT but just with less generality built into the template language (generality that often just gets you into trouble). If you need to transform data for display (eg reorient a table, turning rows into columns and vice versa), the template can actually call out to perl helpers. This continues the separation of coding and presentation while giving almost as much flexibility as having a fully programmable template language.

      However the Tal and Seamstress models go a little further... now we've made the code layer manipulate the presentation layer.

      This is just simply not true at all, the perl layer cannot manipulate the presentation layer, TAL is nothing like Seamstress or Empty in this respect.

      The second comment makes me wonder if you actually know TAL at all. Perhaps you have been misled by the comments above into thinking that it is similar to Seamstress and Empty.

        This is just simply not true at all
        You are very right and I am very wrong. To a point.

        I was very wrong about the model of TAL which seems to be implemented more along the lines of TT or HTML::Template - just with an XML based mini language.

        However, the process of calling back in to the perl layer in order to reorganize your data frames TAL in the light that I was mentioning before and is why I also indicated that HTML::Template also falls into that level. If you want the data in a different form - you HAVE to call into perl on TAL and HTML::Template. Seamstress doesn't give you the option - so you have to manipulate your data before hand.

        In TT and Template::Alloy - you can call into perl to manipulate your data - but the language has enough flexibility that you don't have to.

        my @a=qw(random brilliant braindead); print $a[rand(@a)];
Re: RFC - Template::Empty
by perrin (Chancellor) on Feb 25, 2008 at 17:07 UTC
    I covered a few people's attempts at this in my Choosing a Template System essay. My favorite example of this type is the now defunct HTML_Tree. It never really caught on. There have been other tries in Java, like XMLC. They also failed to gather a large following. Most people stayed with things like JSP and Velocity.

    I think the reality is that DOM-based HTML manipulation gets cumbersome for complex templates. It also ties your code very tightly to the presentation. Manipulation based on HTML ID attributes works better, since the code no longer has to know as much about where they are. Petal and Template::TAL are XML-friendly but don't seem to offer more separation than Template Toolkit and the like, i.e. the XML they use is just another template language.

    So, if you want to pursue this, I'd suggest moving away from the DOM-like approach in your example and going to something more like HTML_Tree, HTML::Seamstress, and XMLC.

      I covered a few people's attempts at this in my Choosing a Template System essay.
      Well..... every system you cover falls into the models you describe in your overview - pipeline or callback. Seamstress and XMLC do not fit into either of those categories. Both pipeline and callback are pull-style. XMLC and Seamstress are push-style.
      My favorite example of this type is the now defunct HTML_Tree. It never really caught on.
      There is a book called "The Outsider" by Colin Wilson which explains things like this. Some things are not supposed to catch on... take a look at the bell curve and it would be clear why... Einstein did not catch on.. Dvorak did not catch on...
      There have been other tries in Java, like XMLC. They also failed to gather a large following.
      XMLC is a pretty solid project. Sure, it's a minority product, but it is the presentation layer of the Enhydra Application Server. . It is also used in the Barracuda MVC framework. And finally Sams published a book on it.

      I would agree that it does not have a _large_ following. But it definitely is a proven industrial strength technology, with active development and user base over 6 years. Not only that, but they use DOM to do it... Java people seem to handle verbosity much better than us Perlers.

      Most people stayed with things like JSP and Velocity.
      I would agree with you. But staying with something doesnt mean it's better. It could be for legacy reasons, familiarity reasons, etc.

      I think the reality is that DOM-based HTML manipulation gets cumbersome for complex templates.
      well DOM _is_ cumbersome.. HTML::Tree is a very Perlish DOM. a very slick product indeed. All hail Sean Burke for a job more than well-done. And Python has some very slick XML mungers, 4suite for instance is incredibly elegant for munging XML.
      It also ties your code very tightly to the presentation.
      Now perrin what do you mean by that? If the code is supposed to present something, then of course it is tied to it. :) But again, you are using "your code" in the same vague sense that Rhandom used "code layer" -- both of you speak about it, but provide no examples, either in your replies or link to any document on the web, peer-reviewed or not.

      Do me a favor and demonstrate the flaws. All through this thread, I am providing CODE to back up the seamstress approach. I need you two to meet me on that practical level, not verbal theoretical level.

      So, if you want to pursue this, I'd suggest moving away from the DOM-like approach in your example and going to something more like HTML_Tree, HTML::Seamstress, and XMLC.
      HTML_Tree is not like Seamstress or XMLC. HTML_Tree is like Petal.

      Petal and Seamstress share one benefit - you are 100% guaranteed HTML which can be viewed with HTML tools with no choking on mini-language constructs. But the approach to use Petal and HTML_Tree (and Data::DRef from back in the day:) is vastly different from XMLC and Seamstress.

      HTML_Tree is pull-style. The other notable push-style thing I've run across besides stringtemplate is meld3 by Chris mcDonough in Python. It is a very nice tool to work with. Too bad it is based on elementtree which is one of the weaker HTML/XML engines for Python.

      I have beheld the tarball of 22.1 on ftp.gnu.org with my own eyes. How can you say that there is no God in the Church of Emacs? -- David Kastrup
      [tag://html,templating,push-style]
      Enforce strict model-view separation in template engines via HTML::Seamstress The car is in the cdr, not the cdr in the car
        But again, you are using "your code" in the same vague sense that Rhandom used "code layer" -- both of you speak about it, but provide no examples, either in your replies or link to any document on the web, peer-reviewed or not.


        I've given an example in an above reply. To be specific. The code layer is the perl layer. It is written in perl and is either modules or cgi script. The presentation layer is either a template file or a template string (yes template strings are useful too - so you can put your template in a database for instance). The code layer picks which template to display and gathers data that the presentation layer may need. But then it is up to the presentation layer to lay it out.

        All of the in house HTML designers I have worked with at any of my jobs have wanted to have the flexibility to manipulate the data so that they page shape could change. I've enjoyed not having to change my perl whenever they've needed to reformat the page.

        Just out of curiosity - what do you use when you need to send a templatized css file, or js file, or text email. To me, the XML/HTML DOM template systems seem to be heavy handed at forcing you to have well formed HTML. HTML is just a subset of what you need to deal with in web development. Do you use multiple template systems - or worse do you try to force css/js/email into the same slot as HTML? I've seen people do this and the templates are usually quite ugly. XML is usually the wrong hammer.

        my @a=qw(random brilliant braindead); print $a[rand(@a)];
        Both pipeline and callback are pull-style. XMLC and Seamstress are push-style.

        "Pipeline" in my essay means that the code is in charge of control flow rather than the template. In a callback style, decisions about what do next are in the template. Seamstress is pipeline.

        The issue I referred to with code being tied to presentation in a DOM approach is that you have to know the structure of the DOM. For example, filling in a variable in a specific paragraph or table requires you to say exactly which paragraph or table cell to fill. You have to write code like this:

        $node->children()->[0]->text( $flavor_name );

        If you use ID or CLASS attributes on the HTML tags instead, you can move them around without changing your DOM calls. I don't think we disagree, since your examples all use ID or CLASS attributes, not DOM location. You probably just have a different name for what I call DOM manipulation, like maybe XPATH.

        HTML_Tree is not like Seamstress or XMLC. HTML_Tree is like Petal.

        I don't see how. Petal embeds a programming language in XML files. HTML_Tree and Seamstress and XMLC all use ID and CLASS attributes to specify parts of an HTML file to replace or modify without embedding loops or conditionals in the template itself. (HTML_Tree can use XPATH-like code if you choose to, and I suspect the others can too, but that would be a bad idea for most situations.)

      Thanks for the essay link, it has been a while since I have read it so it sounds like I am due for a review.

      The code is tied tightly to the presentation with this approach, but the problem I have seen with template code becoming too programmatic gets you to the same place, just a different route (and language).

        The code is tied tightly to the presentation with this approach,
        redhotpenguin, what do you mean? Is what you state above a problem? Can you document a case where this leads to issues? Give me one web link or code sample showing this to be a problem. If you know Perl OO, you can decouple, slice, dice, flip, saute your Perl code to the presentation... Perl is liquid my man. Drink every drop. It will never fail you. It has a user base well into the hundreds of thousands. It has been around for more than a decade. And has solved IT problems in every domain under huge time pressure.

        Put your faith in the real solid rock and be happy.

        I have beheld the tarball of 22.1 on ftp.gnu.org with my own eyes. How can you say that there is no God in the Church of Emacs? -- David Kastrup
        [tag://fanatic,perl,propaganda]
        Enforce strict model-view separation in template engines via HTML::Seamstress The car is in the cdr, not the cdr in the car
Re: RFC - Template::Empty
by sundialsvc4 (Monsignor) on Feb 25, 2008 at 17:51 UTC

    One viewpoint that I think is relevant here is to consider ...

    • Okay, you did not write this code. You're going to have to “ramp up” on it. Now, implement this extensive but wholly-cosmetic change. By tomorrow.

    When you are given that sort of task, it really drives home the nature of the coupling that necessarily must exist (somewhere, and at some level) between the presentation and the underlying data. What may appear to be “elegant” might turn out to be unmanageable, and if that is the case we have created an unnecessary problem for ourselves.

    The person who is presented with this challenge is actually faced with three familiar challenges:

    1. Figuring out what the existing code does.
    2. Devising and executing changes to the code, to make it meet the new requirements.
    3. Testing the new code to make sure that it fulfills all of the new requirements but did not regress.
    If unwanted “coupling” has been introduced for any reason – “elegance” or otherwise – then we have created a very serious problem for ourselves. The amount of real-estate that our programmer must consider, must change, and must be careful not to break, could be extensive. If he or she is forced to make corresponding changes in two or more files at the same time, the probability of error is substantially increased.

    Knowing this, if it were my project to architect and/or to manage, I would press very, very hard upon this topic. In fact, I might “spring” a request just like this one upon the team ... entirely without warning ... (yeah, I'm one of those) >:-D ... to actually convince myself that the strategy is not going to collapse into unmaintainability. Mind you, I'm not saying that it de facto would collapse, but I'd be pressing hard for a solid demonstration that my gut-feelings on the matter were unfounded.

Re: RFC - Template::Empty
by leocharre (Priest) on Feb 27, 2008 at 18:49 UTC

    I think the idea of targetting the title tag as a place holder because it has no content is pretty neat!

    I don't aggree with some of the other things said here- I suggest some of us may be missing the point- if I understand it properly.

    It is that no funny code needs to be introduced. At all.No funny id attributes, no <TMPL_VAR FEEDME> tags..

    Am I to understand that we can target the the value for 'username' input field because it has no value?

    The syntax you suggest seems to call for some crazy autoloading, (which i would suggest against, because if this actually worked out, I would personally use it in cgi, and it would maybe screw up resources- yes, for what i do, yes. ).

    If I get the idea right, I think it's sexy. Implementing this and spreading it.. might be an ungrateful demon child who will never ever say please or thank you.

    I think refining the concept, before the code - is key. Start a blog or something with the idea.

    Is it worth it? This will be a real issue. This whole thing seems pretty simple an idea. That's how you know it could be hell hours and bugs galore.

    I adore HTML::Template. Let me emphasize that.. i love HTML::Template. And I gotta tell ya, the system you suggest is the only thing that tempts me to deviate.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://669956]
Front-paged by tye
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (4)
As of 2014-07-26 15:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (178 votes), past polls