|
Re: RFC - Template::Empty
by Corion (Patriarch) 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.)...
| [reply]
[d/l]
[select] |
|
|
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.
| [reply]
[d/l] |
|
|
| [reply] |
|
|
|
|
|
|
|
| [reply]
[d/l] |
|
|
|
|
|
|
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.
| [reply] |
|
|
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
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);
| [reply]
[d/l]
[select] |
|
|
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. | [reply]
[d/l]
[select] |
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. | [reply] |
|
|
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).
| [reply] |
|
|
| [reply]
[d/l] |
|
|
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.
| [reply]
[d/l]
[select] |
|
|
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.)
| [reply]
[d/l] |
|
|
|
|
| [reply] |
|
|
|
|
|
|
Re: RFC - Template::Empty
by sundialsvc4 (Abbot) 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.
| [reply]
[d/l] |
|
|
| [reply] |
Re: RFC - Template::Empty
by Rhandom (Curate) on Feb 25, 2008 at 16:32 UTC
|
| [reply] |
|
|
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.
| [reply] |
|
|
| [reply] |
|
|
|
|
|
|
|
|
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...
| [reply]
[d/l]
[select] |
|
|
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 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> </td>
</tr>
<tr>
<td>4</td>
<td>8</td>
<td> </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)];
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
Re: RFC - Template::Empty
by sundialsvc4 (Abbot) 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: - Figuring out what the existing code does.
- Devising and executing changes to the code, to make it meet the new requirements.
- 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 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.
| [reply] |
|
|
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.
| [reply] |
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.
| [reply] |