|
Re: rant on = qw(HTML::Mason Embperl Template etc) ;
by Masem (Monsignor) on Nov 09, 2001 at 07:20 UTC
|
It's neigh impossible to separate perl and HTML completely cleanly, where the HTML designer never has to consider what is coming from perl, nor the perl programmer has to consider what he needs to provide to the designer. At some point, you have to make a concession in the HTML template that you have something coming from perl.
Now, from what I've seen, most template solutions, just like with JSP pages or the like, try to hide what's from perl in HTML comments, such that the designer can build the page without problems. There's got to be an initial session where the perl programmer and the HTML design sit down, and lay out what will go in those comments, but then they can go in their own direction, meeting again when necessary.
I read the Java literature as well, and while there's article after article on JSP and servlets and the like, each one echoes the laments you've given already; you cannot cleanly separate these. Every once in a while someone proposes yet another solution that tries to separate them, but at SOME point there's got to be a comingling of the code.
Maybe what the problem is is not that the templating tools are a problem, but that the way that large groups are designing sites are at fault. You mention that you worry that your HTML wranglers will come in at night, and wreck your template, or changes you make during the day will wreck the hard work the HTML guys have done. Maybe what is needed to have the HTML people and the perl programmers spend more time with each other during the development of pages. Maybe the HTML programmers NEED to understand that some engine is providing the data to them and how that works, and the perl programmers have to provide an API or some 'fixed' expectations of what they will be delivering to the programmers. This way, nearly any template solution will work as long as the envirnoment is working right.
As to your suggestion on an XML template solution, I point out that Template Toolkit 2 is language neutral; while the templating code doesn't merge well with HTML, it can be used to generate any text output, including XML (I believe, even, there's an XML plugin for TT2).
<2>
-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important
| [reply] |
Re: rant on = qw(HTML::Mason Embperl Template etc) ;
by lachoy (Parson) on Nov 09, 2001 at 08:49 UTC
|
This whole discussion of templating systems ranks with editors and operating systems as a matter of style. Clearly, the way Mason does things isn't for you. So it goes. It sure works for lots of other people, so its designers must be doing something right :-)
That said, you might be interested in a Java technology that does much the same thing you discuss but quite a bit cleaner. XMLC allows you to compile an XML (or HTML) document to a Java class, using items specified by 'id' tags as objects in your Java code. No intermingled Java code whatsoever.
The nifty thing about it was that more than any other solution I've seen, the web designers didn't have to know anything about what you were doing in the backend. And because the document is represented as a series of hierarchical objects, you can clone() them, query them for properties and apply those properties to other objects in the document.
For example, one of the most common display elements is a data table with alternating colors. The designer creates the table with a header row and two sample rows for mockup. You grab the colors of the two rows, axe the second row and clone the first row for as many data elements as you require. Once you're done, you can apply the colors to the rows after they've been generated, rather than while you're generating them.
In fact, one of the interesting things this does is get you out of the mindset of having to generate everything all at once in a top-to-bottom fashion as most other solutions require.
Anyway, I bring this up merely to have something else to think about and throw into the mix. As if we don't have enough solutions already :-)
Chris
M-x auto-bs-mode
| [reply] |
Re: rant on = qw(HTML::Mason Embperl Template etc) ;
by Maclir (Curate) on Nov 09, 2001 at 09:31 UTC
|
While I have yet to digest your complete "rant", I must take exception to your assertion:
in a quality program such as Dreamweaver or Frontpage
I am sorry, but the words "quality" and "Frontpage" are mutually exclusive. Dreamweaver (and most WYSIWYG HTML tools) add so much cruft and overhead to pages it is beyond a joke. | [reply] |
|
|
As a Perl coder, and a Dreamweaver/vim double-teamer, I must correct your assertion. The primary reason I use Dreamweaver is that it doesn't add crap to your HTML; the "RoundTrip HTML" bits in the ads for the product aren't just marketing hype. It _will_ do some farily legit clean-up, upper-casing tags and the like, but it won't plug in stupid tags, or cram just one more javascript function, unless you tell it to. And you can, from one option screen, turn off everything, leaving your code 100% pristine. This is nigh-impossible in FrontPage, from what I hear (I won't go near THAT app with a 50-foot pole.)
It even offers an option like the HTML Tidy program to clean up Word and FrontPage HTML. For those wanting rapid dev on the HTML side, concentrating on writing Perl code, Dreamweaver works very well.
----Asim, known to some as Woodrow.
| [reply] |
|
|
Dreamweaver (and most WYSIWYG HTML tools) add so much cruft and overhead to pages it is beyond a joke.
Preach it, brother Maclir. There are designers, and there are HTML jockies (and then there are those of us who are both :). No HTML jockey I know would be caught dead letting FrontPage or DreamWeaver near his markup.
--
man with no legs, inc.
| [reply] |
|
|
Wow, I thought Dreamweaver was good about this. Certainly it is much better than Frontpage.
But anyway, as long as the browser can display it, I don't care how unacceptable it is to an HTML expert like you...
but tell me something: do you want your HTML split across a bunch of components so that you can no longer edit an HTML document? How would you deal with something like that?
| [reply] |
|
|
|
|
|
|
|
|
I completely concur re Frontpage. It is a vile piece of dreck with insures that only Frontpage weenies can ever touch that web page again.
As for Dreamweaver... I completely disagree. I started writing HTML eight years ago, and have since tried an assortment of WYSIWYG HTML tools. Dreamweaver is the only one I would even consider using (and do). The level of cleanliness (at least, for the simple to medium-complexity stuff I do) is comparable to that of my own, hand-tuned code. To be sure, it does take some, minor effort of setting it up properly in the first place, and diligence in alt tags and similar Good Code, but those are mostly all things that I'd have to do in vi either. Did I mention that you can directly edit the HTML in DW and it will not second-guess you?
About the worst I'll give you is that it uses <p> and </p> tags, and probably has more whitespace/indentation than I use on my own. For the sake of clarity, I think I can stand that.
Of course, I personally find it really hard to beat the Dreamweaver-Fireworks integration. Vector-based graphics are yummy, and 'Export slices to Dreamweaver,' is totally killer. Sadly, lately it's been more about the pretty pictures than the content. Been bizzy.
| [reply] |
|
|
About the worst I'll give you is that it uses <p> and </p> tags,
Actually, if you look at the latest XHTML standard, you need the </p> tag to terminate each paragraph, assuming you want you HTML to be compliant.
| [reply] |
Re: rant on = qw(HTML::Mason Embperl Template etc) ;
by ajt (Prior) on Nov 09, 2001 at 14:01 UTC
|
++ to you!
I can't agree with you enough. While the various technoloies you mention have their strengths, and work fine, the fact that they mix HTML and code like PHP or JSP makes them in my view impure, impracticle and unscaleable.
Screamer in this thread, I am about to write my very own templating module.., raises many of the same issues. I agreed then, and I agree now, that mixed code and markup is bad, and should not be done.
I have built my own application that delivers XSLT like templating, and it does separate code from HTML, you can use any XML aware HTML editor to work on the HTML. It can make calls to any scripting language - though naturally I mostly make calls to Perl. It's designed to be simple, and I'm evaluating if it's worth keeping or upgrading to AxKit which may be a more sensible long term solution.
My humble 2p
| [reply] |
|
|
If I may add a shameless plug to my humble selfwritten programm w3make...
It takes a tree of XML documents pushes them through an XSLT engine (currently saxon) and yields a whole site of html pages, can copy things around and call more shell commands. Of course it has it's flaws but it comes close to what I feel like maintaining a small- oder midscale site
It is my expression of what I felt about all the systems I looked at when it was -once again- time to relaunch the website of my employer: none of them fitted my visions.
I wrote this small because it is one of those shameless plugs...
| Regards... |
Stefan
|
|
you begin bashing the string with a +42 regexp of confusion
|
| [reply] |
Re: rant on = qw(HTML::Mason Embperl Template etc) ;
by brother ab (Scribe) on Nov 09, 2001 at 15:03 UTC
|
As for HTML designers that use Dreamweaver - for my experience they feel quite comfortable about HTML::Mason. I have explained them that mason-components are like their own Dreamweaver library items, but much more powerfull and they ate this :) Your example of "bad component" could be titled "bad library item" or so because it has nothing mason or even perl specific, it is an example of ugly decomposition of a page.
Be sure, it is possible for designer to learn something about Mason or ColdFusion or ASP or JSP or what-else-those-programmers-use. Don't hide too much from them or they'll lose logic of your application. Yes, they are not just page designers, the are a part of a team that creates something bigger than these pages.
--
brother ab
| [reply] |
Re: rant on = qw(HTML::Mason Embperl Template etc) ;
by count0 (Friar) on Nov 09, 2001 at 23:41 UTC
|
What about HTML::Template? Of all these types of modules for separating HTML from Perl, this seems to be the most successful at it (IMO).
HTML::Template templates even work with WYSIWYG editors. (when wrapped in html comments: <!-- <TMPL_VAR NAME="foo"> --> for example)
The html designer only has to worry about a small number of extra tags, which can be easily documented. These tags are even very non-Perl'ish, and eye-friendly to your average HTML guy/gal.
So, what is it about HTML::Template that isn't bringing it to the horizon? | [reply]
[d/l] |
|
|
What about HTML::Template?
This is one of those questions that I would give 10 upvotes to if I could. You would think that since I wrote
this node giving high praise to
HTML::Template that I would have looked at iit harder before embarking on my glory run with HTML::Seamstress
What happened is I read perrin's seminal article on template system comparisons and ran across on called HTML_Tree, which at the time was on CPAN. But he removed his module from CPAN so I wrote an equivalent which was an improvement over it (as I saw it) in a number of ways.
Now, I plan to drop my HTML::Seamstress project and join the HTML::Template camp... I guess I opted for the vi of template systems even though I use Perl and Emacs, which are the swiss-army chainsaws in their respective classes... heheh.
But for the record, seamstress could compile it's template to executable perl programs. Also, seamstress methods are closer tied to HTML::TreeBuilder and HTML::Element so that HTML manipulations were programmatic and structural as opposed to string-based.
Also, I intentionally left out an include statement, so that this would be forced on HomeSite, Dreamweaver, what have you.
But you just have to do things slightly different with HTML::Template. But I feel that HTML::Template does offer what Seamstress offers albeit with a slightly different API. But given it's maturity (my god, the caching features!) and popularity it is best to join that school and continue the war again Template and Mason et al.
| [reply] |
|
|
| [reply] |
|
|
One thing I didn't like about HTML::Template (maybe I just didn't understand it enough to come up with a clean solution) was the following.
I wanted to give the HTML developers a set of variables that they could use. They could pick and choose which of the set they wanted to display. It was a snippet of HTML to display the current weather, so they could show "wind speed", "wind direction", "temperature", "humidity", and so on....
I did something like:
$tmpl = HTML::Template->new('filename' => $TEMPLATE);
$tmpl->param('Temperature' => $current->{'Temperature'});
$tmpl->param('WindDirection' => current->{'WindDirection'});
$tmpl->param('WindSpeed' => $current->{'WindSpeed'});
...
print $tmpl->output();
and the HTML developers would ideally be able to select
from those variables and use them like this:
<TABLE>
<TR>
<TD>
<SPAN CLASS="weather-temp">
<!--TMPL_VAR NAME="Temperature"-->°F
</SPAN>
</TD>
</TR>
</TABLE>
But actually what I had to do was put ALL the variables
into the template, and hide them as a comment, otherwise
I would get some error:
<H3>Current weather</H3>
[insert HTML here using a selection of the variables below]
<!--DO NOT REMOVE:<!--TMPL_VAR NAME="Temperature"--><!--TMPL_VAR NAME=
+"PerceivedTemperature"--><!--TMPL_VAR NAME="R
elativeHumidity"--><!--TMPL_VAR NAME="WindDirection"--><!--TMPL_VAR NA
+ME="WindSpeed"--><!--TMPL_VAR NAME="Pressure"
--><!--TMPL_VAR NAME="Visibility"--><!--TMPL_VAR NAME="Icon"--><!--TMP
+L_VAR NAME="IconDescription"-->-->
...
and I just find that extremely ugly. What's more, if your
variables are within a TMPL_LOOP (which I also did a list
of news headlines, so in fact I found myself in that situation), then you have to put
that blob of commented-out TMPL_VARs inside that loop.
Also I found that somehow this setup was confusing to
the HTML designers, so I ended up having to edit the HTML
anyway (maybe that's unique to my situation, though), thus
smashing my dreams of never having to look at the HTML again.
| [reply]
[d/l]
[select] |
|
|
$tmpl = HTML::Template->new('filename' => $TEMPLATE,
'die_on_bad_params' => 0
);
And you'll be good to go.
/\/\averick
perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"
| [reply]
[d/l] |
|
|
HTML and Perl need not commingle in the least bit
by princepawn (Parson) on Nov 09, 2001 at 07:59 UTC
|
Every once in a while someone proposes yet another solution that tries to separate them,
One I am not sitting on my ass and proposing. I have a viable (yet alpha-stage) HTML templating framework,
HTML::Seamstress up for comparision on the very criticisms I raised again Mason in this post. Download it and see for yourself
but at SOME point there's got to be a comingling of the code.
Two
This is not a true statement. Please see
this node for data to the contrary.
| [reply] |
|
|
I understand what you are trying to do: you want a templating system that is SGML happy, so that most HTML jockies don't have to worry about any code; this is certainly a reasonable consideration.
But I believe that while SGML-compliant HTML templates are great, I still think you cannot completely severe some aspects of the code from the HTML. As an example, I took a look at HTML::TreeBuilder node (the second link
above), and see stuff like this:
<td builder="_text::iterator.weight"> @0.1.0.0.5
or going to the docs for HTML::Seamstress, I see this:
<td worker="$s->_text($s->{iterator}->{weight})"> </td>
Great, I could pass these segments to W3C and it will be happy, since there's nothing wrong with extraneous tags. In addition, I would suspect that the HTML writer can build and test their page without processing anything to at least judge what the page will look like before the perl programmer gets their hands on it, particularly in HTML::S's case. But if I was the HTML jockey, I would *still* need to know what the "builder" tag system is and what it implies to design of the page. And if I'm the perl programmer, I've got to make sure that I stick to what I tell that HTML person. Those extra tags and their values, IMO, are still programming code not associated with HTML, and thus there is still comingling going on, but certainly much much less than, say, using CGI's HTML generator functions, or strictly writing the perl app in the templating language of TT2 or HTML::Mason. But even if you look at a simple loop that you'd need to generate a table:
<table supply="$s->_aref($s->load_data)">
<tr> <th>name<th>age<th>weight</th> </tr>
<tr iterator="$s->{supply}->Next">
<td worker="$s->_text($s->{iterator}->{name})"> </td>
<td worker="$s->_text($s->{iterator}->{age})"> </td>
<td worker="$s->_text($s->{iterator}->{weight})"> </td>
</tr>
</table>
You will still need to instruct the HTML person on what, in particular, "$s->{supply}->Next" means. So while you have hidden as much possible perl code from them, it's still there implicitly.
In other words, there's numerous little tricks you can to to continually further split the HTML and the perl (or whatever) coding, however, there always will be a connection between those parts that cannot be severed. And the key to making sure that the HTML and the perl work together along that connection is to make some sort of 'contract' that tells the HTML what to be expecting, no more no less, and what the perl programmers must provide, no more no less. Without this 'contract', then you fall back into the mess of tightly connected perl and HTML code. The contract issue can be easily resolved, certainly, with enough pre-planning and in-progress audits to make sure that the perl programming is prepping what is needed, and the HTML writer is inclued what is given to him. But simply chosing the best template system out there, putting no planning into it, and expecting separate perl and HTML to drop out of it is very naive.
(The same implicit problem exists in any MVC system; in this case, it's the GUI toolkit's API that is the contract that connects all parts with thin, nearly-completely seperable parts, but still connected.)
Now, I will say again that I think using SGML-like markup to embed what you what as indicated by the H::S docs is a good step; again, this should allow HTML developers to wrangle layout without concern for the back end as much as with a system like Mason. And this can be easily applied to XML (also a SGML language), so there's yet another extention.
As a suggestion, I would suggest trying to convert the perl-ish code in the tags into something that can be convert back to perl code, but looking more like VBasic. EG: instead of
<td worker="$s->_text($s->{iterator}->{weight})"> </td>
I'd aim for something like:
<td worker="s.text(s.iterator.weight)"> </td>
<!-- or -->
<td worker="s.iterator.weight:text"> </td>
or at least something that mimics JavaScript than perl, because realistically, HTML designers will be more familar with that than perl.
-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|