RE: HTML::Template
Greetings. On Mon, 19 Aug 2002, Pierre Vaudrey wrote: with the following starnge error (The Title is displayed but not the vignette.gif file) [Mon Aug 19 07:22:24 2002] [error] Missing right curly or square bracket at /Library/WebServer/Documents/perl/vignette.gif line 1, at end of line syntax error at /Library/WebServer/Documents/perl/vignette.gif line 1, at EOF For some reason vingette.gif is being interpreted as a Perl script instead of an image. If (as I suppose) the /perl directory has PerlScript (or relatives) as handler, that is not strange at all... Moving vignette.gif elsewhere should make the problem disappear. Cheers, alf
Re: HTML::Template
Le mardi 20 août 2002, à 09:32 AM, Alessandro Forghieri a écrit : Greetings. On Mon, 19 Aug 2002, Pierre Vaudrey wrote: with the following starnge error (The Title is displayed but not the vignette.gif file) [Mon Aug 19 07:22:24 2002] [error] Missing right curly or square bracket at /Library/WebServer/Documents/perl/vignette.gif line 1, at end of line syntax error at /Library/WebServer/Documents/perl/vignette.gif line 1, at EOF For some reason vingette.gif is being interpreted as a Perl script instead of an image. If (as I suppose) the /perl directory has PerlScript (or relatives) as handler, that is not strange at all... Moving vignette.gif elsewhere should make the problem disappear. Many Thanks !! My problem is fixed . Cheers, alf Pierre Vaudrey email [EMAIL PROTECTED]
Re: HTML::Template
On Mon, 19 Aug 2002, Pierre Vaudrey wrote: with the following starnge error (The Title is displayed but not the vignette.gif file) [Mon Aug 19 07:22:24 2002] [error] Missing right curly or square bracket at /Library/WebServer/Documents/perl/vignette.gif line 1, at end of line syntax error at /Library/WebServer/Documents/perl/vignette.gif line 1, at EOF For some reason vingette.gif is being interpreted as a Perl script instead of an image. This is probably a case of a misconfigured web server, although I don't know enough about your setup to be sure. What happens if you try to load this image separate from HTML::Template, just by typing the URL into your browser? -sam
Re: HTML::Template
Pierre Vaudrey wrote: I'm trying to run the following HTML::Template simple example : [...] Could anybody help me to fix it ? Pierre, you are asking an HTML::Template question at the wrong forum, seems that this is the place where you want to ask this instead: http://search.cpan.org/author/SAMTREGAR/HTML-Template-2.5/Template.pm#FREQUENTLY_ASKED_QUESTIONS __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: HTML Template Comparison Sheet ETA
On Sep 4, 2:46pm, Sam Tregar wrote: [% FOREACH thing = list %] a href="[% thing.url %]"b[% thing.name %]/b/a [% END %] That isn't really much better, in my opinion. It's still too much of a departure from the HTML around it. That's the point. It's not HTML markup so you should make it look distinctive, IMHO. Contrast the above to HTML::Template's TMPL_LOOP list a href="TMPL_VAR url"bTMPL_VAR name/b/A /TMPL_LOOP Barring a little syntax, over which we can agree to differ, that's the same thing as the simpler example Perrin posted: [% FOREACH list %] a href="[% url %]"b[% name %]/a/a [% END %] With a little education an HTML designer can learn to manipulate the template syntax. You'll have to teach them to program before they can deal with a full "foreach" no matter how you dress it up. Nope, I don't agree, FOREACH and TMPL_LOOP are semantically identical in these examples. A -- Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated. [EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Marc D. Spencer wrote: o There are actually 3 groups involved, and separation of function as much as possible allows the three groups to work independently on a project without requiring concurrent editing of the same file. - HTML coders - Behavior (the perl or java code) - Resources (pulling in images or other referenced objects) With the templating options discussed so far, you tie the HTML coders and the perl/java coders to editing the same file. Separation of these two is really key, according to those I asked. The Project Managers like the separation too. I don't think thats the case at all here. We've discussed several solutions, none of which tie the programmer into editing the template file. Thats the whole point of these discussions... o Don't forget localization. None of the existing products that we were able to look at handled localization of templates. Localization must be handled by HTTP accept headers and/or manual overriding. This is handled by Apache - what more needs to be done (I'm not being facetious (sp?) - I'd really like to get more and better answers to this question)? o Virtual hosts are real, and template reuse, especially across VHs, while allowing for VH specific customization (driven by the perl/java or configuration) is a nicety. Do you mean like www.pdamd.com and www.pdare.com ? -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: HTML Template Comparison Sheet ETA
Hi all, On Tue, 5 Sep 2000, Matt Sergeant wrote: Thats the whole point of these discussions... I'm not sure that there's any point to these discussions. Do you think this one could go off-List now? 73, Ged.
Re: HTML Template Comparison Sheet ETA
[EMAIL PROTECTED] (Marc D. Spencer) writes: I have to chime in a little (also noting that we have drifted a bit off the original topic...) While working for a large company as the Chief Architect for the web group I was faced with the same need to investigate template options - within the discussion of Build or Buy. And yes, JSP (and ATG Dynamo) were on the list of potential buy options. I took a novel approach: Since I am an engineer, and can only really think like one, I _asked_ the web designers, and the web technicians, and the programming and management staff what their needs were. I'll summarize as briefly as I can below: o The designers do not like any template structure that uses the angle bracket notation foo. It makes some wysiwyg editors unhappy to see foreign tags, and in the current race to HTML4.0 strict, new tags make the validation tools (which have to be applied pre-template-parsing, of course) unhappy. o There are actually 3 groups involved, and separation of function as much as possible allows the three groups to work independently on a project without requiring concurrent editing of the same file. - HTML coders - Behavior (the perl or java code) - Resources (pulling in images or other referenced objects) With the templating options discussed so far, you tie the HTML coders and the perl/java coders to editing the same file. Separation of these two is really key, according to those I asked. The Project Managers like the separation too. o Don't forget localization. None of the existing products that we were able to look at handled localization of templates. Localization must be handled by HTTP accept headers and/or manual overriding. o Virtual hosts are real, and template reuse, especially across VHs, while allowing for VH specific customization (driven by the perl/java or configuration) is a nicety. We ended up developing our own solution, using mod_perl. By the way, performance tested against ATG's Dynamo, it performed 500 - 700% faster. FWIW. The approach I have taken for some of my clients is to separate the HTML and Perl entirely. The designers/HTML coders just create plain, static HTML, with no strange tags. The pages created are run through a batch script that takes a specification of locations in the page that should be altered in some way, and transforms the entire (static) work-in-progress web site into a preview web site (once the any changes have been verified the contents of the site is then moved to the live site). Elements and attributes can be inserted or deleted, and pages can be transformed into Perl subroutines. Currently locations are specified with ID attributes, but I am intending extending this to use XPath. This keeps the HTML content and Perl code *entirely* separate. As an example, report pages can be created filled with dummy data -- the first row will generally be wrapped in a Perl loop and cells populated with live data at run time and all other dummy data rows deleted. The batch transformation process takes about five minutes for a site with a couple of thousand documents. The system has performed well for us (one site using it is www.nhbs.com). There is an old document about the system on http://www.ford-mason.co.uk/resources/perl/WYSIGASP.html (the system originally carried the moniker WYSIGASP -- what you see is good as a starting point) I intend to update the system and tidy up the documentation and so on once I have got the mod_perl Pocket Reference out of the way. I started work on the system a few years ago now, so I need to think about how it fits in with XML, for example. Andrew -- Andrew Ford, Director Ford Mason Ltd Tel: +44 1531 829900 [EMAIL PROTECTED] South Wing, Compton HouseFax: +44 1531 829901 http://www.ford-mason.co.uk Compton Green, Redmarley Mobile: +44 7785 258278 http://www.refcards.com Gloucester, GL19 3JB, UK
Re: HTML Template Comparison Sheet ETA
"GWH" == G W Haywood [EMAIL PROTECTED] writes: GWH Do you think this one could go off-List now? No; I find it quite useful to help form my own descision on what sort of templating system to use with mod_perl apps.
Re: HTML Template Comparison Sheet ETA
Vivek Khera wrote: "GWH" == G W Haywood [EMAIL PROTECTED] writes: GWH Do you think this one could go off-List now? No; I find it quite useful to help form my own descision on what sort of templating system to use with mod_perl apps. I'm also finding it useful. There have been many useful ideas/concepts thrown about that I intend to use in the template comparison. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: HTML Template Comparison Sheet ETA
On Tue, 05 Sep 2000 10:39:37 -0400, Drew Taylor wrote: I'm also finding it useful. There have been many useful ideas/concepts thrown about that I intend to use in the template comparison. Seconded. Lots of useful stuff in this thread, and has been giving me a lot of information about other ways of handling templating other than the way I am doing it now (embedded scalars with HTML). Thanks to all for the great discussion. Brgds, Mike.
Re: HTML Template Comparison Sheet ETA
Hi all, On Tue, 5 Sep 2000, Drew Taylor wrote: "GWH" == G W Haywood [EMAIL PROTECTED] writes: GWH Do you think this one could go off-List now? No; I find it quite useful to help form my own descision on what sort of templating system to use with mod_perl apps. I'm also finding it useful. There have been many useful ideas/concepts thrown about that I intend to use in the template comparison. OK, you win, I'm outvoted. 73, Ged.
Re: HTML Template Comparison Sheet ETA
"G.W. Haywood" wrote: Hi all, On Tue, 5 Sep 2000, Drew Taylor wrote: "GWH" == G W Haywood [EMAIL PROTECTED] writes: GWH Do you think this one could go off-List now? No; I find it quite useful to help form my own descision on what sort of templating system to use with mod_perl apps. I'm also finding it useful. There have been many useful ideas/concepts thrown about that I intend to use in the template comparison. OK, you win, I'm outvoted. I will say that the topic has greatly veered from the original subject. How about we continue the discussion with appropriate subject lines? At least it will be easier to scan the messages. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: HTML Template Comparison Sheet ETA
There are several points that we should consider before we can succesfully compare different templating systems. Performance, Ease of use, Code maintainability, Learning curve and the "Programming eficiency" (lines of code you have to write to have your job done) are some (good?) examples. A compromisse between performance/eficiency/ease of use is common. []s Nelson __ Nelson Ferraz Insite - Solucoes Internet e-mail: [EMAIL PROTECTED] http://www.insite.com.br/
Re: HTML Template Comparison Sheet ETA
To which HTML::Template responds: "Sure you know Perl, but does the HTML
designer you're working with?" HTML::Template has a simple, HTML-esque
syntax for its template files that is aimed at HTML designers.
I still think that this:
? foreach $name (@names) { ?
Name: ?=$name? P
Job: ?=$job{$name}? P
? } ?
Is cleaner (well, as much as perl can be :-)) than this:
TMPL_LOOP NAME=EMPLOYEE_INFO
Name: TMPL_VAR NAME=NAME P
Job: TMPL_VAR NAME=JOB P
/TMPL_LOOP
And the first one has two major advantages: 1) requires less code in the
Perl modules and 2) allows designers to know how Perl looks like.
Keep the
Perl in your modules and keep the HTML in your template files. Go the
other direction and soon enough you've got your programmers changing
font colors.
I'd rather putting all the formatting information in a CSS file...
I agree that one shouldn't put lots of code inside of a template, but
variables and loops are better expressed in Perl than in a "little
crippled language".
Nelson
__
Nelson Ferraz Insite - Solucoes Internet
e-mail: [EMAIL PROTECTED] http://www.insite.com.br/
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Nelson Correa de Toledo Ferraz wrote: I agree that one shouldn't put lots of code inside of a template, but variables and loops are better expressed in Perl than in a "little crippled language". You and I are programmers and we agree. However once you move to a larger shop where you'll find non-programmers editing templates, the HTML-ish loop looks more sensible than an entirely new language, unfortunately. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: HTML Template Comparison Sheet ETA
"Nelson" == Nelson Correa de Toledo Ferraz [EMAIL PROTECTED] writes: Nelson And the first one has two major advantages: 1) requires less Nelson code in the Perl modules and 2) allows designers to know how Nelson Perl looks like. Is this a codeword for "share our pain"? :) Perhaps any HTML Template Comparison sheet should also show how to write a loop like that... I know Template-Toolkit would be a syntax somewhat in between the two, for example, while Mason would be more Perl-like. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: HTML Template Comparison Sheet ETA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4 Sep 2000, Randal L. Schwartz wrote: Nelson And the first one has two major advantages: 1) requires less Nelson code in the Perl modules and 2) allows designers to know how Nelson Perl looks like. Is this a codeword for "share our pain"? :) Perhaps any HTML Template Comparison sheet should also show how to write a loop like that... I know Template-Toolkit would be a syntax somewhat in between the two, for example, while Mason would be more Perl-like. I've been working with JSPs lately, and I'd use something like: jsp:useBean name="someIterator" type="java.util.Iterator" dadadada:iterator iterator="%= someIterator %" table tr thName/th thAddress/th /tr dadadada:iteratorLoop id="x" type="dadadada.someapp.SomeBeanClass" tr tdjsp:getproperty name="x" property="name" //td tdjsp:getproperty name="x" property="address" //td /tr /dadadada:iteratorLoop /table /dadadada:iterator Which is close enough to HTML that the HTML people should understand it. You never really have to "break character" while writing presentation pages. I prefer the custom tags approach to the embedded code approach.. See, in Java you're better off having a servlet set up the 'beans' for the JSP, and then invoking the 'dumb' JSP to present them. The logic is in the servlet, and the JSP imports the results with useBean statements. The designers never have to tiptoe around the logical work, they only edit the JSP files. That said, I am a mod_perl novice, and I don't know if there's anything equivalent or better than this in the mod_perl world. - -- "The Funk, the whole Funk, and nothing but the Funk." Billy Donahue mailto:[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE5s77o+2VvpwIZdF0RAtJPAKCRu9QU+Kqvib1ehQ/x1T4X/n3rGgCgm2AO U5w8Hl8SrWK0jPV98QRNELA= =6vfU -END PGP SIGNATURE-
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Billy Donahue wrote: I've been working with JSPs lately, and I'd use something like: jsp:useBean name="someIterator" type="java.util.Iterator" dadadada:iterator iterator="%= someIterator %" table tr thName/th thAddress/th /tr dadadada:iteratorLoop id="x" type="dadadada.someapp.SomeBeanClass" tr tdjsp:getproperty name="x" property="name" //td tdjsp:getproperty name="x" property="address" //td /tr /dadadada:iteratorLoop /table /dadadada:iterator Which is close enough to HTML that the HTML people should understand it. You never really have to "break character" while writing presentation pages. I prefer the custom tags approach to the embedded code approach.. See, in Java you're better off having a servlet set up the 'beans' for the JSP, and then invoking the 'dumb' JSP to present them. The logic is in the servlet, and the JSP imports the results with useBean statements. The designers never have to tiptoe around the logical work, they only edit the JSP files. That said, I am a mod_perl novice, and I don't know if there's anything equivalent or better than this in the mod_perl world. Well to stick the AxKit oar in, yes, of course there's something better... In AxKit your developers design custom "taglibs" that allow you to design your own tags however you want them to appear. There's a built in taglib for SQL, which allows you to produce XML from a DBI database, but writing taglibs is relatively easy. Once you've written the taglib, its just a drop-in component that your designers can use. And they don't need to know anything about these vegetables you speak of... :-) -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: HTML Template Comparison Sheet ETA
At 11:26 AM 9/4/00 -0300, Nelson Correa de Toledo Ferraz wrote: I agree that one shouldn't put lots of code inside of a template, but variables and loops are better expressed in Perl than in a "little crippled language". Your example makes perfect sense to me. But that's why I'm in "Tech" and not "Creative". I wrote my own quick 'n nasty templating package a few years ago that allowed Perl code to be embedded inside PERL/PERL brackets. So long as I was coding the pages, it worked great, if not as efficiently as embperl or mason. But in the real world of NYC new media, Creative typically drives the project. It's more common for the site to be built by artists and HTML sitebuilders, not programmers. The first time I see the pages is when they get handed off to Tech to glue it all together. This usually happens sometime past Tech's scheduled hand-off date, i.e. five days to do fifteen budgeted days' work in order to make the launch date. I had more success with Sam's HTML::Template package. The sitebuilders seemed to better understand how to work with its simpler concept, although I had to stay away from HTML::Template's looping constructs for the same reason. No doubt, if there had been better communications and coordination between Tech and Creative and I'd had more hands-on input on what Creative was doing to those templates I could have eliminated most of the screwups. But in practice, I've found turf warfare to be status quo between Tech and Creative in larger agencies. My favorite anecdote with embedded Perl templates: after a 100-page creative update to an existing site, nothing worked. Turned out that some funky HTML editor had HTML-escaped the Perl code. That was a fun all-nighter. ---[ http://www.magpie.com ]---=oo--- Steve Manes Brooklyn, N'Yawk
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Nelson Correa de Toledo Ferraz wrote:
I still think that this:
? foreach $name (@names) { ?
Name: ?=$name? P
Job: ?=$job{$name}? P
? } ?
Is cleaner (well, as much as perl can be :-)) than this:
TMPL_LOOP NAME=EMPLOYEE_INFO
Name: TMPL_VAR NAME=NAME P
Job: TMPL_VAR NAME=JOB P
/TMPL_LOOP
That's because you're a Perl programmer. The template syntax wasn't
designed for your tastes. It was designed for the HTML designers you will
eventually have to work with - wether while you're actually on the project
or when it moves into maintainance and needs design changes.
And the first one has two major advantages: 1) requires less code in the
Perl modules and 2) allows designers to know how Perl looks like.
1) The more code you put in your modules the better. This promotes code
reuse and better documentation.
2) Say what? Are you running a school or trying to things done? Putting
raw Perl in your HTML isn't helping you designers is any way I understand.
-sam
Re: HTML Template Comparison Sheet ETA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Sep 2000, Matt Sergeant wrote: That said, I am a mod_perl novice, and I don't know if there's anything equivalent or better than this in the mod_perl world. Well to stick the AxKit oar in, yes, of course there's something better... Gheesh! I should have seen that coming!! - -- "The Funk, the whole Funk, and nothing but the Funk." Billy Donahue mailto:[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE5s8ls+2VvpwIZdF0RAipnAJ9NYkWEMK829xZKwCZOCyWWpw70uACglIQU r25PRJGL7DU45NCzNjAs1sk= =qfy/ -END PGP SIGNATURE-
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Matt Sergeant wrote: You and I are programmers and we agree. However once you move to a larger shop where you'll find non-programmers editing templates, the HTML-ish loop looks more sensible than an entirely new language, unfortunately. i used to believe this argument. i was all up on the xslt bandwagon. and then i took the question to our html dept. and they unanimously preferred perl.
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, brian moseley wrote: On Mon, 4 Sep 2000, Matt Sergeant wrote: You and I are programmers and we agree. However once you move to a larger shop where you'll find non-programmers editing templates, the HTML-ish loop looks more sensible than an entirely new language, unfortunately. i used to believe this argument. i was all up on the xslt bandwagon. and then i took the question to our html dept. and they unanimously preferred perl. Unusual bunch :-) Or are you talking about XSLT vs Perl? If so then I'd agree - XSLT is mightily scary compared to a simple HTML template scheme. But infinitely more powerful. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Billy Donahue wrote: Which is close enough to HTML that the HTML people should understand it. You never really have to "break character" while writing presentation pages. I prefer the custom tags approach to the embedded code approach.. See, in Java you're better off having a servlet set up the 'beans' for the JSP, and then invoking the 'dumb' JSP to present them. The logic is in the servlet, and the JSP imports the results with useBean statements. The designers never have to tiptoe around the logical work, they only edit the JSP files. yes! agree! after years of experimenting with different processes and procedures, this is _exactly_ where i'm at.
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Matt Sergeant wrote: In AxKit your developers design custom "taglibs" that allow you to design your own tags however you want them to appear. There's a built in taglib for SQL, which allows you to produce XML from a DBI database, but writing taglibs is relatively easy. Once you've written the taglib, its just a drop-in component that your designers can use. And they don't need to know anything about these vegetables you speak of... :-) heh! the taglib idea originated with jsp, as i recall. i started to write mail to the mason list the other day discussing taglibs and their usefulness in mason... and then i realized that the concept is already fully embodied in mason, with its component structure. really. the syntax is almost totally equivalent. great stuff.
Re: HTML Template Comparison Sheet ETA
brian moseley [EMAIL PROTECTED] writes: i used to believe this argument. i was all up on the xslt bandwagon. and then i took the question to our html dept. and they unanimously preferred perl. Looking for better paid jobs, I'd guess... ;-) -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, brian moseley wrote: On Mon, 4 Sep 2000, Matt Sergeant wrote: In AxKit your developers design custom "taglibs" that allow you to design your own tags however you want them to appear. There's a built in taglib for SQL, which allows you to produce XML from a DBI database, but writing taglibs is relatively easy. Once you've written the taglib, its just a drop-in component that your designers can use. And they don't need to know anything about these vegetables you speak of... :-) heh! the taglib idea originated with jsp, as i recall. No, it originated way before then I think. Sun copied it too. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Matt Sergeant wrote: Unusual bunch :-) don't think so. xslt is overly verbose and complicated, and its model is the inverse of the standard html page. whereas a nice little mason page with some simple embedded perl looks enough like what everybody's used to, to not be big, scary and new. Or are you talking about XSLT vs Perl? If so then I'd agree - XSLT is mightily scary compared to a simple HTML template scheme. But infinitely more powerful. *raises eyebrow* please expand on that last comment.
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, brian moseley wrote: ah. well anyway, it's ubiquitous, and everybody's got it. everybody that counts, anyway, imo. mr bungle redundant .. redundant .. redundant
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Nelson Correa de Toledo Ferraz wrote:
I still think that this:
? foreach $name (@names) { ?
Name: ?=$name? P
Job: ?=$job{$name}? P
? } ?
Is cleaner (well, as much as perl can be :-)) than this:
TMPL_LOOP NAME=EMPLOYEE_INFO
Name: TMPL_VAR NAME=NAME P
Job: TMPL_VAR NAME=JOB P
/TMPL_LOOP
And I still think that:
DIV CLASS="employee_info"
Name: SPAN CLASS="text::name"John Q. Public/SPANBR
Job: SPAN CLASS="text::job"mod_perl guru/SPAN
/DIV
is cleaner still: *pure* HTML (no fake elements) that any web
tool will understand and dummy-content so the page designer can
see the end-product before any code is written.
Another benefit in not mixing any code in the template is that
the web page designer can wake up tomorrow and change the
template to:
TABLE
TR
THName/TH
THJob/TH
/TR
TR CLASS="employee_info"
TD CLASS="text::name"John Q. Public/TD
TD CLASS="text::job"mod_perl guru/TD
/TR
/TABLE
and not a single line of the associated Perl code has to
change. So when either the web page designers or the marketers
(*shudder*) decide that the web page needs some snazzing up,
they can snazz them up all they want and they don't have to bug
the programmers to change anything.
See http://www.best.com/~pjl/software/html_tree/ for details.
(I've got the day off today so I'm gonna try to figure out how
to get this thing submitted to CPAN.)
And the first one has two major advantages: 1) requires less code in the
Perl modules
But that's where the code belongs.
and 2) allows designers to know how Perl looks like.
Web designers don't care what the Perl looks like.
I agree that one shouldn't put lots of code inside of a template, but
variables and loops are better expressed in Perl than in a "little crippled
language".
I agree: Perl should be used to its full ability, but none of it
should be in the template.
- Paul
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, brian moseley wrote: On Mon, 4 Sep 2000, Matt Sergeant wrote: Unusual bunch :-) don't think so. xslt is overly verbose and complicated, and its model is the inverse of the standard html page. whereas a nice little mason page with some simple embedded perl looks enough like what everybody's used to, to not be big, scary and new. Or are you talking about XSLT vs Perl? If so then I'd agree - XSLT is mightily scary compared to a simple HTML template scheme. But infinitely more powerful. *raises eyebrow* please expand on that last comment. I was questioning whether or not your HTML people found Perl easier than some taglib scheme like HTML::Template, or whether you meant they found it easier than XSLT. Now as to why XSLT is infinitely more powerful... Most HTML template schemes are great where the template wraps the content. So you've got basically a HTML page with some places to insert content. This is basically an extension of the SSI concept, and while these schemes have become more powerful, they lack the ability to do really powerful transformations. For example, take a large article. Now with an ordinary "wrapper" template scheme, the article *HAS* to be encoded as HTML, otherwise it just can't be inserted into the template. You can do some fancy things with pre-processing, but then that ends up being in the realm of code again. With XSLT you can markup your article in some XML format, and have explicit programmatic control over how that entire article gets presented, right down to the links and possibly putting in some breakouts, and other stuff. You can do this down to individual attributes. This is called declarative processing, and its the key to XSLT's power, and also provided in a Perl version with AxKit, called XPathScript. And of course just to add to that, declarative processing is not the only way you can do XSLT. You're quite welcome to use the style you are used to, using a single main template with insertion points, but as your source gets more complex you tend to need the declarative processing more. And you can do this in ways far more powerful than CSS can cope with, and not only that, you can do this on the server to generate stuff other than HTML (which is the only thing your CSS is going to work with), such as content for WebTV, or WAP, or PDF. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: HTML Template Comparison Sheet ETA
"Paul J. Lucas" wrote: And I still think that: DIV CLASS="employee_info" Name: SPAN CLASS="text::name"John Q. Public/SPANBR Job: SPAN CLASS="text::job"mod_perl guru/SPAN /DIV is cleaner still: *pure* HTML (no fake elements) that any web tool will understand and dummy-content so the page designer can see the end-product before any code is written. Having placeholder data in there is an interesting benefit. What about conditionals and loops though? Wouldn't they break the "preview" ability? - Perrin
Re: HTML Template Comparison Sheet ETA
That's because you're a Perl programmer. The template syntax wasn't
designed for your tastes. It was designed for the HTML designers you will
eventually have to work with - wether while you're actually on the project
or when it moves into maintainance and needs design changes.
That's a good point, but take a look at Perl itself: it doesn't force you
to be clear, but there are guidelines to make code more readable.
And the first one has two major advantages: 1) requires less code in the
Perl modules and 2) allows designers to know how Perl looks like.
1) The more code you put in your modules the better. This promotes code
reuse and better documentation.
If I want to make something simple, make it simple! For instance:
? for ($min..$max) { ?
OPTION $_
? } ?
2) Say what? Are you running a school or trying to things done? Putting
raw Perl in your HTML isn't helping you designers is any way I understand.
I always try to teach while having things done. Learning a bit of Perl
will help the designers as much as learning "raw HTML" instead of using
just a WYSIWYG tool: they will be more productive.
See you,
Nelson
__
Nelson Ferraz Insite - Solucoes Internet
e-mail: [EMAIL PROTECTED] http://www.insite.com.br/
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Perrin Harkins wrote: "Paul J. Lucas" wrote: And I still think that: DIV CLASS="employee_info" Name: SPAN CLASS="text::name"John Q. Public/SPANBR Job: SPAN CLASS="text::job"mod_perl guru/SPAN /DIV is cleaner still: *pure* HTML (no fake elements) that any web tool will understand and dummy-content so the page designer can see the end-product before any code is written. Having placeholder data in there is an interesting benefit. What about conditionals and loops though? Wouldn't they break the "preview" ability? That is a loop - just a single line of it, thats all. This is the same as Enhydra's XMLC technology. You compile it down to a class that gives you access to attributes named text::name, then you subclass that class (allowing you to recompile the base class at any time and not affect your code) and make it loop however many times you need by manipulating a DOM. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: HTML Template Comparison Sheet ETA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Sep 2000, Paul J. Lucas wrote: And I still think that: DIV CLASS="employee_info" Name: SPAN CLASS="text::name"John Q. Public/SPANBR Job: SPAN CLASS="text::job"mod_perl guru/SPAN /DIV is cleaner still: *pure* HTML (no fake elements) that any web tool will understand and dummy-content so the page designer can see the end-product before any code is written. Another benefit in not mixing any code in the template is that the web page designer can wake up tomorrow and change the template to: TABLE TR THName/TH THJob/TH /TR TR CLASS="employee_info" TD CLASS="text::name"John Q. Public/TD TD CLASS="text::job"mod_perl guru/TD /TR /TABLE Great, as long as there's no loops or anything but straight up text replacement... I don't like this approach at all! Where in your example do you leave room to display an array of employees? What if you need to actually USE the `class' attribute of your HTML element? It's been hijacked! - -- "The Funk, the whole Funk, and nothing but the Funk." Billy Donahue mailto:[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE5s9yF+2VvpwIZdF0RAoZFAKCQ98QYfj+mTSoQb2X+KBCzj6PA2wCgoCfl jZJ0JNmHxQpzfRJ+6GE3W6Y= =/kos -END PGP SIGNATURE-
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Nelson Correa de Toledo Ferraz wrote:
That's because you're a Perl programmer. The template syntax wasn't
designed for your tastes. It was designed for the HTML designers you will
eventually have to work with - wether while you're actually on the project
or when it moves into maintainance and needs design changes.
That's a good point, but take a look at Perl itself: it doesn't force you
to be clear, but there are guidelines to make code more readable.
That doesn't help the designer who has honed his HTML skills and now is
chucked a 500 page copy of "Programming Perl" just to get his job done...
And the first one has two major advantages: 1) requires less code in the
Perl modules and 2) allows designers to know how Perl looks like.
1) The more code you put in your modules the better. This promotes code
reuse and better documentation.
If I want to make something simple, make it simple! For instance:
? for ($min..$max) { ?
OPTION $_
? } ?
To a HTML monkey, all those curly brackets, question marks and dollars are
magical. All you've done is reduce some keystrokes. Looks fine to a perl
programmer, looks like a modem init string to a designer.
2) Say what? Are you running a school or trying to things done? Putting
raw Perl in your HTML isn't helping you designers is any way I understand.
I always try to teach while having things done. Learning a bit of Perl
will help the designers as much as learning "raw HTML" instead of using
just a WYSIWYG tool: they will be more productive.
At Perl? The designers I've met don't want to be more productive in
Perl. They want to get their jobs done, and that involves spending most of
their day in dreamweaver and photoshop (the rest of the time they usually
spend smoking, or discussing last night's "Corrie")...
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Matt Sergeant wrote: I was questioning whether or not your HTML people found Perl easier than some taglib scheme like HTML::Template, or whether you meant they found it easier than XSLT. ah yes. xslt vs mason, specifically. again. With XSLT you can markup your article in some XML format, and have explicit programmatic control over how that entire article gets presented, right down to the links and possibly putting in some breakouts, and other stuff. You can do this down to individual attributes. This is called declarative processing, and its the key to XSLT's power, and also provided in a Perl version with AxKit, called XPathScript. ok, sure. i'm coming from a different place than you are, so i think about the question differently. my application isnt editorial/content driven. the html people are concerned with making the header and footer of the page have our customers' navigation elements; in specifying colors and such. the data that is presented in the content area of our page is fragmented and comes from many disparate data sources. its quite easy to assemble with embedded code, and would be quite unweildy with xslt (i know, i've tried the approach). in general, your point is well taken, and you've even helped me see a use for it inside my system that i hadn't previously seen. but that's still not as an aid to my html people - it's so that i don't have to embed html markup into my message catalogs (where my localized strings come from). perhaps i can use xslt to transform catalog source in xml format to several sets of catalogs, one for html, one for wml. maybe. see below comments. but i still am much more inclined to go with the html template approach for the page's framing elements - which means the artifact that my html people manipulate is still an html page. not an xsl stylesheet. And you can do this in ways far more powerful than CSS can cope with, and not only that, you can do this on the server to generate stuff other than HTML (which is the only thing your CSS is going to work with), such as content for WebTV, or WAP, or PDF. mm, we've found in the real world that a 'one source fits all' transformation simply can't cope with the vast differences between devices. perhaps for simple content presentation its ok, but for a sophisticated application, the flow has to change quite dramatically across devices. it's been more practical for us to use separate sets of jsp templates for each device, with a custom template inheritance mechanism to provide the benefits of sharing.
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Perrin Harkins wrote:
"Paul J. Lucas" wrote:
And I still think that:
DIV CLASS="employee_info"
Name: SPAN CLASS="text::name"John Q. Public/SPANBR
Job: SPAN CLASS="text::job"mod_perl guru/SPAN
/DIV
is cleaner still: *pure* HTML (no fake elements) that any web
tool will understand and dummy-content so the page designer can
see the end-product before any code is written.
Having placeholder data in there is an interesting benefit.
I currently use the .chtml extension to tell Apache to do my
magic (via Files *.chtml). But I often do a:
ln file.chtml file.html
and then I can point my browser at the plain .html version when
I want to see what the mock-up page looks like without executing
any code. In production, I remove the links.
What about conditionals and loops though?
I just got another e-mail about this so I could clarify. There
is no loop that you can see in my example, and this is by design
since HTML doesn't loop.
All of this is explained in the documentaion, but, briefly: the
looping is done under the control of the associated .pm file:
for every HTML file, there is an associated .pm file and that's
where all the code is.
The function bound to the class employee_info tells the HTML
Tree engine that it wants to loop (or not loop) by its return
code.
An example of a conditional:
DIV CLASS="if::do_this"
blah
/DIV
where do_this has to have been already evaluated and the result
stuffed into $this-{ do_this }. But, the "if::" is just a
built-in class (to my module) as a short-cut; you're free to
use your own classes.
The underlying HTML parser is smart enough to "know" what
elements terminate other elements (both explicitly and
implicitly) so it "knows" where the end of the conditional or
loop is.
Wouldn't they break the "preview" ability?
No: for loops, you just get one iteration; for conditionals, you
get the result as if the condition were true.
- Paul
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, brian moseley wrote: On Mon, 4 Sep 2000, Matt Sergeant wrote: To a HTML monkey, all those curly brackets, question marks and dollars are magical. All you've done is reduce some keystrokes. Looks fine to a perl programmer, looks like a modem init string to a designer. i dunno dude. my experience in san francisco is that a) designers and html monkeys are more often than not different sets of people and b) while your comments hold true for designers, html monkeys are often as proficient in js as i am in perl, and they would be mightily offended at your condescending comments. a) I'm in a shitty mood today. Appologies for the HTML monkeys getting in my way today :-) b) We all meet different people. The people I've worked with, even people proficient in Javascript, flip their lid when they get forced to look at things like $_ and regexps when they know of easier systems out there. And I know what SF is like - anyone working in computing there is getting paid a hell of a lot more than the people working in it here (cost of housing not withstanding). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Billy Donahue wrote: Great, as long as there's no loops or anything but straight up text replacement... I don't like this approach at all! What I showed *was* a loop; read my other follow-up. What if you need to actually USE the `class' attribute of your HTML element? You can use it just fine: read the HTML spec. The CLASS attribute is allowed to have multiple values separated by whitespace. - Paul
Re: HTML Template Comparison Sheet ETA
"Paul J. Lucas" wrote: What about conditionals and loops though? Wouldn't they break the "preview" ability? No: for loops, you just get one iteration; for conditionals, you get the result as if the condition were true. Thanks for the explanation. I can still think of situtations in applications I've worked on where there were mutually excusive chunks of HTML that would have looked funny with this approach, but it gets you about 95% of the way towards a previewing system for free. Cool. - Perrin
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Matt Sergeant wrote:
b) We all meet different people. The people I've worked
with, even people proficient in Javascript, flip their
lid when they get forced to look at things like $_ and
regexps when they know of easier systems out there. And
I know what SF is like - anyone working in computing
there is getting paid a hell of a lot more than the
people working in it here (cost of housing not
withstanding).
your point being, they are highly paid so they are ok
looking at perl?
here's one problem. everytime somebody thinks 'embedded
perl' they start thinking about $_ and regexps. when in fact
those constructs are hardly ever used (in my experience) in
display code!
i'll continue to use mason as an example, since that's my
favorite embedded perl system. 98% of my usage is something
like:
% for my $thing (sort @list) {
a href="% $thing-{url} %"b% $thing-{name} %/b/a
% }
or
% if ($something) {
blah blah blah
% }
there are no sophisticated or mysterious constructs in those
examples... and they're hardly contrived! this is the
essence of 'separation of application and presentation':
application logic provides its results in simple, clean data
structures, and display logic uses iterators, conditionals,
and occassionaly simple formatting functions (taglibs!).
it's a hell of a lot sillier, imo, to use a sql taglib to
draw data out of a database while you're processing a
template, than to draw the data FIRST, handling errors and
business logic, and THEN process your template, doing a very
simple merge of template and data.
i argue that for applications, a nice mvc architecture using
templates with embedded perl is a fine, fine choice. for
strict content presentation - little logic other than how to
render a blob of text - your xslt approach is very
reasonable.
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, brian moseley wrote: On Mon, 4 Sep 2000, Matt Sergeant wrote: b) We all meet different people. The people I've worked with, even people proficient in Javascript, flip their lid when they get forced to look at things like $_ and regexps when they know of easier systems out there. And I know what SF is like - anyone working in computing there is getting paid a hell of a lot more than the people working in it here (cost of housing not withstanding). your point being, they are highly paid so they are ok looking at perl? No, they are highly paid because they are highly skilled, generally. it's a hell of a lot sillier, imo, to use a sql taglib to draw data out of a database while you're processing a template, than to draw the data FIRST, handling errors and business logic, and THEN process your template, doing a very simple merge of template and data. Thats not how SQL taglibs work in things like AxKit and Cocoon. The taglib generates a data structure, which gets processed in the next stage of the pipeline (this is more efficient than it sounds, but the efficiency is hidden from the user). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: HTML Template Comparison Sheet ETA
I was trying to stay out of this one, but...
brian moseley wrote:
% for my $thing (sort @list) {
a href="% $thing-{url} %"b% $thing-{name} %/b/a
% }
[...]
there are no sophisticated or mysterious constructs in those
examples...
Just two kinds of data structures, hash de-referencing syntax, and
lexical scoping, and I would probably have passed that list as a
reference too so you'd need to use @{$list}. Embedded perl is
absolutely the best answer sometimes, but don't underestmate the value
of turning your example into this:
[% FOREACH thing = list %]
a href="[% thing.url %]"b[% thing.name %]/b/a
[% END %]
i argue that for applications, a nice mvc architecture using
templates with embedded perl is a fine, fine choice.
Yes, and so is an MVC architecture using templates with a taglib of some
sort. It largely depends on the nature of the project and the people
involved.
- Perrin
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Perrin Harkins wrote: I can still think of situtations in applications I've worked on where there were mutually excusive chunks of HTML that would have looked funny with this approach, but it gets you about 95% of the way towards a previewing system for free. Cool. Yes, in the case of mutually-exclusive sections of HTML, you would get shown both for a preview. (There is also a built-in "unless::" class.) In my experience, it's doesn't crop up THAT often. I'm also not claiming the technique is perfect or right for every possible situation. Some hairy HTML pages can take some head-scratching to figure out how to get the page generated using the technique, but the majority of cases are fairly straight-forward. - Paul
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Perrin Harkins wrote: Embedded perl is absolutely the best answer sometimes, but don't underestmate the value of turning your example into this: [% FOREACH thing = list %] a href="[% thing.url %]"b[% thing.name %]/b/a [% END %] That isn't really much better, in my opinion. It's still too much of a departure from the HTML around it. Contrast the above to HTML::Template's looping: TMPL_LOOP list a href="TMPL_VAR url"bTMPL_VAR name/b/A /TMPL_LOOP With a little education an HTML designer can learn to manipulate the template syntax. You'll have to teach them to program before they can deal with a full "foreach" no matter how you dress it up. -sam
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Matt Sergeant wrote: Thats not how SQL taglibs work in things like AxKit and Cocoon. The taglib generates a data structure, which gets processed in the next stage of the pipeline (this is more efficient than it sounds, but the efficiency is hidden from the user). oh yeah, you're right. ok well, xslt syntax still sucks! :)
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Perrin Harkins wrote: [% FOREACH thing = list %] a href="[% thing.url %]"b[% thing.name %]/b/a [% END %] what's the value? you have to write a parser and then interpret the instructions. that's what eval() is for! and your syntax is no prettier or easier to understand than the perl.
Re: HTML Template Comparison Sheet ETA
According to Steve Manes: At 11:26 AM 9/4/00 -0300, Nelson Correa de Toledo Ferraz wrote: I agree that one shouldn't put lots of code inside of a template, but variables and loops are better expressed in Perl than in a "little crippled language". Your example makes perfect sense to me. But that's why I'm in "Tech" and not "Creative". I wrote my own quick 'n nasty templating package a few years ago that allowed Perl code to be embedded inside PERL/PERL brackets. So long as I was coding the pages, it worked great, if not as efficiently as embperl or mason. But in the real world of NYC new media, Creative typically drives the project. It's more common for the site to be built by artists and HTML sitebuilders, not programmers. The first time I see the pages is when they get handed off to Tech to glue it all together. This usually happens sometime past Tech's scheduled hand-off date, i.e. five days to do fifteen budgeted days' work in order to make the launch date. The real advantage of a 'little crippled language' is that perl itself makes absolutely no effort to keep you from shooting both your feed off at once and you really don't want to let layout people destroy your server with something as simple as a loop that doesn't exit under certain obscure circumstances. Nor do you want to become the only person who can safely make changes. My favorite anecdote with embedded Perl templates: after a 100-page creative update to an existing site, nothing worked. Turned out that some funky HTML editor had HTML-escaped the Perl code. That was a fun all-nighter. HTML::Embperl anticipates this problem and would have kept on working anyway. Les Mikesell [EMAIL PROTECTED]
Re: HTML Template Comparison Sheet ETA
I love this perennial thrash. My 2 cents: don't underestimate the value
of having mobility in the separation of "engineer" and "production" ('HTML
Monkey', as it's been previously referred too, ee ee). Mason's ability to
have components that are all Perl, all FooML or a mix in the two allows
you to decide where to draw that line. I've found that in the real world,
producers have two career paths: one towards design and one towards
technology. I've worked with systems where the technology was rigidly
opaque and there was no way for producers to ease their way into
programming. I've torn down that wall. Simple Perl constructs don't
require careful study of the camel book but if folks _want_ to do
sophisticated things with their data handling, they're not hamstrung
by the constructs of an artificial set of boundaries. That said, I do
insist on having components and classes constructed for re-use -- this is
a concept that even the most novice producer appreciates. And though I'm
not in the business of career counseling, I can (and have) provide a
system that has entry points for anybody in the broad spectrum of skills.
If I want to make something simple, make it simple! For instance:
? for ($min..$max) { ?
OPTION $_
? } ?
2) Say what? Are you running a school or trying to things done? Putting
raw Perl in your HTML isn't helping you designers is any way I understand.
I always try to teach while having things done. Learning a bit of Perl
will help the designers as much as learning "raw HTML" instead of using
just a WYSIWYG tool: they will be more productive.
--
Salon Internet http://www.salon.com/
Manager, Software and Systems "Livin' La Vida Unix!"
Ian Kallen [EMAIL PROTECTED] / AIM: iankallen / Fax: (415) 354-3326
Re: HTML Template Comparison Sheet ETA
"Paul J. Lucas" wrote: And I still think that: DIV CLASS="employee_info" Name: SPAN CLASS="text::name"John Q. Public/SPANBR Job: SPAN CLASS="text::job"mod_perl guru/SPAN /DIV is cleaner still: *pure* HTML (no fake elements) that any web tool will understand [...] Great idea, but just one note; ':' is not legal in CSS class names. In fact, underscores are not even allowed in CSS class names! (Dashes are allowed, however.) ELB
Re: HTML Template Comparison Sheet ETA
Nah You do not want the Perl to look like the HTML at all so the HTML designers aren't confused. Also - why put so much perl into the page at all? [- use mymodule.pm -] Sam Tregar wrote: On Mon, 4 Sep 2000, Perrin Harkins wrote: Embedded perl is absolutely the best answer sometimes, but don't underestmate the value of turning your example into this: [% FOREACH thing = list %] a href="[% thing.url %]"b[% thing.name %]/b/a [% END %] That isn't really much better, in my opinion. It's still too much of a departure from the HTML around it. Contrast the above to HTML::Template's looping: TMPL_LOOP list a href="TMPL_VAR url"bTMPL_VAR name/b/A /TMPL_LOOP With a little education an HTML designer can learn to manipulate the template syntax. You'll have to teach them to program before they can deal with a full "foreach" no matter how you dress it up. -sam
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Eric L. Brine wrote: Great idea, but just one note; ':' is not legal in CSS class names. In fact, underscores are not even allowed in CSS class names! So? They aren't CSS class names. The are in fact legal class names according to the HTML spec. - Paul
Re: HTML Template Comparison Sheet ETA
I have to chime in a little (also noting that we have drifted a bit off the original topic...) While working for a large company as the Chief Architect for the web group I was faced with the same need to investigate template options - within the discussion of Build or Buy. And yes, JSP (and ATG Dynamo) were on the list of potential buy options. I took a novel approach: Since I am an engineer, and can only really think like one, I _asked_ the web designers, and the web technicians, and the programming and management staff what their needs were. I'll summarize as briefly as I can below: o The designers do not like any template structure that uses the angle bracket notation foo. It makes some wysiwyg editors unhappy to see foreign tags, and in the current race to HTML4.0 strict, new tags make the validation tools (which have to be applied pre-template-parsing, of course) unhappy. o There are actually 3 groups involved, and separation of function as much as possible allows the three groups to work independently on a project without requiring concurrent editing of the same file. - HTML coders - Behavior (the perl or java code) - Resources (pulling in images or other referenced objects) With the templating options discussed so far, you tie the HTML coders and the perl/java coders to editing the same file. Separation of these two is really key, according to those I asked. The Project Managers like the separation too. o Don't forget localization. None of the existing products that we were able to look at handled localization of templates. Localization must be handled by HTTP accept headers and/or manual overriding. o Virtual hosts are real, and template reuse, especially across VHs, while allowing for VH specific customization (driven by the perl/java or configuration) is a nicety. We ended up developing our own solution, using mod_perl. By the way, performance tested against ATG's Dynamo, it performed 500 - 700% faster. FWIW.
Re: HTML Template Comparison Sheet ETA
ELB Great idea, but just one note; ':' is not legal in CSS class names. ELB In fact, underscores are not even allowed in CSS class names! PL So? They aren't CSS class names. In the preview mode, they are treated as such, so in effect they are. Therefore, the document claims does not conform to both strict HTML and CSS in preview mode. In addition, if those are not stripped out by your module (and as far as I can tell with a quick look, they are not), the resulting HTML does not conform to both strict HTML and CSS. PL The are in fact legal class names according to the HTML spec. The HTML spec doesn't define what is a legal class name. It's simply defined as "CDATA" (i.e. a HTML escaped string). ELB
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Eric L. Brine wrote: ELB Great idea, but just one note; ':' is not legal in CSS class names. ELB In fact, underscores are not even allowed in CSS class names! PL So? They aren't CSS class names. In the preview mode, they are treated as such, so in effect they are. Then I think the web browser you're using is broken. The CLASS attribute is (and never was) reserved for the exclusive use of styles. Anything not recognized should be ignored. In addition, if those are not stripped out by your module (and as far as I can tell with a quick look, they are not), They probably *could* be. the resulting HTML does not conform to both strict HTML and CSS. It's 100% conformant to HTML: please go read the specification. As to CSS, I can't comment with authority since I'm not that familiar with the specification; but, as I said above, I would hope that anything not recognized is ignored. PL The are in fact legal class names according to the HTML spec. The HTML spec doesn't define what is a legal class name. It's simply defined as "CDATA" (i.e. a HTML escaped string). Then anything that is legal CDATA is a legal class name, by definition. I really don't know how to make that any clearer. - Paul
Re: HTML Template Comparison Sheet ETA
brian moseley wrote: On Mon, 4 Sep 2000, Perrin Harkins wrote: [% FOREACH thing = list %] a href="[% thing.url %]"b[% thing.name %]/b/a [% END %] what's the value? It's easier for some people to understand and write without help from an engineer. you have to write a parser and then interpret the instructions. You always have to do that, since templates with perl code in them are not valid perl and have to be translated. The taglib-based systems I'm familiar with use some kind of parser to read the template and generate valid perl which is then eval'ed. That's exactly what Mason does too, and Mason's parser is not trivial. your syntax is no prettier or easier to understand than the perl. That's debatable. The designers where I work preferred it. Anyway, this is not a one-size-fits-all issue, and there are good systems available that use both techniques. I'm writing an essay about this issue for the new template guide Drew and I are working on, and I'll try to summarize all the arguments on both sides. Please read through it when we release it and let me know if there's anything I've missed. - Perrin
Re: HTML Template Comparison Sheet ETA
On Mon, 28 Aug 2000, Nelson Correa de Toledo Ferraz wrote: "This approach has two problems: First, their little language is crippled. If you need to do something the author hasn't thought of, you lose. Second: Who wants to learn another language? You already know Perl, so why not use it?" To which HTML::Template responds: "Sure you know Perl, but does the HTML designer you're working with?" HTML::Template has a simple, HTML-esque syntax for its template files that is aimed at HTML designers. Keep the Perl in your modules and keep the HTML in your template files. Go the other direction and soon enough you've got your programmers changing font colors. You can put that in your sheet and, er... smoke it? -sam
Re: HTML Template Comparison Sheet ETA
Nelson Correa de Toledo Ferraz wrote: Hi Drew, I'm the one who volunteered, and then I went on vacation for a 2 weeks. I have decided I will have a bare minimum draft done within a week. And then, as Matt suggested, people can just send suggestions/corrections/additions and the document will grow. When I have a draft, I'll post it to the list. I'm new to this list, and I'd like to make a small contribution to the HTML Template Comparison Sheet. I've been using Text::Template for some time now, and I really enjoy using it because 1) it's fast, 2) it's small, just 28kb and 3) it uses Perl as scripting language. snip Thanks for the intro to Text::Template Nelson. I'll make sure it gets included in the comparison. There is such a WIDE variety of modules available that it would be almost impossible for me to try them all. But I might give it a try anyway. ;-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: HTML Template Comparison Sheet ETA
Matt Sergeant wrote: On Tue, 15 Aug 2000, Gunther Birznieks wrote: Is there an ETA on when this will be out? I know everyone is busy, but I just figured I would ask. There have been hundreds of template messages generated in the last weeks on this topic, and then it seems to have gone a bit quiet (as usual). If nobody is working on it, I suggest just getting 1 or 2 paragraph synopsis from template authors about thier product. Just compile those together and then let it evolve as people see other people's paragraphs and think "Hey I should have mentioned X too...". I'm finally getting through the huge volume of list emails after vacation, so I apologize for the delay in this response. I'm the one who volunteered, and then I went on vacation for a 2 weeks. I have decided I will have a bare minimum draft done within a week. And then, as Matt suggested, people can just send suggestions/corrections/additions and the document will grow. When I have a draft, I'll post it to the list. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: HTML Template Comparison Sheet ETA
Matt Sergeant wrote: If nobody is working on it, I suggest just getting 1 or 2 paragraph synopsis from template authors about thier product. Just compile those together and then let it evolve as people see other people's paragraphs and think "Hey I should have mentioned X too...". I would happily accept the brief synopsis Matt mentioned above. If I get a few of them, I will combine and post them along with a brief document overview. It would be better than what we have right now. :-) If you do send me a synopsis, please include the major features and try to keep it to a few paragraphs. But I won't exclude anything if it happens to be long. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: HTML Template Comparison Sheet ETA
Hi Drew,
I'm the one who volunteered, and then I went on vacation for a 2 weeks.
I have decided I will have a bare minimum draft done within a week. And
then, as Matt suggested, people can just send
suggestions/corrections/additions and the document will grow. When I
have a draft, I'll post it to the list.
I'm new to this list, and I'd like to make a small contribution to the
HTML Template Comparison Sheet.
I've been using Text::Template for some time now, and I really enjoy using
it because 1) it's fast, 2) it's small, just 28kb and 3) it uses Perl as
scripting language.
From the author's words:
"When people make a template module like this one, they almost always
start by inventing a special syntax for substitutions. For example, they
build it so that a string like %%VAR%% is replaced with the value of
$VAR. Then they realize the need extra formatting, so they put in some
special syntax for formatting. Then they need a loop, so they invent a
loop syntax. Pretty soon they have a new little template language."
"This approach has two problems: First, their little language is
crippled. If you need to do something the author hasn't thought of, you
lose. Second: Who wants to learn another language? You already know
Perl, so why not use it?"
That's a great concept. Anyway, I have tweaked the code a little, now
allows you to to make expressions like this one:
? foreach $name (@names) { ?
Name: ?=$name? P
Job: ?=$job{$name}? P
P
? } ?
Notice the ?=$variable? construction, It's the only "magic" that you
have to know. If you already know Perl, the code is much cleaner than the
HTML::Template counterpart, which would be something like this:
TMPL_LOOP NAME=EMPLOYEE_INFO
Name: TMPL_VAR NAME=NAME P
Job: TMPL_VAR NAME=JOB P
P
/TMPL_LOOP
Futhermore, with Text::Template you can access methods and modules
directly from the templates. For instance:
? my @emp = main::sql("select name,job from employee"); ?
? my @emp = $employee-list(); ?
The only problem with Text::Template is that it fails on taint checks.
However, because this module is very flexible, I believe that it's easy to
fix it by "untainting" the template before parsing it!
If anyone is curious about the Text::Template module, take a look at the
author's homepage at: http://www.plover.com/~mjd/perl/
Best wishes,
Nelson
__
Nelson Ferraz Insite - Solucoes Internet
e-mail: [EMAIL PROTECTED] http://www.insite.com.br/
Re: HTML Template Comparison Sheet ETA
On Tue, 15 Aug 2000, Gunther Birznieks wrote: Is there an ETA on when this will be out? I know everyone is busy, but I just figured I would ask. There have been hundreds of template messages generated in the last weeks on this topic, and then it seems to have gone a bit quiet (as usual). If nobody is working on it, I suggest just getting 1 or 2 paragraph synopsis from template authors about thier product. Just compile those together and then let it evolve as people see other people's paragraphs and think "Hey I should have mentioned X too...". -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Content negotiation Was: Re: HTML Template Comparison Sheet ETA
Whilst we're on the subject of templates, would anyone care to comment on how they fit with content-negotiated documents? I'm looking at a document for multiple language using Apache MultiViews. (index.html.es, index.html.jp etc). Does this even work with SSI or Apache::SSI? TIA, Dave -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: HTML Template Comparison Sheet ETA
On Tue, 15 Aug 2000, Gunther Birznieks wrote: Was someone (or somepersons) committed to doing this or is the project seeking volunteers or both? Drew Taylor [EMAIL PROTECTED] was working on the first cut, and I was planning to add some things on to that. As with The Guide, I'm sure that all contributed information will be welcome, but I'd suggest waiting for the first draft to avoid duplicating Drew's work. - Perrin
