Meditations On HTML In Perl

Replies are listed 'Best First'.
Re: Meditations On HTML In Perl by abell (Chaplain) on Dec 04, 2002 at 11:24 UTC
I think the trick is using a templating system that allows you to use perl in it. This way, you can embed presentation logic in the presentation docs (templates) and keep the application logic clean. In a typical web app you can manage the information flux like this: --------- ------- --------- ------- ---------- \| REQUEST \| --> \| DISP. \| --> \| APPLIC. \| --> \| PRES. \| --> \| RESPONSE \| --------- ------- \| LOGIC \| \| LOGIC \| ---------- --------- ------- ^ ^ \| \| v v ------- ---------- \| CLASS \|- \| TEMPLATE \|- ------- \|- ---------- \|- ------- \| ----------- \| ------- ----------- Note: DISP is for dispatcher For templates, I am opting more and more for a mixed system, including ePerl for power and simple substitution/fixed chunks for speed when power is not needed. In a sample case, the application subsystem can generate an object of class PersonList and the presentation subsystem passes it to a template supposed to show name and age of every person in the list. The template contains something along the lines of `<: # get parameter personList # this is the only way the template gets # information from other layers my $pList = param('personList'); :> ... <table> <tr><td><b>Name</b></td><td><b>Age</b></td></tr> <: for my $person ($pList->getAsList()) { print template('personRow')->apply( name=>$person->name, age=>$person->age ); } :> </table>` [download] where template personRow is a simple substitution template of the form `<tr><td><:name:></td><td><:age:></td></tr>` [download] The presentation subsystem can make use of modules and ad-hoc subroutines for automatic generation of HTML, which should not be accessed by the application subsystem. One advantage of this approach is that even if things can get messy with the mixture of Perl and HTML, when something breaks it's easy to find where the error is located. Cheers Antonio Bellezza The stupider the astronaut, the easier it is to win the trip to Vega - A. Tucket	[reply] [d/l] [select]
Re: Meditations On HTML In Perl by dingus (Friar) on Dec 04, 2002 at 13:24 UTC
I think you are right, there is no good way to always ensure that you never have raw HTML in perl. However use of external stylesheets and external javascript libraries do reduce the amount as do templates. What I find is that most of my dynamically generated pages consist of is a common header (and sometimes footer) plus a setion where I want to put dynamically generated content. Typically judicious use of Javascript and DHTML means that even navigational bars are in fact common over all pages. As a result the dynamic content is limited to a couple of otherwise empty DIVs which you can then choose how to fill. Thus it is quite possible to have an external html page which conains everything except one or two two blank DIVs like this: `Standard header cruft including <link rel="stylesheet" href="/some/where/sheet.css" type="text/css"> <SCRIPT LANGUAGE="JavaScript" src="/some/where/library.js"></SCRIPT> <BODY> More cruft <DIV id = 'form'> <!-- insert form here --> </DIV> <DIV id = 'results'> <!-- insert results here --> </DIV> </body></html>` [download] Now you need to be strict about what things output stuff to those sections but my scripts typically enforce that by having a print and exit at the bottom which kind of makes it obvious when something started printing halfway up as the page doesn't display right. `# # doing work up above # open (TPLT, "<$tpltfn") or die "Can't open template. $!"; undef $/; # dosn't matter because we're about to quit; $html = <TPLT>; close (TPLT); print header; # add cookies etc if necessary $formidx = index($html,'<!-- insert form here -->'); $residx = index($html,'<!-- insert results here -->'); print substr($html,0,$formidx), create_form($parameters), substr($html,$formidx,($residx-$formidx)), create_results($other_parameters), substr($html,$residx); exit;` [download] Dingus `Enter any 47-digit prime number to continue.`	[reply] [d/l] [select]
Re: Meditations On HTML In Perl by perrin (Chancellor) on Dec 04, 2002 at 16:48 UTC
What you are describing is one of the main reasons I abandoned hacked in-house templating tools and started using Template Toolkit. I have not yet found any situation that Template Toolkit can't handle without resorting to HTML embedded in the Perl code (or Perl embedded in the template). If you give an example of a problem you've faced, we could suggest ways to solve it with various templating tools.	[reply]
Re: Meditations On HTML In Perl by alien_life_form (Pilgrim) on Dec 04, 2002 at 14:23 UTC
Greetings, The problem lies in fact with HTML. Constructs like <FORM> and siblings do not promote logic-presentation divorce, quite the contrary, in fact. I also tend to be more than a little scared of the DHTML thingy, as it always end up eating into the application logic and to generate templates that, unless handled gingerly, have the capability of breaking the entire application. Cheers, alf You can't have everything: where would you put it?	[reply]
Re: Meditations On HTML In Perl by thraxil (Prior) on Dec 04, 2002 at 18:21 UTC
i've been using HTML::Template for all my CGI scripts for 2 or 3 years now. i probably average several hundred lines of perl per workday. HTML::Template is notoriously simple. all it allows for is simple conditionals and loops; no embedded perl code, no subroutines, nothing. i have yet to encounter a situation that it couldn't handle and i was forced to embed HTML directly in the perl. not once. occasionally you run into situations where it would take 10 seconds to embed the HTML in the perl vs. 1 minute to put it out in a seperate template. the time advantage of directly embedding it is so small that it doesn't really make that much of a difference and using a template almost always pays for itself later on by making maintenance easier. anders pearson	[reply]
Re: Meditations On HTML In Perl by Abigail-II (Bishop) on Dec 04, 2002 at 16:50 UTC
Well, Tk distances you from doing raw Xlib (or whatever is used on non-Unix platforms), but then, so does HTML. Even with Tk, you have to have things like: `$widget -> Label (-text => "Flubber") -> pack;` [download] somewhere in your code. I fail to see why that's a better abstraction than a `print HTML "<p>Flubber</p>";` [download] In fact, I find it easier to separate content from presentation using HTML than using Tk. Stylesheets are cross-platform, but the X options database certainly isn't. Abigail	[reply] [d/l] [select]
Re: Meditations On HTML In Perl by one4k4 (Hermit) on Dec 04, 2002 at 14:14 UTC
I'm not sure if this is really relevant, but I tend to break the HTML out into seperate modules. Same goes with the DB calls. I'm porting an application to PostgreSQL, from MySQL. Really only have to edit one file. Same concept for HTML. I tend to not use the CGI.pm functions, and just write my own. Seems I can get it done quicker. Maybe because of the learning curve that really isn't there, but who knows - I'm too lazy. ;) If anything, I can give the HTML.pm (or whatever it's called) to another HTML developer and say "edit the parts between -here- and -here-, here are the variables you can use... enjoy. Then I can just quickly proofread it and go from there.. _14k4 - perlmonks@poorheart.com (www.poorheart.com)	[reply]
Re: Meditations On HTML In Perl by princepawn (Parson) on Dec 04, 2002 at 15:08 UTC
I would welcome your feedback on HTML::Seamstress Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality	[reply]
Re: Meditations On HTML In Perl by talexb (Chancellor) on Dec 04, 2002 at 21:18 UTC
It seems that no matter how much you try to isolate HTML from Perl, using templates, for example, there are always occasions where it's just not worth the effort. Well, I hate to rain on your parade, but I disagree. I just finished a web application for managing a live and silent auction event, completed with ticketing ahead of time, live item list, and invoicing. Apart from a <div align="center"> that I had to stick in a few of the CGIs, I did the whole thing with `use CGI` and CSS, and I was very happy with the result. I would have been happy if I'd been able to stay away from HTML completely, but for me it worked out fine. (Doing a table with `CGI` is a piece of cake compare to the alternative .. especially escaping all those double quotes (ugh) or using a Here Doc (ugh ugh).) --t. alex but my friends call me T.	[reply] [d/l] [select]
Re: Meditations On HTML In Perl by Ionizor (Pilgrim) on Dec 05, 2002 at 01:38 UTC
I would agree that escaping double quotes in HTML sucks. Instead I usually use `qq` with parentheses or braces. e.g. `print qq(<p>A link to the <a href="test.html">test page</a></p>);`	[reply] [d/l] [select]
Re: Meditations On HTML In Perl by Ionizor (Pilgrim) on Dec 05, 2002 at 01:42 UTC
With the caveat, of course, that JavaScript will break horribly unless you escape your brackets. That brings us back to the original problem or forces us to use a different delimiter.	[reply]
Re: Re: Meditations On HTML In Perl by talexb (Chancellor) on Dec 05, 2002 at 16:02 UTC
Re: Meditations On HTML In Perl by Ionizor (Pilgrim) on Dec 05, 2002 at 20:38 UTC
Re: Re: Meditations On HTML In Perl by BUU (Prior) on Dec 05, 2002 at 02:31 UTC
What the hell is wrong with using single quotes for html attributes? come on people. Ok, it isn't quite valid XHTML/XML, (which i think is stupid..), and if your html is completely valid aside from little errors saying "single quote should be double quote" Then i think you've fufilled everything that xhtml was designed for in the first place. And doing `print "<a href='$foo' style='foo:baz' onClick='stuff'>$xxx</a>"` is infintely cleaner then doing `print "<a href=\\"$foo\\" style=\\"foo:baz\\" onClick=\\"stuff\\">$xxx</a>"`..	[reply] [d/l] [select]
Re^3: Meditations On HTML In Perl by adrianh (Chancellor) on Dec 05, 2002 at 05:55 UTC
What the hell is wrong with using single quotes for html attributes? Because standards are useful only when they're... well... standard :-) And doing print `"<a href='$foo' style='foo:baz' onClick='stuff'>$xxx</a>"` is infintely cleaner then doing `print "<a href=\\"$foo\\" style=\\"foo:baz\\" onClick=\\"stuff\\">$xxx</a>"`.. This is what `qq` is there for. `qq!<a href="$foo" style="foo:baz" onClick="stuff">$xxx</a>!` [download]	[reply] [d/l] [select]
Re(3): Meditations On HTML In Perl by talexb (Chancellor) on Dec 05, 2002 at 16:13 UTC
What the hell is wrong with using single quotes for html attributes? come on people. Ok, it isn't quite* valid XHTML/XML, (which i think is stupid..)* Well, at the risk of sounding like a stand-up comedian, there's three kinds of people in this world, those who can count, and those who can't .. rimshot Thank you, thank you, I'll be here all week, be sure to tip your waitresses, try the veal .. rimshot But seriously .. that kind of cavalier approach to standards is a kind of 'black and white' thing for me. Either you conform to the standard or you don't. Me, I love it when the HTML Validator tells me a page that I've programmed comes out squeaky clean. But then, back in the 80's I was a C developer who wasn't happy until my code was properly indented, and also compiled and linted cleanly. That's just my style. Your style sounds more like 'patch it up, close enough' to me. This is not a personal attack -- I don't know you, so it couldn't be -- it's just an observation that you and I appear to have differing standards in quality. --t. alex but my friends call me T.	[reply]
Re^3: Meditations On HTML In Perl by Aristotle (Chancellor) on Dec 08, 2002 at 13:47 UTC
Tolerance for that "hey, it's close enough now ain't it" attitude is the reason the web is nowadays comprised by 99% invalid HTML, which requires parsers be written with extra intelligence and makes it hard to programmatically extract information from remote pages. Not every kind of laziness is a virtue. Makeshifts last the longest.	[reply]