Re: [OT] About XML and Petal (was Re: templating system opinions (axkit?))
Le lundi, 28 juil 2003, à 21:27 Europe/Paris, Jean-Michel Hiver a écrit : Also, with TT you have to use the filter 'html' to XML encode your variables. Petal does it by default, and you need to use the TALES 'structure' keyword to NOT encode. You don't *have* to use the 'html' filter in TT. I wrote a subclass of Template which does this automatically for me, and as with Petal I can also not encode by using a specific method. -- Eric Cholet
[OT] About XML and Petal (was Re: templating system opinions (axkit?))
XML syntax is crufty at best. It requires you to be strict and tediously correct with every character. So what. It's not like you can afford to forget that many curly braces or semicolons (well, except those at the end of a block) with Perl. That doesn't make it useless does it? You have to shoe-horn the semantics of your complex directives into the limited syntax of element-name-and-attributes. If you're crazy enough to use XML as a programming language, I have to agree with you. XML really sucks at that. However as a data exchange format I think it's fine. I think the same idea is behind AxKit's XPathScript. Let's use programming languages to program, and XML as a vector to structure and transport data. The language becomes contrived and clumsy as a result of trying to satisfy a purity of design and you find yourself tied down to only generating valid XML (which few real world web pages are, even if they should be). Well, I see Petal's ability to help you generating valid XML webpages as a good thing. I do not recommend Petal to people who are interested in generating HTML 3.2 pages full of tables, font face tags, fixed width fonts and other javascripteries. They would be very disapointed. The templates becomes harder to read and write because they're designed to satisfy an XML parser rather than a human. By using XML directives in XML markup, you ensure that the directives are camouflaged nicely and blend into the background. This is precisely what you (well, I) don't want to happen. These directives are supposed to be important - they are a separate concern from the purely declarative markup surrounding and deserve to stand out from the crowd. I suppose that's one way of seing it. The problem is that your template then looks like a programming language, which kind of defeats the purpose of having a template in the first place. I suppose that Petal is philosophically closer to HTML_Tree, except it has a much gentler learning curve IMHO. This is all personal opinion, of course. Same here :) I drank the XML kool aid for a long time, until I realised it was nothing but water, sugar and artifical colours. XML still serves a useful purpose for many things, but it's not the uber-solution to all our problems that vendors of commercial XML software would have us believe. Just because you can write programs, or SQL queries, or templates using XML, doesn't mean that you should. I agree on that. For the record, Petal looks like a well implemented template module, and I'm glad to see another high-calibre one joining the collective. I've looked at TAL before and while I understand the design philosophy that they're trying to promote, I still not that impressed because I can see what look like gaping holes in the reasoning behind it. Maybe... It's a little bit strange when you get started with it, but it becomes clear and very elegant quite quickly. For example with a traditional mini-language kind of templating system, you might have something like: div dir=!--VAR language_dir -- !--VAR some_content-- /div Which is completely impossible to validate and IMHO very hard to read. With Petal you just start with a mockup: div dir=ltr Hello, World /div And then you add TAL instructions: div dir=ltr petal:attributes=ltr language_dir petal:content=some_content Hello, World /div If you like a more straightforward approach, Petal also lets you write: div dir=$language_dir $some_content /div But at the risk of breaking compatibility with some validators / XML tools / etc. Vive la difference! Entierement d'accord :) Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: templating system opinions (axkit?)
On Mon, 28 Jul 2003, Andy Wardley wrote: Jean-Michel Hiver wrote: Because Petal templates have to be well-formed XML, XML syntax is crufty at best. There's a lot in XML that is needless, but like perl still has a dump() function, we just say don't use that then. At it's core, XML is a very elegant syntax for defining a rich dataset of nodes, and solves many of the problems that text markup systems still struggle with reinventing (such as different encodings - YAML for example forces everyone's document to be in one of the UTF encodings). It requires you to be strict and tediously correct with every character. Many believe this is a good thing with a templating language. Let the browser be flexible in what it can receive, but let us, as professionals, be strict in what we generate. You have to shoe-horn the semantics of your complex directives into the limited syntax of element-name-and-attributes. The language becomes contrived and clumsy as a result of trying to satisfy a purity of design. This I can agree with, having written my own templating system because I didn't like XSLT's idea of being written in XML :-) But I now use XSLT, because it has other benefits (portable, fast, etc). and you find yourself tied down to only generating valid XML (which few real world web pages are, even if they should be). My web pages come out as HTML 4.0 transitional, not XHTML, and they are generated with XSLT. They often omit closing tags where appropriate for HTML. I don't do any fancy post-processing. Sorry Andy, but the above is not true at all. Vive la difference! As you can see in evidence (Apache::AxKit::Language::*), I agree. -- !-- Matt -- :-get a SMart net/:- Spam trap - do not mail: [EMAIL PROTECTED]
Re: templating system opinions (axkit?)
Matt Sergeant wrote: At it's core, XML is a very elegant syntax for defining a rich dataset of nodes It's a syntax for defining a dataset of nodes that all conform to XML's ideas about what a dataset of nodes looks like. I'm not convinced about rich or elegant. :-) and you find yourself tied down to only generating valid XML (which few real world web pages are, even if they should be). My web pages come out as HTML 4.0 transitional, not XHTML, and they are generated with XSLT. They often omit closing tags where appropriate for HTML. I don't do any fancy post-processing. Sorry Andy, but the above is not true at all. OK, fair enough, you can generate output that contains invalid XML markup. But you can't write a source template that includes invalid XML as literal text. At least not without escaping all the and characters and other such madness. However, I accept that this is construed as a feature in these kind of systems. I just happen to prefer a slightly different kind of system. A
Re: [OT] About XML and Petal (was Re: templating system opinions (axkit?))
Jean-Michel Hiver wrote: something like: div dir=!--VAR language_dir -- !--VAR some_content-- /div Which is completely impossible to validate and IMHO very hard to read. Agreed. The following is easier to read, IMHO, and is also valid XML markup. div dir=[% language_dir %] [% some_content %] /div div dir=ltr petal:attributes=ltr language_dir petal:content=some_content Hello, World /div I accept that it's a clever approach, but I think it's the hardest to read of all three. Both the original values and also the Petal replacement instructions are present in the element. The reader has to mentally match them up to figure out what's going on. It's hard to see at a glance that 'Hello World' is replaced by 'some_content', for example, without checking the element attributes. I'm sure that once you're in the Petal mindset it all make sense much more quickly. But you're right in saying that it's strange at first! If you like a more straightforward approach, Petal also lets you write: div dir=$language_dir $some_content /div If you like a more straightforward approach, TT also lets you write: div dir=$language_dir $some_content /div See, I knew there would be something that we would agree on! :-) But at the risk of breaking compatibility with some validators / XML tools / etc. It still looks like valid XML to me. Where is the incompatability? Am I missing something obvious? A
Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))
If you like a more straightforward approach, TT also lets you write: div dir=$language_dir $some_content /div See, I knew there would be something that we would agree on! :-) :) But at the risk of breaking compatibility with some validators / XML tools / etc. It still looks like valid XML to me. Where is the incompatability? Am I missing something obvious? And it is. However if you have, say, div id=[% VAR object.id %] then it's not XHTML anymore (spaces / weird chars not allowed as identifier...). I'm sure there's many more cases of nasty surprises. There's also cases in which with TT or H::T you have: [% IF expression %] foo [% FOR other_expression AS stuff %] ... some stuff /foo [% END %] [% END %] Here the problem is obvious because the code is well indented. However with TAL syntax this simply cannot happen. Also, with TT you have to use the filter 'html' to XML encode your variables. Petal does it by default, and you need to use the TALES 'structure' keyword to NOT encode. This is because double encoded values are much easier to spot and debug than badly encoded ones. To summarize, I think Petal is more specialized in XML templating and has the strength of a very smart, open specification written by the Zope people. Petal fills a niche across the XML and the templating world and is certainly not a replacement for TT. Actually, as Steve Purkis suggested on the Petal mailing list it would be possible to implement Petal on top of TT. Maybe for Petal 2.00! To conclude, and in order to satisfy my little ego I think both libraries are deadly cool. Plus I would never have dreamed of the author of TT arguing about the pros and cons of TT vs Petal with me when I started writing the library a little more than a year ago. That in itself is a great reward :-) Cheers, Jean-Michel.
Re: [OT] About XML and Petal (was Re: templating system opinions (axkit?))
I suggest y'all check out Tapestry
http://jakarta.apache.org/tapestry
to see a really nice happy medium. It uses a templating language
similar to TAL but much more flexible (and useful, in my mind) than
rigid XML. All its templates can be used in things like Dreamweaver
and GoLive with getting munged. I also think that forcing templates to
be valid XML is a huge pain in the nuts and would drive most poor HTML
monkeys crazy. We're the developers, leave the XML to us... don't
force it on people who use photoshop for a living and have learned HTML
so they could be a web designer because it's just gonna confuse them.
And besides, we're perl developers... we should take one look at XML
and vomit at its disgusting syntax and unwieldy markup-heavy,
text-heavy guts. You can't beat pure perl for representing data
structures, or NeXT plists, for that matter. What's easier, this:
{
XML = Sucks,
Perl = [
Rules,
Is Great,
Is fun,
],
}
or this piece of nastiness
?xml some crazy required tagged bs?
SomeUselessWrapper
XMLSucks/XML
Perl
UselessItemTagRules/UselessItemTag
UselessItemTagIs Great/UselessItemTag
UselessItemTagIs fun/UselessItemTag
/Perl
/SomeUselessWrapper
Ok, so I'm not being totally fair, but you get the idea.
XML is a nice idea for certain things but I gotta agree with Andy...
keep it out of my web templates.
Cheers
Kyle Dawkins
Central Park Software
On Monday, Jul 28, 2003, at 12:27 US/Pacific, Jean-Michel Hiver wrote:
If you like a more straightforward approach, TT also lets you write:
div dir=$language_dir
$some_content
/div
See, I knew there would be something that we would agree on! :-)
:)
But at the risk of breaking compatibility with some validators / XML
tools / etc.
It still looks like valid XML to me. Where is the incompatability?
Am
I missing something obvious?
And it is. However if you have, say, div id=[% VAR object.id %]
then
it's not XHTML anymore (spaces / weird chars not allowed as
identifier...). I'm sure there's many more cases of nasty surprises.
There's also cases in which with TT or H::T you have:
[% IF expression %]
foo
[% FOR other_expression AS stuff %]
... some stuff
/foo
[% END %]
[% END %]
Here the problem is obvious because the code is well indented. However
with TAL syntax this simply cannot happen.
Also, with TT you have to use the filter 'html' to XML encode your
variables. Petal does it by default, and you need to use the TALES
'structure' keyword to NOT encode.
This is because double encoded values are much easier to spot and debug
than badly encoded ones.
To summarize, I think Petal is more specialized in XML templating and
has the strength of a very smart, open specification written by the
Zope
people. Petal fills a niche across the XML and the templating world and
is certainly not a replacement for TT.
Actually, as Steve Purkis suggested on the Petal mailing list it would
be possible to implement Petal on top of TT. Maybe for Petal 2.00!
To conclude, and in order to satisfy my little ego I think both
libraries are deadly cool. Plus I would never have dreamed of the
author
of TT arguing about the pros and cons of TT vs Petal with me when I
started writing the library a little more than a year ago.
That in itself is a great reward :-)
Cheers,
Jean-Michel.
Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))
Hi, All May be I'm a bit late here... But is there any sence in artifical XML templating languages since there is XSLT ? Just wonder whether there are cons other than long learning curve and performance issues ? Alex Gidrevich
Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))
On Mon, 28 Jul 2003, Aleksandr Guidrevitch wrote: May be I'm a bit late here... But is there any sence in artifical XML templating languages since there is XSLT ? Just wonder whether there are cons other than long learning curve and performance issues ? Well, in the case of just TAL/Petal, the point as far as I know isn't so much that it happens to be valid XML -- though of course that's a welcome design aspect -- but that it's easy to use in W3C compliant HTML without masking the interesting bits inside HTML comment blocks. I can't think of an example now (and apologize for only having had time to skim much of this long, spiralling thread so far), but I seem to remember that TAL's syntax allowed for these clever little inside out loop structures that, among other things, ensures that the unrolled version of the loop still has proper indentation etc. Unessential maybe, but a nice touch. I don't know nearly enough about XSLT to comment on it in depth, but my impression is that TAL generally derives from the same heritage as all the assorted Perl template languages, etc, rather than ...well I guess I don't really know where XSLT derives from (Docbook?), but it seems more like CSS: a separate document describing how to display one or more other structured documents. The difference in the case of TAL / TT / H::T / Mason / etc is that the template is used to provide that structure itself, assembling it out of code that is maybe extracting content from a database or calculating it on the fly something. My hunch is that the way to work XSLT into the mix -- if it has a place at all -- is to have your logic (scripts with H::T, code sprinkled in Mason templates, TT applied where clever TT people apply it) fleshing out the framework defined in a template (the H::T template, the non-code part of a Mason template, the plaintext part of a TT template) as well formed XML, and then using XSLT to format that intermediate form for display. This probably makes sense in cases where that intermediate form can be cached (pages for web or print that change once a day, say), but for truly dynamic documents the XSLT stage is probably way too much overhead. Is XSLT appropriate for applying both structure styling to the free- form output of a [Perl] program? Does it take a lot of overhead? Would this overhead happen on the server end (glue XML + XSLT into an HTML document that goes out over the wire), or on the client end (download XML, then grab XSLT by reference (like HTML grabs CSS), and then the client merges them)? If the client does the work, how widespread is support? If the server does the work, what should the throughput be like? My hunch -- which I'd be happy to be corrected about -- is that this can't be any easier than just working directly from traditional template kits, as has been discussed at remarkable length in this thread :) -- Chris Devers[EMAIL PROTECTED]http://devers.homeip.net:8080/resume/ sorry for helping along in this thread 10 days dozens of messages ago :)
Re: templating system opinions (axkit?)
I've been considering using a template system for an app that I'm working, but decided against it as the designers who would be putting the actual pages together (look n feel) use Adobe GoLive which does 'bad things' to non-html stuff (at least in my experience). I know everybody's defending their fave templating system... I guess I can't resist: I have to jump in and defend my baby :) So why is Petal better than anything else? First of all, it is an implementation of TAL. TAL is a very clever open specification for WYSIWYG-friendly templates written by the Zope people. TAL has three python implementations, one PHP implementation and two Perl implementations (see Petal::CodePerl). I believe it will become the standard with which template designers will want to work with. You can open Petal XHTML templates into GoLive, Dreamweaver, Mozilla, and they will look fine. Petal is basically an implementation of TAL, an open specification designed by the ZOPE people to be WYSIWYG-compatible and which has been extensively tested with all kinds of WYSIWYG-ish software. Because Petal templates have to be well-formed XML, it is safe (and in fact recommended!) to send them through HTML tidy and check for well-formness with xmllint. Petal is not limited to XHTML. You can template any kind of XML. RSS, RDF, SVG, WML... you name it! It has good support for Unicode / multi-lingual applications and character set encoding (well, provided you use Perl 5.8). It is quite fast (templates are turned into subroutines which are cached on disk and in memory). It has been designed to be very mod_perl friendly. Petal has an active community and a mailing list, it is stable and has already been successfully used in different projects by different people. This TAL spec that I've shamelessly stolen / implemented is a really cool idea. You should really give it a try in between two Template Toolkit driven projects :) Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: templating system opinions (axkit?)
I know everybody's defending their fave templating system... I guess I can't resist: I have to jump in and defend my baby :) So why is Petal better than anything else? Oops, I got a bit carried away... As a side note, Petal is probably not better than anything else, but different. If you're templating XML / XHTML, it'll do a really good job. If you're templating text, use something else :) Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: templating system opinions (axkit?)
- Original Message - From: Jean-Michel Hiver [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 24, 2003 1:46 PM First of all, it is an implementation of TAL. TAL is a very clever open specification for WYSIWYG-friendly templates written by the Zope people. Do you have a URL for further reading on TAL? Petal has an active community and a mailing list, Ditto - a URL would be interesting! Regards Jeff
RE: templating system opinions (axkit?)
Do you have a URL for further reading on TAL? I found one: http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL Regards, Kitch
Re: templating system opinions (axkit?)
First of all, it is an implementation of TAL. TAL is a very clever open specification for WYSIWYG-friendly templates written by the Zope people. Do you have a URL for further reading on TAL? Yep. http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL Petal has an active community and a mailing list, Ditto - a URL would be interesting! Sure :) http://lists.webarch.co.uk/mailman/listinfo/petal Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: templating system opinions (axkit?)
On Mon, 21 Jul 2003, Patrick Galbraith wrote: Anyone on this list use AxKit? I'm curious how it pans out. I like the idea of XSLT/XML, though I find myself trying to read between the lines of hype vs. something that's actually very useful. I don't know, so I don't have any opinions. I do know I'd like to use XSLT/XML so as to have a project to use it for, hence learn it. I'm just about to roll out a site using AxKit that has to do about 3 million hits/day out of the box. The main reason I like AxKit is it prevents me from screwing up and creating XSS bugs, because everything has to be well formed. I almost never have to use html or URL encode/decode functions - I just write straight perl code. I barely notice that I'm using XML. It's also worth noting that XSLT is a portable skill, with lots of great offline tools. It's also worth saying: never listen to hype. Evaluate solutions based on your criteria. AxKit matches mine but it doesn't mean it will match yours. Matt.
Re: templating system opinions (axkit?) [OT]
Hi Matt, On Wed, 23 Jul 2003, Matt Sergeant wrote: The main reason I like AxKit is it prevents me from screwing up [snip] I just write straight perl code. I barely notice that I'm using XML. Can you give us in a couple of sentences your take on the state of XML in general and AxKit in particular? To me somehow things don't seem to be going in quite the same direction any more... 73, Ged.
RE: templating system opinions (axkit?)
Hi, I've been considering using a template system for an app that I'm working, but decided against it as the designers who would be putting the actual pages together (look n feel) use Adobe GoLive which does 'bad things' to non-html stuff (at least in my experience). What i've done is just use completely external html files with html-compliant comments indicating the data field. (example !-- APPNAME_USER_FIRST_NAME --). My application just reads in the html on startup and does a series of substition statements over the file as necessary to replace the comments with the actual data. Thus, each type of page has one base html (or html file pieces) that are merged with each other and data as necessary allowing all logic to be kept in the program. It's certainly not the most robust system in the world, but it's simple and compatible with existing skill sets and design tools. Also, it only reads those html files once at startup so if you change designs on the fly the application needs to be restarted. I'll be adding a function to either stat the files before using the cached version or just automatically reload the files every 15 minutes regardless of changes to eliminate the SIGHUP issue. Please do note that I'm only expecting, on the VERY high side, a few thousand users to be hitting it each day. good luck, bill -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED] Sent: Wed 2003-07-23 4:00 AM To: Patrick Galbraith Cc: [EMAIL PROTECTED] Subject:Re: templating system opinions (axkit?) On Mon, 21 Jul 2003, Patrick Galbraith wrote: Anyone on this list use AxKit? I'm curious how it pans out. I like the idea of XSLT/XML, though I find myself trying to read between the lines of hype vs. something that's actually very useful. I don't know, so I don't have any opinions. I do know I'd like to use XSLT/XML so as to have a project to use it for, hence learn it. I'm just about to roll out a site using AxKit that has to do about 3 million hits/day out of the box. The main reason I like AxKit is it prevents me from screwing up and creating XSS bugs, because everything has to be well formed. I almost never have to use html or URL encode/decode functions - I just write straight perl code. I barely notice that I'm using XML. It's also worth noting that XSLT is a portable skill, with lots of great offline tools. It's also worth saying: never listen to hype. Evaluate solutions based on your criteria. AxKit matches mine but it doesn't mean it will match yours. Matt. CONFIDENTIALITY NOTICE: This E-Mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute and delete the original message. Please notify the sender by E-Mail at the address shown. Thank you for your compliance.
RE: templating system opinions (axkit?)
On Wed, 23 Jul 2003, Hauck, William B. wrote: What i've done is just use completely external html files with html-compliant comments indicating the data field. (example !-- APPNAME_USER_FIRST_NAME --). My application just reads in the html on startup and does a series of substition statements over the file as necessary to replace the comments with the actual data. Thus, each type of page has one base html (or html file pieces) that are merged with each other and data as necessary allowing all logic to be kept in the program. Change that to: !-- TMPL_VAR APPNAME_USER_FIRST_NAME -- and you can use HTML::Template! You'll also get loops, includes, and simple conditionals should you ever need them. -sam
RE: templating system opinions (axkit?)
Change that to: !-- TMPL_VAR APPNAME_USER_FIRST_NAME -- You mean TMPL_VAR APPNAME_USER_FIRST_NAME don't you? Or did I miss the secret stealth hide-your-tags-in-html-comments feature? :-) -Fran
RE: templating system opinions (axkit?)
What you have created for your own use is almost exactly what HTML::Template does. We have used it for a year without any major problems between us and the HTML designer. Its fast and supports loops and if statements. Its probably worth your while to check it out. As far as XSLT goes, we're moving to it now (XML::LibXSLT) and its making our life much easier. Our designer doesnt mind learning it, esp. after showing him what it can do. Marc Slagle Whapps, LLC. On Wed, 2003-07-23 at 10:27, Hauck, William B. wrote: Hi, I've been considering using a template system for an app that I'm working, but decided against it as the designers who would be putting the actual pages together (look n feel) use Adobe GoLive which does 'bad things' to non-html stuff (at least in my experience). What i've done is just use completely external html files with html-compliant comments indicating the data field. (example !-- APPNAME_USER_FIRST_NAME --). My application just reads in the html on startup and does a series of substition statements over the file as necessary to replace the comments with the actual data. Thus, each type of page has one base html (or html file pieces) that are merged with each other and data as necessary allowing all logic to be kept in the program.
Re: templating system opinions (axkit?)
Hauck, William B. wrote: Hi, snip / I'll be adding a function to And then you'll be adding a function to..., and then possibly a function to..., and then you'll need it to... Pretty soon, you will have spent hundreds of hours developing a templating system that you throw away in favor of one of the tried and true templating systems that are available. Of course I may be wrong. Your needs may be very simple, and may not change over time. But you may want to ask around on this list to see how many folks have rolled their own templating system and thrown it away. Of course there are folks on this list who haven't thrown theirs away, and have worked hard to make them robust, stable and performant. Thats why we take advantage of their work ;-) bill -- Douglas -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED] Sent: Wed 2003-07-23 4:00 AM To: Patrick Galbraith Cc: [EMAIL PROTECTED] Subject:Re: templating system opinions (axkit?) On Mon, 21 Jul 2003, Patrick Galbraith wrote: Anyone on this list use AxKit? I'm curious how it pans out. I like the idea of XSLT/XML, though I find myself trying to read between the lines of hype vs. something that's actually very useful. I don't know, so I don't have any opinions. I do know I'd like to use XSLT/XML so as to have a project to use it for, hence learn it. I'm just about to roll out a site using AxKit that has to do about 3 million hits/day out of the box. The main reason I like AxKit is it prevents me from screwing up and creating XSS bugs, because everything has to be well formed. I almost never have to use html or URL encode/decode functions - I just write straight perl code. I barely notice that I'm using XML. It's also worth noting that XSLT is a portable skill, with lots of great offline tools. It's also worth saying: never listen to hype. Evaluate solutions based on your criteria. AxKit matches mine but it doesn't mean it will match yours. Matt. CONFIDENTIALITY NOTICE: This E-Mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute and delete the original message. Please notify the sender by E-Mail at the address shown. Thank you for your compliance.
Re: templating system opinions (axkit?)
[EMAIL PROTECTED] wrote: Change that to: !-- TMPL_VAR APPNAME_USER_FIRST_NAME -- You mean TMPL_VAR APPNAME_USER_FIRST_NAME don't you? Or did I miss the secret stealth hide-your-tags-in-html-comments feature? :-) You missed it: http://search.cpan.org/author/SAMTREGAR/HTML-Template-2.6/Template.pm#NOTES - Perrin
RE: templating system opinions (axkit?)
You missed it: http://search.cpan.org/author/SAMTREGAR/HTML-Template-2.6/Temp late.pm#NOTES Ah. When the section begins If you're a fanatic about valid HTML it becomes more clear why I missed that. :-) Thanks, Fran
RE: templating system opinions (axkit?)
Hi Jesse, -Original Message- From: Jesse Erlbaum [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 8:50 PM To: 'Patrick Galbraith' Cc: [EMAIL PROTECTED] Subject: RE: templating system opinions (axkit?) Hi Patrick -- I like the idea of XSLT/XML, though I find myself trying to read between the lines of hype vs. something that's actually very useful. I don't know, so I don't have any opinions. I do know I'd like to use XSLT/XML so as to have a project to use it for, hence learn it. It's mostly hype in my experience. And not even very useful hype, like Java or PHP, which are actually real things which people might want to use. XSLT seems to be XML geeks' answer to CSS+templating. As if CSS wasn't very successful, as if the world needed another templating system, XSLT seems to have been invented to take the creative work of designing web sites out of the hands of HTML designers, and put it in the hands of XPath programmers. You know. Programmers who are really good at both creative design and communicating with human beings. Not. Alright, pretty smarmy. But unless you just happen to have thousands of XML documents sitting around on your hard drive, XSLT is a solution in search of a problem. Most of my data is in a RDBMS -- not XML. To enhance the *need* for XSLT, some databases will now return XML. That's an interesting idea. Instead of using a mature language like Perl|Java|PHP, let's use something like XSLT to turn my data into a web page! It's new, shiny, and will solve the problem of TOO MANY people knowing the other aforementioned languages. D'oh! Too cynical? Maybe. The fact that XSLT is still discussed in serious company just bugs me. ;-) Not just that, but what about SOAP... Net RPC... I'd like to know where those fit in as well. Fantastic, useful stuff. I get so tired of Java types talking about how perl is just a scripting language.. it's not an application platform/server like Dynamo/WebSpere/insert $$$ java non-OS app here. I even tried to crack a particular Orielly java book and was turned off on a statement like Perl is good for proto-typing but not a full application server. Yes, there are a lot of prototypes getting millions of pageviews a day and generating signicifican revenue. You hit the nail on the head there: Prototype in Perl, and then just keep using it! A strategy for the NEW New Economy. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 It's nice to see that I'm not alone ;-) Without trying to start a religious war, I think all the debate can easily slip to: Is XML really useful? I mean besides creating new job positions, new software, new frameworks, new problems to be solved, some overhead over processing simple text files, etc. But I shouldn't go in there... As for Java, unfortunately the Perl community is in my opinion in a no-win situation. I've seen lots of people in managerial positions hardly knowing how to read/write their emails using Outlook, not knowing that Perl even exists, but giving lessons about the Java usefulness; to quote a recent one: You can't survive on the Internet today without Java. There is a technical snobbery that is hard to defeat since snobbery itself is human nature. But what would I know? Quit cheap philosophy and back to work... Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net I'm not mad. I've been in bad mood for the last 30 years...
Re: templating system opinions (axkit?)
Anyone on this list use AxKit? I'm curious how it pans out. I like the idea of XSLT/XML, though I find myself trying to read between the lines of hype vs. something that's actually very useful. I don't know, so I don't have any opinions. I do know I'd like to use XSLT/XML so as to have a project to use it for, hence learn it. Not just that, but what about SOAP... Net RPC... I'd like to know where those fit in as well. I get so tired of Java types talking about how perl is just a scripting language.. it's not an application platform/server like Dynamo/WebSpere/insert $$$ java non-OS app here. I even tried to crack a particular Orielly java book and was turned off on a statement like Perl is good for proto-typing but not a full application server. Yes, there are a lot of prototypes getting millions of pageviews a day and generating signicifican revenue. I'd like to see perl/mod_perl reclaim some of the lost ground. On Sun, 20 Jul 2003, Dave Rolsky wrote: On Sun, 20 Jul 2003, Patrick Galbraith wrote: I've been working at Classmates.com for a couple months contracting, and they use Text::Forge. I've been impressed by the performance, and wish it was a big player. Part of the reason it isn't is guys like me should contribute to it and make it a bigger player. I'd say the big reason it's not a big player is that it doesn't offer anything new. It also doesn't seem to be very actively developed and has very little documentation. I really like the syntax - it looks a lot like JSP. Yeah, just like Apache::ASP ;) All of this said, what is the most commonly used system out there? The biggest players are Mason and Template Toolkit, judging from big companies that have used them, as well as job posting. HTML::Template, Embperl, and Apache::ASP all seem to have reasonably active user bases as well. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: templating system opinions (axkit?)
Hi Patrick -- I like the idea of XSLT/XML, though I find myself trying to read between the lines of hype vs. something that's actually very useful. I don't know, so I don't have any opinions. I do know I'd like to use XSLT/XML so as to have a project to use it for, hence learn it. It's mostly hype in my experience. And not even very useful hype, like Java or PHP, which are actually real things which people might want to use. XSLT seems to be XML geeks' answer to CSS+templating. As if CSS wasn't very successful, as if the world needed another templating system, XSLT seems to have been invented to take the creative work of designing web sites out of the hands of HTML designers, and put it in the hands of XPath programmers. You know. Programmers who are really good at both creative design and communicating with human beings. Not. Alright, pretty smarmy. But unless you just happen to have thousands of XML documents sitting around on your hard drive, XSLT is a solution in search of a problem. Most of my data is in a RDBMS -- not XML. To enhance the *need* for XSLT, some databases will now return XML. That's an interesting idea. Instead of using a mature language like Perl|Java|PHP, let's use something like XSLT to turn my data into a web page! It's new, shiny, and will solve the problem of TOO MANY people knowing the other aforementioned languages. D'oh! Too cynical? Maybe. The fact that XSLT is still discussed in serious company just bugs me. ;-) Not just that, but what about SOAP... Net RPC... I'd like to know where those fit in as well. Fantastic, useful stuff. I get so tired of Java types talking about how perl is just a scripting language.. it's not an application platform/server like Dynamo/WebSpere/insert $$$ java non-OS app here. I even tried to crack a particular Orielly java book and was turned off on a statement like Perl is good for proto-typing but not a full application server. Yes, there are a lot of prototypes getting millions of pageviews a day and generating signicifican revenue. You hit the nail on the head there: Prototype in Perl, and then just keep using it! A strategy for the NEW New Economy. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: templating system opinions (axkit?)
Jesse Erlbaum wrote: Hi Patrick -- I like the idea of XSLT/XML, though I find myself trying to read between the lines of hype vs. something that's actually very useful. I don't know, so I don't have any opinions. I do know I'd like to use XSLT/XML so as to have a project to use it for, hence learn it. It's mostly hype in my experience. And not even very useful hype, like Java or PHP, which are actually real things which people might want to use. I don't quite understand what isn't real about XML or XSLT. XML really is a way to structure your data, XSLT really is a way to transform that structured data. But unless you just happen to have thousands of XML documents sitting around on your hard drive, XSLT is a solution in search of a problem. Most of my data is in a RDBMS -- not XML. Or, if you have thousands of XML documents sitting around on your hard drive, XSLT is an efficient way to translate them into XHTML and deliver them to a browser. You do make a good point that XSLT probably isn't for folks who store the all data they are delivering in a RDBMS. Adding layers onto your RDBMS to make it return XML, and then transforming that newly generated XML using XSLT may not be the best solution. But if folks are storing indexed XML documents on their filesystem (a la XML::Comma or a similar framework) XSLT can be quite handy. Too cynical? Maybe. The fact that XSLT is still discussed in serious company just bugs me. ;-) Well, I've always considered myself to be pretty light-hearted. Sometimes bordering on straight goofy ;-) TTYL, -Jesse- -- Douglas
Re: templating system opinions (axkit?)
Anyone on this list use AxKit? I'm curious how it pans out. I used it for http://www.nikki-site.com (sorry, Japanese-only site). This site uses exactly 4 pure-mod_perl handlers, and everything else eventually goes through AxKit (excuse the site design, as far as development goes that is a one-man show, and I'm a programmer, not a designer ;) I was keen on leveraging XSLT precisely because I knew that I'd be transforming a data source through mod_perl + in a cron job, AND I wanted to avoid using Perl on the cronjobs because of the resource constraints (puny server). When a user requests data, AxKit uses a stylesheet to transform it to HTML. Meanwhile the same data source is preprocessed a couple of times behind the scenes to create derivative data, which is later available for users to fetch from Apache. The preprocessing is done using the same stylesheet as the one that AxKit, but it is run via multiple calls to xsltproc instead of going though Perl. So I get the speed of a C-based app using the same stylesheet as mod_perl. I like that ;) (note for nit-pickers: I admit I didn't do an extensive comparison of how it would have faired to use optimized Perl, but the previous incarnation of www.nikki-site.com used to take about 3 minutes processing the same data -- xsltproc does it in about 13 seconds) I also like the way AxKit applies transformation. I conceptually think of it as a set of filters, and that just fits my mental model. YMMV. XSP is also very convenient, but I must admit I haven't harnessed its entire functionality. On the other hand I must say that debugging problems on AxKit is pretty harsh on beginners. I went in with the mindset that if it was broken I was going to make it work, so I didn't have much problem, but that may or may not work for you. Overall I find AxKit to be god-sent for my particular application. Things became much easier for me to add to the site, but if you're not already familiar with the workings of XML/XSLT, you may need a little patience. --d
Re: templating system opinions (axkit?)
Jesse Erlbaum [EMAIL PROTECTED] wrote: It's mostly hype in my experience. And not even very useful hype, like Java or PHP, which are actually real things which people might want to use. XSLT seems to be XML geeks' answer to CSS+templating. As if CSS wasn't very successful, as if the world needed another templating system, XSLT seems to have been invented to take the creative work of designing web sites out of the hands of HTML designers, and put it in the hands of XPath programmers. You know. Programmers who are really good at both creative design and communicating with human beings. Not. Alright, pretty smarmy. But unless you just happen to have thousands of XML documents sitting around on your hard drive, XSLT is a solution in search of a problem. Most of my data is in a RDBMS -- not XML. To enhance the *need* for XSLT, some databases will now return XML. That's an interesting idea. Instead of using a mature language like Perl|Java|PHP, let's use something like XSLT to turn my data into a web page! It's new, shiny, and will solve the problem of TOO MANY people knowing the other aforementioned languages. D'oh! Too cynical? Maybe. The fact that XSLT is still discussed in serious company just bugs me. ;-) This is a bit disorganized, but I'm trying to explain why different things have their place, at least in the work I'm doing. I am working on a project with the following simplified pipeline in an MVC environment: TT2 - HTML::Mason - AxKit - Client I use each of these for their strengths. I don't expect each one to do everything I need. We want the people that know our customers the best to be the ones that provide the content for the site. These same people are not programmers. They do not like programming. They don't like being near code for fear they will mess something up. I will let them edit TT2 templates. Since they don't like the Unix editors or CVS, I will provide (initially) a web interface for editing and a revision-controlled repository (Gestinanna::POF::Repository). The templates will produce XML so the author can concentrate on content and not worry about presentation. We want others who understand the processes a customer can understand to be the ones writing the controllers. These are XML documents that define a state machine (StateMachine::Gestinanna) that walk a customer through a process to get something done (and applying the right XSLT can create the documentation for the state machine). But these same documents do not expose the full Perl language or the server in the hope of having one less security hole to worry about. In fact, the applications can usually be prototyped without invoking the model or having any code run on a state/edge transition. Once the process flow is finalized, the model can be tied in. These are run in HTML::Mason and determine which template will be used to produce the XML. The model is written as a set of Perl modules (e.g., Gestinanna::POF). The authors of these modules are trusted, usually the same people that are responsible for system security and operation. They can have full access to the server. The modules provide an OO interface to most business operations controlled by the controller. The XML produced by the template is processed by AxKit to produce HTML, WML, or some other format usable by the customer's client. The other benefit of XSLT is that like content is treated in a consistent manner in the end document. Customers can always expect a particular content type to be in a particular format for a given document type without the person writing the content having to constantly check their work against a style sheet. If the person responsible for the layout and look of the site changes something, only the XSLT and CSS have to be changed. Usually, only the CSS has to be changed unless there are major structural changes to the site. The look and layout of the site is done in Photoshop, not in IE. This allows someone that does know XSLT to go in and make sure the resulting HTML matches for a wide range of browsers what was done in Photoshop. We also tend to stick with the W3C recommendations instead of relying on proprietary features/bugs. Of course, we're also a state institution under certain legal restrictions regarding what we can do on the web. So I'm using TT2, HTML::Mason and AxKit to work on a site using XML and XSLT. Each has its role based on personnel constraints that are outside the technical requirements of the project. Even so, it results in a highly customizable application that requires little effort at any particular point. I'm working on throwing SOAP and Jabber into the mix as well. I haven't done any performance tuning yet. The primary focus of the application is security, then maintainability, then usability. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: templating system opinions (axkit?)
On Mon, 2003-07-21 at 12:14, Patrick Galbraith wrote: I get so tired of Java types talking about how perl is just a scripting language.. it's not an application platform/server like Dynamo/WebSpere/insert $$$ java non-OS app here. I even tried to crack a particular Orielly java book and was turned off on a statement like Perl is good for proto-typing but not a full application server. Yes, there are a lot of prototypes getting millions of pageviews a day and generating signicifican revenue. I'd like to see perl/mod_perl reclaim some of the lost ground. Yahoo and Amazon both use perl much more than they use Java. eBay is going Java (from C++), but it's costing them millions and taking years. Ticket Master and CitySearch are both Perl. It looks to me like there is very little evidence to support the claim that Java is in any way better for building high-volume sites. - Perrin
