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
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: [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?))
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 Sucks Rules Is Great Is fun 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: $some_content 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, 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 %] [% FOR other_expression AS stuff %] ... some stuff [% 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?))
> If you like a more straightforward approach, TT also lets you write: > > > $some_content > > > 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, 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 %] [% FOR other_expression AS stuff %] ... some stuff [% 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?))
Jean-Michel Hiver wrote: > something like: > > > > > > 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. [% some_content %] >dir="ltr" > petal:attributes="ltr language_dir" > petal:content="some_content"> > > > Hello, World > 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: > > > $some_content > If you like a more straightforward approach, TT also lets you write: $some_content 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: 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: 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. -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
[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: Which is completely impossible to validate and IMHO very hard to read. With Petal you just start with a mockup: Hello, World And then you add TAL instructions: > Hello, World If you like a more straightforward approach, Petal also lets you write: $some_content 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?)
Jean-Michel Hiver wrote: > Because Petal templates have to be well-formed XML, This is the sticking point for me, I'm afraid. I can see some of the benefits of having templates written in well-formed XML markup, but I can't see past the drawbacks. XML syntax is crufty at best. It requires you to be strict and tediously correct with every character. 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 and you find yourself tied down to only generating valid XML (which few real world web pages are, even if they should be). 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. This is all personal opinion, of course. 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. 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. But that's what makes the world such a fun place - we all have different ideas about the Right Way to Do It. And that's why there will never be one template module, toolkit, strategy, solution or design pattern that will keep all the people happy all the time. That's not to say that we need 37 different template modules, but we definately need more than one. Vive la difference! A
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 (CGI::Application in connection with either HTML::Template or Template::Toolkit)
Hey Randal -- > Maybe because it competes with OpenInteract, which is far > more established. I don't really think OI and CGI-App are in competition at all. OI attempts to be a uber-framework, a la Mason -- or maybe more like ColdFusion or WebObjects.CGI::Application just focuses on web application state management. CGI::Application doesn't try to bolt on anything else. The developer can choose their favorite modules for templating system, database interface, object persistence, session management, etc. CGI-App is specifically made to allow developers to choose from the best available CPAN libraries, rather than to pre-select for them. You could probably use CGI::Application to implement part of OpenInteract, but you wouldn't use one in lieu of the other. They're not really comparable at all. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
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?)
> - 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?)
> 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?)
> 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 (CGI::Application in connection witheither HTML::Template or Template::Toolkit)
Dave Rolsky wrote: There's a fine book about it. www.masonbook.com Just an unbiased opinion ;) Hey, I'd be happy to write a book about OpenInteract ;-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)
Eric wrote: That was really interesting to look at. OpenInteract is really impressive. I guess there is always a cost to having a big do it all type of system. That is what made me avoid Mason, it just blew my head off for complexity. Now it is true, I am looking for a bit more than what CGI::Application offers out of the box, but it may well end up being worthwhile to just extend rather than convert. I really appreciate the simple philosophy that HTML::Template and CGI::Application follow. OpenInteract definitely does more for you. But it also has (IMO) a fairly sophisticated way to distribute standalone applications -- including data structures, initial data, security settings, templates and (oh yeah) the actual perl code -- and plug them into another OI server. OI 1.x ties you to the Template Toolkit, but 2.x (a big improvement now in beta) allows you to use whatever templating engine you like. You lose a ton of functionality, but HTML::Template folks seem to like it that way :-) One question, how do you judge that OpenInteract is more established? Is does look like it is actively developed, but I never heard of it before, and I couldn't find much indication of how popular it is. Randal's 'far more established' may be premature :-) Taking a strict time perspective: from Backpan it looks like CGI::Application was first released to CPAN in July 2000, while OI was first released in February 2001. (I'd thought it was October 2000, but it's funny the tricks your memory will play.) As to other definitions of 'established' I haven't followed CGI::Application development to say either way. There have been more articles published on CGI::Application and it seems to have a larger userbase, partly because it's easier to get started with and wrap your head around everything it does. Classic trade-off :-) Good luck! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)
On Wed, 23 Jul 2003, Eric wrote: > do it all type of system. That is what made me avoid Mason, it just blew my > head off for complexity. Now it is true, I am looking for a bit more than There's a fine book about it. www.masonbook.com Just an unbiased opinion ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Templating system opinions (CGI::Application in connection with either HTML::Template or Template::Toolkit)
Hi, That was really interesting to look at. OpenInteract is really impressive. I guess there is always a cost to having a big do it all type of system. That is what made me avoid Mason, it just blew my head off for complexity. Now it is true, I am looking for a bit more than what CGI::Application offers out of the box, but it may well end up being worthwhile to just extend rather than convert. I really appreciate the simple philosophy that HTML::Template and CGI::Application follow. One question, how do you judge that OpenInteract is more established? Is does look like it is actively developed, but I never heard of it before, and I couldn't find much indication of how popular it is. Thanks, Eric At 09:23 AM 2003-07-23, Randal L. Schwartz wrote: > "Dave" == Dave Baker <[EMAIL PROTECTED]> writes: Dave> I'm curious as to why the combination of CGI::Application and Dave> HTML::Template hasn't taken off ... CGI::Application seems to allow a Dave> software developer to create an entire CGI app that can be stored and Dave> distributed as a module on CPAN, but only a couple such app/modules Dave> have been so added. Maybe because it competes with OpenInteract, which is far more established. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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! Lead Programmer D.M. Contact Management 250.383.0836
Re: Templating system opinions (CGI::Application in connection with either HTML::Template or Template::Toolkit)
> "Dave" == Dave Baker <[EMAIL PROTECTED]> writes: Dave> I'm curious as to why the combination of CGI::Application and Dave> HTML::Template hasn't taken off ... CGI::Application seems to allow a Dave> software developer to create an entire CGI app that can be stored and Dave> distributed as a module on CPAN, but only a couple such app/modules Dave> have been so added. Maybe because it competes with OpenInteract, which is far more established. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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: 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?)
[EMAIL PROTECTED] wrote: Change that to: You mean 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?)
Hauck, William B. wrote: Hi, 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?)
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 ). 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?)
> Change that to: > > You mean don't you? Or did I miss the secret stealth hide-your-tags-in-html-comments feature? :-) -Fran
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 ). 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: 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?)
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 ). 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?) [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?)
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
hi ( 03.07.21 17:04 -0500 ) Nigel Hamilton: > At Turbo10 we went for a strict 'no functional elements' in the > template approach. this seems like you're placing a technical limit on your solution. why wouldn't you use the technologies that will solve your problem the best instead of constraining the 'solution space' before considering the problem fully? > But how do you do things like for displaying rows in a > report? exactly. the most intuitive way, to me, is to loop on the page. -- \js
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/". 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
> > Just wondering what the best templating system is to use > > and/or learn. > > I'm just wondering why no one recommended Embperl. Like Mason, it's more > than a templating system, but I find it's inheritance features great. I too have found template inheritance to be pretty important - especially the ability to override enclosing templates. At Turbo10 we went for a strict 'no functional elements' in the template approach. But how do you do things like for displaying rows in a report? The content management system models a HTML page (e.g., Object -> Master Template -> Page -> Form -> Subform). A presentation script is responsible for inserting the rows into the page and master template. Attributes (e.g., bgcolor) of an enclosing object (e.g., page) are inherited (or overridden) by an enclosed object (e.g., form). Each object is stored in an XMLish file, slurped into a hash, and the keys are merged. Typically a DBI row hash is also merged as there is a 1-1 correspondence between database column names and form attributes. I think the question of templating solution depends on the plan for the content management system ... NIge -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: templating system opinions
Perrin Harkins wrote: The one thing about TT was that I don't know if I really liked how it had a different syntax than perl. Plus, as far as performance, we did some specific coding to make it faster for Slash so our templates would be in the DB. That's an anti-optimization. Filesystems are faster than databases when all you want is to fetch a single item with a specific name. It's also a pain in the ass to edit things that are in a database, as opposed to just files. I agree -- filesystems have all these great new remote access protocols like ftp and scp. That's why I took this option (storing templates in the database) out of OpenInteract. Well, actually you can still do it, I just make it really tough :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: templating system opinions
On Fri, 2003-07-18 at 18:37, Patrick Galbraith wrote: > The one thing about TT was that I don't know if I really liked how it > had a different syntax than perl. Plus, as far as performance, we did > some specific coding to make it faster for Slash so our templates would > be in the DB. That's an anti-optimization. Filesystems are faster than databases when all you want is to fetch a single item with a specific name. It's also a pain in the ass to edit things that are in a database, as opposed to just files. - Perrin
Re: templating system opinions
On Mon, 21 Jul 2003, Sam Tregar wrote: > My impression is that Mason doesn't get much advantage from clients > that only use part of the Mason system. I imagine that one of the > reasons that the Mason workalike I built for Bricolage is faster than > Mason is that it only implements the functionality actually needed by > Bricolage. Following this line of thinking it might be possible to > modify Mason to only use/load the slower/bigger pieces when they are > actually needed. Of course, I'm no authority on why Mason is slow or > how it could be fixed. It's not the loading of things that's slow, it's the execution path for a request. We do have some ideas on how we can speed this up, but it'll probably involve the user choosing an optimized, less feature-ful or flexible class for something (like resolving URLs to components), rather than Mason itself trying to figure out what to optimize dynamically. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
Perrin Harkins wrote: On Mon, 2003-07-21 at 12:22, Kip Hampton wrote: Why choose one when you can have 'em all? :-) Well, no offense to AxKit, but having multiple templating systems in a single project is something that I specifically work to avoid. It complicates things and typically hurts performance. Developer time is always more costly than bigger iron so I prefer environments that let people use the tools that they know and can be nore rapidly productive with. AxKit lets me choose, and If I don't need it, I don't use it (or load it) but if I do, then its available. If I had an Apache::ASP app and wanted to use XSLT, I would just use the built-in support for it. If I had a Mason app, I would use XML::libXSLT directly. Certainly, and you wouldn't be wrong to do so. However, the instant you want to start applying different styles to content based on environemental conditions, or setting up chains of transformations, then you begin duplicating logic in your app code that AxKit already does well behind the scenes by adding a directive or two to your httpd.conf. "Horses for courses" as the saying goes; personally, I prefer having more choices. -kip
Re: templating system opinions
On Mon, 21 Jul 2003, Dave Rolsky wrote: > On Mon, 21 Jul 2003, Sam Tregar wrote: > > > I wouldn't be too sure. I implemented a lot of that stuff to add > > HTML::Template support to Bricolage and it's still much faster than > > Mason. > > "A lot" as in _all_ of it, or a "lot" as in autohandlers and dhandlers? "A lot" as in everything that was needed to get HTML::Template to fill the role of Mason in Bricolage's publish process. I'd certainly be a fool to claim I'd implemented all of Mason! I doubt I could even list all the stuff that Mason does. > In other words, I don't think one could do all of the same stuff, or > even most, and achieve a huge speed increase. There would have to > be something sacrificed. My impression is that Mason doesn't get much advantage from clients that only use part of the Mason system. I imagine that one of the reasons that the Mason workalike I built for Bricolage is faster than Mason is that it only implements the functionality actually needed by Bricolage. Following this line of thinking it might be possible to modify Mason to only use/load the slower/bigger pieces when they are actually needed. Of course, I'm no authority on why Mason is slow or how it could be fixed. I have plans to go a similar route with HTML::Template in the future. I'd like to build a system that dynamically assembles itself based on the usage pattern of the program. That way if the programmer sticks to the basics they get a smaller, faster system. If they need the big guns then the more complete systems can be loaded at some moderate penalty. -sam
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/". 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
Re: templating system opinions
On Mon, 2003-07-21 at 12:22, Kip Hampton wrote: > And don't forget that, with AxKit, you can use Apache::ASP, Mason, or > any Apache::Filter-aware handler to provide content for AxKit to > transform and TT2 as a transformational language. Oh, and there's > XPathScript, too, which, although its only one part of AxKit, is really > a novel "templating/trasformation" language all on its own... > > Why choose one when you can have 'em all? :-) Well, no offense to AxKit, but having multiple templating systems in a single project is something that I specifically work to avoid. It complicates things and typically hurts performance. If I had an Apache::ASP app and wanted to use XSLT, I would just use the built-in support for it. If I had a Mason app, I would use XML::libXSLT directly. - Perrin
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 A&M CIS Operating Systems Group, Unix
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
On Mon, 21 Jul 2003, Sam Tregar wrote: > On Sun, 20 Jul 2003, Dave Rolsky wrote: > > > OTOH, if you were to try to replicate some of Mason's more powerful > > features with H::T, like autohandlers, inheritance, etc., then I'm > > sure that'd bring H::T's speed down to Mason's level ;) > > I wouldn't be too sure. I implemented a lot of that stuff to add > HTML::Template support to Bricolage and it's still much faster than > Mason. "A lot" as in _all_ of it, or a "lot" as in autohandlers and dhandlers? I'll believe it when I see it. There's nothing about Mason that's particularly slow except the code that implements the features. In other words, I don't think one could do all of the same stuff, or even most, and achieve a huge speed increase. There would have to be something sacrificed. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
On Sun, 20 Jul 2003, Dave Rolsky wrote: > OTOH, if you were to try to replicate some of Mason's more powerful > features with H::T, like autohandlers, inheritance, etc., then I'm > sure that'd bring H::T's speed down to Mason's level ;) I wouldn't be too sure. I implemented a lot of that stuff to add HTML::Template support to Bricolage and it's still much faster than Mason. > In other words, you generally get what you pay for. The most powerful and > flexible systems are generally slower and more RAM-hungry. One exception > to this might be Embperl, which has large chunks written in C. In that > case, the cost is paid for in development time. HTML::Template::JIT also trades development time (mine) for run-time speed. Right now it doesn't support all of HTML::Template's functionality, but it comes pretty close. The upside is that it's between four and eight times faster than HTML::Template, which makes it the fastest templating system by a large margin. -sam
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
On Mon, 21 Jul 2003, Patrick Galbraith wrote: > I'm guessing they use it for IMDB, although they may have other > projects as well that use it. I do know that their core app is > C++/apache, with some sort of perl glue to talk to the app. I believe IMDB uses mod_perl, but I don't know about Mason. I know Amazon is using Mason for _Amazon_, not things they've bought. They're using it for the their apparel shop, among other things. I don't want to say too much more because I'm hoping for a bigger announcement from more reputable sources, but I can't promise anything ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
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/". 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?)
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/". 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
I'm guessing they use it for IMDB, although they may have other projects as well that use it. I do know that their core app is C++/apache, with some sort of perl glue to talk to the app. Nice that they are such an apache/perl/OS house considering they're here in Seattle, mere miles from Redmond ;) They're also not one of several places who think jumping on the java bandwagon is the path to enlightenment. Ehem. On Mon, 21 Jul 2003, Dave Rolsky wrote: > On Mon, 21 Jul 2003, Drew Taylor wrote: > > > I personally have not seen an "official" announcement, but if you look > > at all their postings on jobs.perl.org you'll notice that nearly every > > one of them mentions Mason. I'm sure Dave will have more to say on the > > subject... :-) > > Not too much more. But hopefully more will be forthcoming from people > closer to Amazon than I. > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/ > -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: templating system opinions
On Mon, 21 Jul 2003, Drew Taylor wrote: > I personally have not seen an "official" announcement, but if you look > at all their postings on jobs.perl.org you'll notice that nearly every > one of them mentions Mason. I'm sure Dave will have more to say on the > subject... :-) Not too much more. But hopefully more will be forthcoming from people closer to Amazon than I. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
Matt Sergeant wrote: (you can of course use XSLT in AxKit :-) And don't forget that, with AxKit, you can use Apache::ASP, Mason, or any Apache::Filter-aware handler to provide content for AxKit to transform and TT2 as a transformational language. Oh, and there's XPathScript, too, which, although its only one part of AxKit, is really a novel "templating/trasformation" language all on its own... Why choose one when you can have 'em all? :-) -kip
Re: templating system opinions
I wanted to add that you *can* use Mason for MVC type programming. I do that on my current big project, www.better-investing.org, in the admin areas. I have a controller index.html page which chooses what component to run based on a run mode, just like CGI::Application, but then gives me all of the other stuff like autohandlers for the display. I'm using Template Toolkit and Apache Handlers (which work like CGI::Application) for another project. I'm not sure which I like better at the moment. I'm much faster in Mason still. -- Barry Hoggard Tristan Media LLC e: [EMAIL PROTECTED] w: www.tristanmedia.com aim: hoggardb
RE: templating system opinions
> In a good OO system with objects > representing the > data model, I found it exhausting to use H::T when I could > just to this > in TT: > > [% user.name %] > > > Am I just being stupid, or are there better ways of doing > these things > in H::T? I'm a little late to the dance but I generally unplug over the weekend. We use H::T here and I too got annoyed with the need to flatten all of my objects. However, with so much invested in H::T by that time, we just wrote a toHash() method which is inherited by all of our objects. It predictably takes the object attributes and churns out a hash (and is smart enough to do a recursive descent if need be). It also take an optional "prefix" so that you could pass in a prefix of "user." and then be able to if you wanted. It was an easy way to reduce the pain of H::T and yet not reinvent the wheel. A simple $tmpl->param($myObj->toHash(prefix => 'user.')) works fairly well in most cases. I'm sure there's a better/more robust way to do it (yeah, switch to TT ;-) but we found that this was sufficient to reduce the annoyance factor enough to allow us to get on with it. Also, we use HTML::Template::Expr to cheat liberally where appropriate. :-) Separation of HTML and logic is a good thing, but like most good things, there are exceptions. Since our controllers were starting to get really cluttered with a lot of "if this simple thing is true then pass this boolean to the template since the template itself can't ask whether this simple thing is true" code, which HTML::Template::Expr helps ease. Hope that helps. I really like H::T for it's simplicity and ease of understanding and picking up for new folks, and didn't want to toss that away unless I had to. -Fran
Re: templating system opinions
Jesse Erlbaum wrote: Dave Rolsky writes: Sure, amazon.com among them. Amazon.com uses Mason? Why have I not heard of this before? I personally have not seen an "official" announcement, but if you look at all their postings on jobs.perl.org you'll notice that nearly every one of them mentions Mason. I'm sure Dave will have more to say on the subject... :-) -- - Drew Taylor * Web app development & consulting [EMAIL PROTECTED] * Site implementation & hosting www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres -
RE: templating system opinions
Hi Dave -- Dave Rolsky writes: > > Mason isn't fast. It is, however, fast enough for high > volume sites - > > that I will assert. > > Sure, amazon.com among them. Amazon.com uses Mason? Why have I not heard of this before? -Jesse-
Re: templating system opinions
On Monday, Jul 21, 2003, at 02:23 Europe/London, Dave Rolsky wrote: 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. And lets not forget XML templating solutions too, like XSLT, which probably out scores them all in job postings terms (although not all that work is perl related). Matt. (you can of course use XSLT in AxKit :-)
RE: templating system opinions
> Just wondering what the best templating system is to use > and/or learn. Hi, I'm just wondering why no one recommended Embperl. Like Mason, it's more than a templating system, but I find it's inheritance features great. I'm using it for a personal project and haven't really checked it's performance, but there's no doubt it integrates well with mod_perl and allows you to use existing perl code, packages/objects on your site with ease. What do you guys think about it? Cameron
Re: templating system opinions
On Sun, 20 Jul 2003, Jamie Lawrence wrote: > Mason isn't fast. It is, however, fast enough for high volume sites - > that I will assert. Sure, amazon.com among them. > From my view, the utility of autohandlers and dhandlers, in terms of > code written vs. cost and time, is an enormous win. Add to that the > flexibility between library developmers and HTML coders, in that there's > a constant feedback loop that enforces reasonable development and > interaction to ensure that all roles are working for the same goal. I'm not gonna disagree with you. I consider Mason's features well worth the speed/memory costs. That's why I use it and develop it ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
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 ===*/
Re: templating system opinions
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 really like the syntax - it looks a lot like JSP. They serve out around 12-13M pageviews a day using it. It just doesn't have a lot of active contributors to it now. Eventually, they will switch to java/atg dynamo. ... All of this said, what is the most commonly used system out there? Jesse Erlbaum wrote: Hi Chris, Patrick -- I post on this topic with some reluctance. Asking which templating system is best is like asking which operating system is best -- or which political party is best (or political system, I suppose). It's Jihad, baby! OTOH, I've never met a flamethrower I didn't like. What's "best" depends on what your requirements are. As far as I can tell, the big ones are Template::Toolkit, Mason, and HTML::Template One picky point: Mason is NOT a templating system. It is a programming system. If you're going to call Mason a templating system, you might as well refer to Perl as a templating system: my $name = "Jesse"; print "Hello, my name is $name\n"; Presto, blammo -- a new templating system! The big players are Template::Toolkit and HTML::Template. It's no secret that I'm a fan of HTML::Template -- Sam and I worked together when he wrote it, and my module, CGI::Application, uses it out of the box (although it does support TT). I use HTML::Template because designers can't be trusted to set variables. Boolean logic is about all their simple minds can handle. Anything which doesn't look like HTML is likely to cause them to have a stroke. Yes, I'm a programmer-snob and a fascist, and I like to take sharp objects away from the gentle "creative" types. Aside from the fact that HTML::Template uses less RAM and is faster than TT, this is the foremost reason I continue to use it. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 -- -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 206.719.2461
Re: templating system opinions
On Sun, 20 Jul 2003, Dave Rolsky wrote: > Actually, H::T is almost certainly _much_ faster and less RAM-intensive > than Mason, at least when you measure the time it takes to serve a single > page/component. OTOH, if you were to try to replicate some of Mason's > more powerful features with H::T, like autohandlers, inheritance, etc., > then I'm sure that'd bring H::T's speed down to Mason's level ;) Fair enough. I haven't actually deployed anything under H::T. I've played with it, and some of it I like. I have stolen part of it for deployment, but it ended up really mangled and site specific, so that doesn't count. Mason isn't fast. It is, however, fast enough for high volume sites - that I will assert. From my view, the utility of autohandlers and dhandlers, in terms of code written vs. cost and time, is an enormous win. Add to that the flexibility between library developmers and HTML coders, in that there's a constant feedback loop that enforces reasonable development and interaction to ensure that all roles are working for the same goal. And in general, I don't care about RAM. A 1G server is cheap. Tune apache properly and you have no problems for sites approaching .25M visits/day. If you need to exceed that, you need multiple front-end boxes. But if you're doing that amount of traffic, you probably need redundancy anyway, so the issue is moot. > In other words, you generally get what you pay for. The most powerful and > flexible systems are generally slower and more RAM-hungry. One exception > to this might be Embperl, which has large chunks written in C. In that > case, the cost is paid for in development time. Agreed. In general, I love Mason, but still do write mod_perl interfaces for some things, when performance is important. For that matter, I push a lot of work onto the database, and then write C extensions to it to handle specific performance problems. Apache, perl, mason, postgres is a kickass combination, where you can fix almost any problem, quickly and cheaply. As usual, this pushes back at the developer, who is obligated to make the right choice. It is certainly not the only choice, but it is the right one(tm) for me. Again, I'm offering opinion, based on my particular experiences. Nothing more, nothing less. -j, who used to run custom NSAPI modules talking to Oracle under NES under high loads, and is an unabashed fan of mod_perl. -- Jamie Lawrence[EMAIL PROTECTED] "People should be allowed to keep midgets as pets." - Gov. Jesse Ventura
Re: templating system opinions
>> Barry Hoggard wrote: >> I used to use HTML::Template for projects, but I moved to >> Template::Toolkit because I felt the former's syntax was just too >> limited. I know we want to separate code and logic, but H::T >> keeps me [skip] JE> Jesse Erlbaum JE> Programmer: Get object, Get object attribute JE> HTML Designer: Display attribute JE> This is no more than a philosophical difference. HTML::Template assumes JE> HTML designers should never do programming tasks, and implements this JE> philosophy by not opening the "code floodgate" at all. TT believes that JE> there is some amount of code you want your designer to do. [skip] Hello. Absolutely agree with Jesse. I've started with my own simple templating module, but step by step I've come to HT. Why HT? 1) It isn't framework, just templates. I'm trying to write my own framework. 2) Relatively fast. 3) Separate code and design. 4) Enough simple syntax to designers. When I was doing selection I just read comparison from perl.apache.org. Satisfied with the choice still. Best regards, Ruslan.
Re: templating system opinions
On Sun, 20 Jul 2003, Jamie Lawrence wrote: > H::T is much more programmer-centric. In a lot of contexts, that makes > sense. Informally (as in, I haven't done a systematic comparison), it is > also faster than Mason. Mason isn't slow, but if you need every last > gram of performance, well, you probably shouldn't be using a general > framework anyway. > > And yes, they're all RAM-intensive. I don't actually care that much - > RAM is cheap for general purpose servers. Actually, H::T is almost certainly _much_ faster and less RAM-intensive than Mason, at least when you measure the time it takes to serve a single page/component. OTOH, if you were to try to replicate some of Mason's more powerful features with H::T, like autohandlers, inheritance, etc., then I'm sure that'd bring H::T's speed down to Mason's level ;) In other words, you generally get what you pay for. The most powerful and flexible systems are generally slower and more RAM-hungry. One exception to this might be Embperl, which has large chunks written in C. In that case, the cost is paid for in development time. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
On Fri, 18 Jul 2003, Dave Rolsky wrote: > On Fri, 18 Jul 2003, Patrick Galbraith wrote: > > > TT was ok, but it did use a bunch of ram ;) > > So does Mason. HTML::Template is no doubt much leaner, but it's also lean > on features. Nothing wrong with that if it suits your needs, though. > > Most Perl templating systems are probably slower and/or bulkier than PHP. > > The best counter for PHP folks is one word, "CPAN" ;) > > Also, Mason at least provides lots of features beyond templating, and is > as much of an app framework as anything. This may be true of TT and the > others, I'm not really sure. Just to chime in here, Mason is very much a framework. It expresses a particular view of web site development. I'm a huge fan of it, personally, but putting that aside, Mason is mainly about finding the proper balance between code monkey and html monkey. The slightly amusng thing, and what I take as a vote for Mason having found the balance, is that radically different styles of coding have evolved - I recently downloaded the code behind www.masonhq.com, and compared it to how we do things, and was shocked and appalled. And picked up some really good ideas... In general, Mason allows an HTMLer to become more of a programmer, and also requires programmers to be HTML savvy, or at least HTML sensitive. I find this a good thing. H::T is much more programmer-centric. In a lot of contexts, that makes sense. Informally (as in, I haven't done a systematic comparison), it is also faster than Mason. Mason isn't slow, but if you need every last gram of performance, well, you probably shouldn't be using a general framework anyway. And yes, they're all RAM-intensive. I don't actually care that much - RAM is cheap for general purpose servers. Just buzzing in with opinion - which is what I think the original poster was soliciting. HTH, my $.02, not a holy warrior, etc. -j -- Jamie Lawrence[EMAIL PROTECTED] The significant problems we face cannot be solved by the same level of thinking that created them. - Albert Einstein
RE: templating system opinions
> Just wondering what the best templating system is to use > and/or learn. Hi, I'm just wondering why no one recommended Embperl. Like Mason, it's more than a templating system, but I find it's inheritance features great. I'm using it for a personal project and haven't really checked it's performance, but there's no doubt it integrates well with mod_perl and allows you to use existing perl code, packages/objects on your site with ease. What do you guys think about it? Cameron
Re: templating system opinions
Jesse Erlbaum wrote: Hey Ken -- Search the guide: http://perl.apache.org/search/swish.cgi?query=template&sbm=&submit=sear ch I'm deeply amused that there are nearly as many articles about templating systems on perl.apache.org (30) as there are templating modules on CPAN! The search shows matching sections, not articles. Most of these matches belong to a single tutorial: http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html __ 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: templating system opinions
Hey Barry! > I used to use HTML::Template for projects, but I moved to > Template::Toolkit because I felt the former's syntax was just too > limited. I know we want to separate code and logic, but H::T > keeps me > from even referencing the attribute of an object. You can't say > > > > and pass in a user object with the attribute (method) or even > a hash key called name. Of course you can do this, but not in exactly that way. There are three tasks which have to be completed to perform the operation you describe: 1. Get object 2. Get object attribute 3. Display attribute Imagine two lists of responsibilities: one for the programmer and one for the HTML designer. In the scheme you describe you've allocated the responsibility as follows: Programmer: Get object HTML Designer: Get object attribute, Display attribute With HTML::Template the responsibilities are exactly the same -- it's just the allocation which is different: Programmer: Get object, Get object attribute HTML Designer: Display attribute This is no more than a philosophical difference. HTML::Template assumes HTML designers should never do programming tasks, and implements this philosophy by not opening the "code floodgate" at all. TT believes that there is some amount of code you want your designer to do. TT hopes that you will limit your use of these capabilities to "simple" things (such as retrieval of an object attribute). Unfortunately, the floodgate is opened and allocation of responsibility is completely arbitrary. TT users can (and do) allocate responsibilities like this: Programmer: ??? HTML Designer: Get object, Get object attribute, Display attribute The programmer doesn't seem to have anything to do anymore. "That's great," says the client, "programmers are really expensive!" Of course, that "HTML Designer" is not really an HTML Designer anymore: HTML Designer/Programmer: Do it all. If you have access to a lot of people who are expert designers and programmers, that's great. Let me know where you find them! I've been looking for years. ;-) TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: templating system opinions
Jesse Erlbaum wrote: The big players are Template::Toolkit and HTML::Template. It's no secret that I'm a fan of HTML::Template -- Sam and I worked together when he wrote it, and my module, CGI::Application, uses it out of the box (although it does support TT). I use HTML::Template because designers can't be trusted to set variables. Boolean logic is about all their simple minds can handle. Anything which doesn't look like HTML is likely to cause them to have a stroke. Yes, I'm a programmer-snob and a fascist, and I like to take sharp objects away from the gentle "creative" types. Aside from the fact that HTML::Template uses less RAM and is faster than TT, this is the foremost reason I continue to use it. I used to use HTML::Template for projects, but I moved to Template::Toolkit because I felt the former's syntax was just too limited. I know we want to separate code and logic, but H::T keeps me from even referencing the attribute of an object. You can't say and pass in a user object with the attribute (method) or even a hash key called name. You have to either treating it like a loop with one item (because loops use arrayrefs of hashrefs) or flatten it into variable names in your code. In a good OO system with objects representing the data model, I found it exhausting to use H::T when I could just to this in TT: [% user.name %] Am I just being stupid, or are there better ways of doing these things in H::T? -- Barry Hoggard Tristan Media LLC e: [EMAIL PROTECTED] w: www.tristanmedia.com aim: hoggardb
Re: templating system opinions - Mason recommendation
> "Stas" == Stas Bekman <[EMAIL PROTECTED]> writes: Stas> While Andy is working on it, you can read a TT for mod_perl chapter in Stas> "Practical mod_perl", written by Andy as well! (http://modperlbook.org) Man, that guy is *everywhere*! :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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: templating system opinions
Hi Patrick -- > I gotta have something to counter PHP people with too ;) Dave is right: "CPAN" is a very compelling argument. OTOH, it you've already cast your lot with using a "server page system" (a la Mason, ASP, JSP, ColdFusion), PHP is a pretty compelling choice. It's new, sexy, lightweight, more or less capable, and has lots of buzz. However: Another compelling argument in favor of Perl (against PHP) is an argument in favor of using an controller-based system instead of a server page system. A controller-based system (such as CGI::Application or mod_perl handlers) combined with a true templating system, such as TT or HTML::Template, makes the templates subservient to the application logic. This is the opposite of server page systems which put the template in change of choosing functionality. In the latter, an HTTP request goes to a template which controls execution. If the template in this system decides that a different template should be displayed, chaos erupts -- redirect city, snarls of spaghetti code. In a controller-based system, the HTTP request goes to a controller which runs the logic and then chooses a template. This is a more rational chain of events, allowing the form to *follow* function -- literally. The controller can naturally choose which template without having to twist itself in a pretzel to do so. Add to that the fact that in spite of the claim that it is possible to separate code from HTML in a server page system, in reality it is too difficult and nobody does it. OTOH, if you can't fight the PHP wave, here's an alternative: Offer to "prototype" the system in Perl, and migrate it to PHP! It so happens that a fellow named Tomas Styblo ([EMAIL PROTECTED]) wrote a version of HTML::Template for PHP: http://htmltmpl.sourceforge.net/ This means that you could quickly, and cheaply get a system up and running with Perl and HTML::Template, and migrate it eventually to PHP. (If the "prototype" happens to be so good that it takes the wind out of the sails of migration, so be it.) TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
RE: templating system opinions
Hey Ken -- > Search the guide: > >http://perl.apache.org/search/swish.cgi?query=template&sbm=&submit=sear ch I'm deeply amused that there are nearly as many articles about templating systems on perl.apache.org (30) as there are templating modules on CPAN! TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
RE: templating system opinions
Hi Chris, Patrick -- I post on this topic with some reluctance. Asking which templating system is best is like asking which operating system is best -- or which political party is best (or political system, I suppose). It's Jihad, baby! OTOH, I've never met a flamethrower I didn't like. > What's "best" depends on what your requirements are. As far > as I can tell, > the big ones are Template::Toolkit, Mason, and > HTML::Template One picky point: Mason is NOT a templating system. It is a programming system. If you're going to call Mason a templating system, you might as well refer to Perl as a templating system: my $name = "Jesse"; print "Hello, my name is $name\n"; Presto, blammo -- a new templating system! The big players are Template::Toolkit and HTML::Template. It's no secret that I'm a fan of HTML::Template -- Sam and I worked together when he wrote it, and my module, CGI::Application, uses it out of the box (although it does support TT). I use HTML::Template because designers can't be trusted to set variables. Boolean logic is about all their simple minds can handle. Anything which doesn't look like HTML is likely to cause them to have a stroke. Yes, I'm a programmer-snob and a fascist, and I like to take sharp objects away from the gentle "creative" types. Aside from the fact that HTML::Template uses less RAM and is faster than TT, this is the foremost reason I continue to use it. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: templating system opinions - Mason recommendation
Chris Devers wrote: [...] A little bird tells me that TT is about to get an O'Reilly book as well, though it's not on their upcoming titles page (yet). While Andy is working on it, you can read a TT for mod_perl chapter in "Practical mod_perl", written by Andy as well! (http://modperlbook.org) __ 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: templating system opinions
On Fri, 18 Jul 2003, Patrick Galbraith wrote: > TT was ok, but it did use a bunch of ram ;) So does Mason. HTML::Template is no doubt much leaner, but it's also lean on features. Nothing wrong with that if it suits your needs, though. Most Perl templating systems are probably slower and/or bulkier than PHP. The best counter for PHP folks is one word, "CPAN" ;) Also, Mason at least provides lots of features beyond templating, and is as much of an app framework as anything. This may be true of TT and the others, I'm not really sure. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
TT was ok, but it did use a bunch of ram ;) I gotta have something to counter PHP people with too ;) On Fri, 18 Jul 2003, Chris Devers wrote: > On Fri, 18 Jul 2003, Patrick Galbraith wrote: > > > Yeah, I worked with TT when I was on the Slash team ;) > > Then why are you asking a question like this?? :) > > > -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: templating system opinions
On Fri, 18 Jul 2003, Patrick Galbraith wrote: > Yeah, I worked with TT when I was on the Slash team ;) Then why are you asking a question like this?? :) -- Chris Devers [EMAIL PROTECTED] http://devers.homeip.net:8080/ Turing machine, n. [After Alan M. Turing (1912-1954), British mathematician and computer pioneer.] The earliest but still the fastest and most reliable computing system ever conceived. "Dis maschine vill run und run" (K. Godel). -- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995
Re: templating system opinions - Mason recommendation
On Fri, 2003-07-18 at 17:23, Chris Devers wrote: > > Correction: Bricolage is written in Mason, I believe. That's what the > > Bricolage authors say at http://bricolage.cc/ > > Hmm, so it does. I wonder where I got the idea that it was H::T based... The data entry UI is in Mason, but it can optionally publish the resulting articles through H::T. See http://bricolage.cc/docs/Bric/HTMLTemplate.html for more. - Perrin
Re: templating system opinions
The one thing about TT was that I don't know if I really liked how it had a different syntax than perl. Plus, as far as performance, we did some specific coding to make it faster for Slash so our templates would be in the DB. On 18 Jul 2003, Mark Maunder wrote: > Hey Peter, > > Template Toolkit rocks! (Sorry about the overt glee, but I am just > finishing a project where it has been very good to me) Besides the > complete seperation that it gives you between presentation and back-end > coding, it's super fast. I benchmarked a 2GHz server with 256 Megs of > RAM using ab (Apache bench) with around 10 concurrent requests and a > total of 10,000 requests and was able to handle over 40 hits per second > on our most dynamic page which has lots of conditionals and loops and > even does a few function calls like this [% IF sess.is_logged_in %] > where 'sess' is a perl object. NOTE: Make sure you cache your template > object in package globals or something like that, or you'll lose > performance. > > I've written a couple of workable templating systems myself with good > old $html =~ s///egs and a content handler (as a perl developers rite of > passage don't ya know) and I wouldn't recommend it because you end up > with something non-standard, and are basically re-inventing template > toolkit which seems to have become the standard in templating over the > last coupla years. > > Old, but still useful benchmarks if you're interested: > http://www.chamas.com/bench/ > > mark. > > On Fri, 2003-07-18 at 13:26, Ken Y. Clark wrote: > > On Fri, 18 Jul 2003, Patrick Galbraith wrote: > > > > > Date: Fri, 18 Jul 2003 14:25:32 -0700 (PDT) > > > From: Patrick Galbraith <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > > > Subject: templating system opinions > > > > > > Hi there, > > > > > > Just wondering what the best templating system is to use and/or learn. > > > > > > I've briefly read up on the pros and cons of each, and am just wondering > > > which one is the most widely _used_ and best to learn if you're wanting to > > > know something that there are jobs for. > > > > > > thanks ;) > > > > Search the guide: > > > > http://perl.apache.org/search/swish.cgi?query=template&sbm=&submit=search > > > > ky > -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: templating system opinions
Thanks much, Yeah, I worked with TT when I was on the Slash team ;) On Fri, 18 Jul 2003, Chris Devers wrote: > On Fri, 18 Jul 2003, Patrick Galbraith wrote: > > > Just wondering what the best templating system is to use and/or learn. > > > > I've briefly read up on the pros and cons of each, and am just wondering > > which one is the most widely _used_ and best to learn if you're wanting to > > know something that there are jobs for. > > What's "best" depends on what your requirements are. As far as I can tell, > the big ones are Template::Toolkit, Mason, and HTML::Template; each one > makes different tradeoffs and makes different assumptions about the > division of labor among programmers, web developers, & content producers. > TT is probably the most flexible, but that or might not be what you want. > > Honestly, of the three I just listed, none of them are *that* complicated. > If you want to learn these for job hunting purposes -- in which case it's > not really fair to ask you what the requirements are, since you can't > really know that -- you might as well experiment with all three. > > A good way to start might be by playing with different content management > etc platforms that use these toolkits. From what I've read, the biggest > examples I can think of are: > > * Slashcode (TT based, runs slashdot.org) > > * Bricolage (H::T, http://www.bricolage.cc/docs/Bric/HTMLTemplate.html, >CMS used by theregister.co.uk et al) > > * Request Tracker (excellent ticketing system, runs http://rt.cpan.org/, >home page is http://www.bestpractical.com/rt) > > Any of these can be downloaded & used freely. If you have the time for it, > grab a copy of one or more and start playing around. > > Have fun :) > > > -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: templating system opinions - Mason recommendation
Chris Devers sent the following bits through the ether: > It's a pretty clever approach; I'd like to see something like this done > with a Perl backend (I haven't really been keeping track of development, > for all I know there already is a Perl backend...). Read more: Your wish is my command. Witness the amazing appearance of "Petal - Perl Template Attribute Language - TAL for Perl!" on the rather tastefully-coloured: http://search.cpan.org/author/JHIVER/Petal-1.00/lib/Petal.pm Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Have you seen Quasimoto? I have a hunch he's back!
Re: templating system opinions - Mason recommendation
Sorry to cc: this to the list, but I stand corrected and might as well mention that to the list :) On Fri, 18 Jul 2003, Dave Baker wrote: > Correction: Bricolage is written in Mason, I believe. That's what the > Bricolage authors say at http://bricolage.cc/ Hmm, so it does. I wonder where I got the idea that it was H::T based... > I'm very pleased with Mason -- the online O'Reilly book about Mason is > at http://www.masonbook.com/book/ A little bird tells me that TT is about to get an O'Reilly book as well, though it's not on their upcoming titles page (yet). The only H::T dead-trees material that I know of is a section in _CGI Programming with Perl_, 2nd edition -- that's where I learned it. I like the simplicity of H::T, but most other people seem to prefer TT or Mason. I still think it comes down to whichever system meets your needs the best, and in different contexts any of them (or others) could be appropriate. This may have been covered before here, but Zope supports an interesting template mechanism called TAL, where everything is done by attributes for the HTML tags, rather than special logical tags as most other systems use (e.g. the ones mentioned above, SSI, PHP, ASP, JSP, etc). This has the nice side effect of guaranteeing that all your html templates are always valid, and so can be used in any html IDE without complication. So for example, picking a random sample from the spec: Repeat Syntax: argument ::= variable_name expression variable_name ::= Name When you want to replicate a subtree of your document once for each item in a sequence, you use repeat. The expression should evaluate to a sequence. If the sequence is empty, then the statement element is deleted, otherwise it is repeated for each value in the sequence. If the action is cancelled, then the element is left unchanged, and no new variables are defined. The variable_name is used to define a local variable and a repeat variable. For each repetition, the local variable is set to the current sequence element, and the repeat variable is set to an iteration object. You use iteration objects to access information about the current repetition (such as the repeat index). (Iteration objects are more properly the domain of TALES.) The repeat variable has the same name as the local variable, but is only accessible through the builtin variable named repeat (see RepeatVariable). Examples: 1 Widget $1.50 It's a pretty clever approach; I'd like to see something like this done with a Perl backend (I haven't really been keeping track of development, for all I know there already is a Perl backend...). Read more: http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4 But anyway, Zope isn't mod_perl, so that's probably not what the original person was hoping to read about... :) -- Chris Devers[EMAIL PROTECTED]
Re: templating system opinions
Hey Peter, Template Toolkit rocks! (Sorry about the overt glee, but I am just finishing a project where it has been very good to me) Besides the complete seperation that it gives you between presentation and back-end coding, it's super fast. I benchmarked a 2GHz server with 256 Megs of RAM using ab (Apache bench) with around 10 concurrent requests and a total of 10,000 requests and was able to handle over 40 hits per second on our most dynamic page which has lots of conditionals and loops and even does a few function calls like this [% IF sess.is_logged_in %] where 'sess' is a perl object. NOTE: Make sure you cache your template object in package globals or something like that, or you'll lose performance. I've written a couple of workable templating systems myself with good old $html =~ s///egs and a content handler (as a perl developers rite of passage don't ya know) and I wouldn't recommend it because you end up with something non-standard, and are basically re-inventing template toolkit which seems to have become the standard in templating over the last coupla years. Old, but still useful benchmarks if you're interested: http://www.chamas.com/bench/ mark. On Fri, 2003-07-18 at 13:26, Ken Y. Clark wrote: > On Fri, 18 Jul 2003, Patrick Galbraith wrote: > > > Date: Fri, 18 Jul 2003 14:25:32 -0700 (PDT) > > From: Patrick Galbraith <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: templating system opinions > > > > Hi there, > > > > Just wondering what the best templating system is to use and/or learn. > > > > I've briefly read up on the pros and cons of each, and am just wondering > > which one is the most widely _used_ and best to learn if you're wanting to > > know something that there are jobs for. > > > > thanks ;) > > Search the guide: > > http://perl.apache.org/search/swish.cgi?query=template&sbm=&submit=search > > ky -- Mark Maunder <[EMAIL PROTECTED]> ZipTree Inc.
Re: templating system opinions
On Fri, 18 Jul 2003, Patrick Galbraith wrote: > Just wondering what the best templating system is to use and/or learn. > > I've briefly read up on the pros and cons of each, and am just wondering > which one is the most widely _used_ and best to learn if you're wanting to > know something that there are jobs for. What's "best" depends on what your requirements are. As far as I can tell, the big ones are Template::Toolkit, Mason, and HTML::Template; each one makes different tradeoffs and makes different assumptions about the division of labor among programmers, web developers, & content producers. TT is probably the most flexible, but that or might not be what you want. Honestly, of the three I just listed, none of them are *that* complicated. If you want to learn these for job hunting purposes -- in which case it's not really fair to ask you what the requirements are, since you can't really know that -- you might as well experiment with all three. A good way to start might be by playing with different content management etc platforms that use these toolkits. From what I've read, the biggest examples I can think of are: * Slashcode (TT based, runs slashdot.org) * Bricolage (H::T, http://www.bricolage.cc/docs/Bric/HTMLTemplate.html, CMS used by theregister.co.uk et al) * Request Tracker (excellent ticketing system, runs http://rt.cpan.org/, home page is http://www.bestpractical.com/rt) Any of these can be downloaded & used freely. If you have the time for it, grab a copy of one or more and start playing around. Have fun :) -- Chris Devers [EMAIL PROTECTED] http://devers.homeip.net:8080/ drag'n'drop, v. To throw away your mouse after the first attempt to copy a file leads to its deletion. See also TRASH CAN. -- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995
Re: templating system opinions
On Fri, 18 Jul 2003, Patrick Galbraith wrote: > Date: Fri, 18 Jul 2003 14:25:32 -0700 (PDT) > From: Patrick Galbraith <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: templating system opinions > > Hi there, > > Just wondering what the best templating system is to use and/or learn. > > I've briefly read up on the pros and cons of each, and am just wondering > which one is the most widely _used_ and best to learn if you're wanting to > know something that there are jobs for. > > thanks ;) Search the guide: http://perl.apache.org/search/swish.cgi?query=template&sbm=&submit=search ky
Re: Feature sets [was Re: Templating System]
Stas Bekman wrote: > > I believe XML is a way too heavy for docs writing. Why one will want to > get a messy source code, when you can get away with a minimalistic POD. > Just look at the Guide's source code and look at the generated PDF -- > isn't it great? I love POD. And if you want more than POD provides, it > takes secs to add the new functionality. I agree. XML has a nice "cool" factor, but I want to make this guide as simple as possible. > As for POD, I've already extended the POD in POD2HTML (which was buggy > anyway). For example, I've added new directives for embedding images, > linking to files and more... I don't afraid to extend the POD since I can > easily convert all my extended pod files back into the standard POD > format. So if you want a syntax for tables, this should be easy to add, > like: > > =table args > > =tr args > > =td args > > ... > > =/td > > =/tr > > =/table That might be a useful extension. How do you do tables now? "=for html"? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: [doc writing] (was Re: Feature sets [was Re: Templating System])
> > But you forget about the benefits of the source code editing, which is > > diff and tools working with it. Surely enough big editors support their > > own diff formats and tools, but they aren't possessed by many people. And > > with POD everybody has a text editor :) > > As with XML :) But XML tends to look like HTML which is quite noisy. > > > Ugh... I believe SDF has better support for tables, without resorting to > > > nastiness like that. I think if you like POD, you'll love SDF, Stas. > > > > > > http://www.mincom.com/mtr/sdf/ > > > > Thanks for the link, Matt. I've seen this technology a while ago. The > > reason that I didn't use it, is that it's a much bigger superset of syntax > > that I need. If all I miss is a tables formatting, I'd rather add this > > support than go for a complete format change. > > I wonder if it would be easy to rip the table support out of SDF and use > that, rather than change completely to SDF. I find table support to be > POD's only real severe weakness. Sounds like a good idea. I don't know what's the status of POD under perl5.6 and what are the plans. I think TomC is still in charge of this module. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Feature sets [was Re: Templating System]
Gunther Birznieks wrote: > > One book I would highly recommend on CVS is Open Source Development with > CVS by Karl Franz Fogel. I found it to be not only highly informative but > an incredibly fun read as well. Each of the semi-dry CVS chapters is > followed up by a fun anecdotal chapter about open source development > processes and how and why they work (esp focusing if possible on how CVS > helps that process). > > I've also found it to be a better "advanced" reference than any of the CVS > documentation I have. Somehow it just "feels" indexed better. I own no > stock in Coriolis Books by the way. :) I have read most of this book, and I agree that it is very well done. I was a total newbie at CVS, and now I can do everything I need on a daily basis. I still don't understand tags very well, but I haven't studied that part of the book much. > Stas does make the source available to the guide generator. Download the > guide from CPAN and poke around the distribution... :) > > We've been using it to do ALL our extropia documentation for 2 months now > (actually we use a modified older version, and am waiting to get some time > to upgrade since Stas has done many improvements). > > Does this format look familiar (albeit a little old)? > http://www.extropia.com/docs/webdb/ > > It's really awesome. I generate standalone HTML for standalone distribution > of scripts, HTML docs that integrate into the look and feel of our website, > and PDF within seconds each time we make a change. :) Sounds very cool! I like doing several steps at once. I think I'll fire up the old CPAN module later today and grab the latest guide distribution. > >Drew, if this all sounds like too much trouble for the first draft and you > >already started in HTML, I'd say just finish that up and we'll distill it > >into POD later. (html2pod?) > > Could be. Although, HTML is a pain in the ass to add onto anyway. It's a > lot easier to see differences between versions of docs in POD than in HTML > where you have all the formatting tags that interfere with reading diffs. No kidding#!@ :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Perrin Harkins wrote: > > Drew, if this all sounds like too much trouble for the first draft and you > already started in HTML, I'd say just finish that up and we'll distill it > into POD later. (html2pod?) I have no problems learning something new. I know basic POD, and it sounds like the tools are available to do things like the feature checklist. And as luck would have it, I've been swamped this week so I have not written a single word. :-( However, I am planning on banging out a quick outline during lunch today, which I will post on my website (hopefully) this afternoon. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: [doc writing] (was Re: Feature sets [was Re: Templating System])
On Fri, 4 Aug 2000, Stas Bekman wrote: > > People are migrating to XML because there are good editors coming onto the > > market (though sadly none for Linux yet, but I'm getting close to > > persuading Arbotext to port Adept to Linux...). The editors hide the > > complexity and you never need to see the source code. But its there if you > > need it (unlike Word, for example). > > Well, this is a whole different story :) Once there will be such an > editor, things will be much better. Well the tools are now pretty nice for Windows. > But you forget about the benefits of the source code editing, which is > diff and tools working with it. Surely enough big editors support their > own diff formats and tools, but they aren't possessed by many people. And > with POD everybody has a text editor :) As with XML :) > > Ugh... I believe SDF has better support for tables, without resorting to > > nastiness like that. I think if you like POD, you'll love SDF, Stas. > > > > http://www.mincom.com/mtr/sdf/ > > Thanks for the link, Matt. I've seen this technology a while ago. The > reason that I didn't use it, is that it's a much bigger superset of syntax > that I need. If all I miss is a tables formatting, I'd rather add this > support than go for a complete format change. I wonder if it would be easy to rip the table support out of SDF and use that, rather than change completely to SDF. I find table support to be POD's only real severe weakness. -- 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
[doc writing] (was Re: Feature sets [was Re: Templating System])
On Fri, 4 Aug 2000, Matt Sergeant wrote: > On Fri, 4 Aug 2000, Stas Bekman wrote: > > > > > > I hope that you write the doc is POD :) > > > > > > > > I suppose I could... I was planning on having a nice checklist of > > > > features/systems that would be a pain to do in a fixed width font. An > > > > HTML table would make my life MUCH easier there. Is there something in > > > > POD that makes tables easier? > > > > > > Write the text in POD, and put the checklist data in with some neutral > > > format. Then we can use a customized pod2html converter on it to generate > > > a pretty table. XML would be a nice way to store the raw data. This > > > might end up being kind of big for an in-line, so we could do something > > > like "=table data_file.xml" and keep it in a separate file. (Or is it > > > better to use "=for html" and put the rest inside that, so that it still > > > passes syntax checks for standard POD?) > > > > I believe XML is a way too heavy for docs writing. Why one will want to > > get a messy source code, when you can get away with a minimalistic POD. > > Just look at the Guide's source code and look at the generated PDF -- > > isn't it great? I love POD. And if you want more than POD provides, it > > takes secs to add the new functionality. > > People are migrating to XML because there are good editors coming onto the > market (though sadly none for Linux yet, but I'm getting close to > persuading Arbotext to port Adept to Linux...). The editors hide the > complexity and you never need to see the source code. But its there if you > need it (unlike Word, for example). Well, this is a whole different story :) Once there will be such an editor, things will be much better. But you forget about the benefits of the source code editing, which is diff and tools working with it. Surely enough big editors support their own diff formats and tools, but they aren't possessed by many people. And with POD everybody has a text editor :) > > As for POD, I've already extended the POD in POD2HTML (which was buggy > > anyway). For example, I've added new directives for embedding images, > > linking to files and more... I don't afraid to extend the POD since I can > > easily convert all my extended pod files back into the standard POD > > format. So if you want a syntax for tables, this should be easy to add, > > like: > > > > =table args > > > > =tr args > > > > =td args > > > > ... > > > > =/td > > > > =/tr > > > > =/table Well, it was just an idea. It can be implemented in any other way... > Ugh... I believe SDF has better support for tables, without resorting to > nastiness like that. I think if you like POD, you'll love SDF, Stas. > > http://www.mincom.com/mtr/sdf/ Thanks for the link, Matt. I've seen this technology a while ago. The reason that I didn't use it, is that it's a much bigger superset of syntax that I need. If all I miss is a tables formatting, I'd rather add this support than go for a complete format change. Other than that, SDF looks really cool, and if you need more features than provided by POD go for it. Especially cool thing, is that it provides tools to convert to and from POD. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Feature sets [was Re: Templating System]
On Fri, 4 Aug 2000, Stas Bekman wrote: > > > > I hope that you write the doc is POD :) > > > > > > I suppose I could... I was planning on having a nice checklist of > > > features/systems that would be a pain to do in a fixed width font. An > > > HTML table would make my life MUCH easier there. Is there something in > > > POD that makes tables easier? > > > > Write the text in POD, and put the checklist data in with some neutral > > format. Then we can use a customized pod2html converter on it to generate > > a pretty table. XML would be a nice way to store the raw data. This > > might end up being kind of big for an in-line, so we could do something > > like "=table data_file.xml" and keep it in a separate file. (Or is it > > better to use "=for html" and put the rest inside that, so that it still > > passes syntax checks for standard POD?) > > I believe XML is a way too heavy for docs writing. Why one will want to > get a messy source code, when you can get away with a minimalistic POD. > Just look at the Guide's source code and look at the generated PDF -- > isn't it great? I love POD. And if you want more than POD provides, it > takes secs to add the new functionality. People are migrating to XML because there are good editors coming onto the market (though sadly none for Linux yet, but I'm getting close to persuading Arbotext to port Adept to Linux...). The editors hide the complexity and you never need to see the source code. But its there if you need it (unlike Word, for example). > As for POD, I've already extended the POD in POD2HTML (which was buggy > anyway). For example, I've added new directives for embedding images, > linking to files and more... I don't afraid to extend the POD since I can > easily convert all my extended pod files back into the standard POD > format. So if you want a syntax for tables, this should be easy to add, > like: > > =table args > > =tr args > > =td args > > ... > > =/td > > =/tr > > =/table Ugh... I believe SDF has better support for tables, without resorting to nastiness like that. I think if you like POD, you'll love SDF, Stas. http://www.mincom.com/mtr/sdf/ -- 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: Feature sets [was Re: Templating System]
Gunther Birznieks ([EMAIL PROTECTED]) said something to this effect: > One book I would highly recommend on CVS is Open Source Development with > CVS by Karl Franz Fogel. I found it to be not only highly informative but > an incredibly fun read as well. Each of the semi-dry CVS chapters is > followed up by a fun anecdotal chapter about open source development > processes and how and why they work (esp focusing if possible on how CVS > helps that process). > > I've also found it to be a better "advanced" reference than any of the CVS > documentation I have. Somehow it just "feels" indexed better. I own no > stock in Coriolis Books by the way. :) Most of this book is available from http://cvsbook.red-bean.com/ (all except chapters 1,3,5, and 7), for those of you who aren't familiar is CVS. The site contains the book in HTML, Info, Texinfo, and Postscript format, and you can get the working copy vis anonymous CVS, also. (darren) -- Tell a man that there are 400 Billion stars and he'll believe you. Tell him that a bench has wet paint and he has to touch it.
Re: Feature sets [was Re: Templating System]
> > > I hope that you write the doc is POD :) > > > > I suppose I could... I was planning on having a nice checklist of > > features/systems that would be a pain to do in a fixed width font. An > > HTML table would make my life MUCH easier there. Is there something in > > POD that makes tables easier? > > Write the text in POD, and put the checklist data in with some neutral > format. Then we can use a customized pod2html converter on it to generate > a pretty table. XML would be a nice way to store the raw data. This > might end up being kind of big for an in-line, so we could do something > like "=table data_file.xml" and keep it in a separate file. (Or is it > better to use "=for html" and put the rest inside that, so that it still > passes syntax checks for standard POD?) I believe XML is a way too heavy for docs writing. Why one will want to get a messy source code, when you can get away with a minimalistic POD. Just look at the Guide's source code and look at the generated PDF -- isn't it great? I love POD. And if you want more than POD provides, it takes secs to add the new functionality. > Stas, do you have code available for the guide generator? That might come > in handy. The guide building code was completely rewritten lately. Now it uses HTML templates (+css) to customize the look and feel, so if you want to roll your own documentation project you don't have to touch the code anymore. The html2ps translator is bundled in distribution, so there is no installation overhead, just grab the package from CPAN: cpan> install mod_perl_guide If there will be enough interest, I'll release the package as a standalone in the future. As for POD, I've already extended the POD in POD2HTML (which was buggy anyway). For example, I've added new directives for embedding images, linking to files and more... I don't afraid to extend the POD since I can easily convert all my extended pod files back into the standard POD format. So if you want a syntax for tables, this should be easy to add, like: =table args =tr args =td args ... =/td =/tr =/table > Drew, if this all sounds like too much trouble for the first draft and you > already started in HTML, I'd say just finish that up and we'll distill it > into POD later. (html2pod?) Not a good idea :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Feature sets [was Re: Templating System]
At 08:03 AM 8/4/00 +0100, Matt Sergeant wrote: >On Thu, 3 Aug 2000, Gunther Birznieks wrote: > > > At 05:10 PM 8/3/00 -0700, Perrin Harkins wrote: > > >On Thu, 3 Aug 2000, Drew Taylor wrote: > > > > Having recently discovered the joy of CVS, I look forward to it. > Awfully > > > > nice to able to roll back to a previous version - although (knock on > > > > wood!) I haven't had to use it yet. > > > > > >I can help if you get stuck. > > > > One book I would highly recommend on CVS is Open Source Development with > > CVS by Karl Franz Fogel. I found it to be not only highly informative but > > an incredibly fun read as well. Each of the semi-dry CVS chapters is > > followed up by a fun anecdotal chapter about open source development > > processes and how and why they work (esp focusing if possible on how CVS > > helps that process). > > > > I've also found it to be a better "advanced" reference than any of the CVS > > documentation I have. Somehow it just "feels" indexed better. I own no > > stock in Coriolis Books by the way. :) > >And its available free online: http://cvsbook.red-bean.com/ Not all chapters are free. Just the CVS related ones (the other ones kind of make the whole subject more pleasurable to read about YMMV). >-- > > >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 __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: Feature sets [was Re: Templating System]
On Thu, 3 Aug 2000, Gunther Birznieks wrote: > At 05:10 PM 8/3/00 -0700, Perrin Harkins wrote: > >On Thu, 3 Aug 2000, Drew Taylor wrote: > > > Having recently discovered the joy of CVS, I look forward to it. Awfully > > > nice to able to roll back to a previous version - although (knock on > > > wood!) I haven't had to use it yet. > > > >I can help if you get stuck. > > One book I would highly recommend on CVS is Open Source Development with > CVS by Karl Franz Fogel. I found it to be not only highly informative but > an incredibly fun read as well. Each of the semi-dry CVS chapters is > followed up by a fun anecdotal chapter about open source development > processes and how and why they work (esp focusing if possible on how CVS > helps that process). > > I've also found it to be a better "advanced" reference than any of the CVS > documentation I have. Somehow it just "feels" indexed better. I own no > stock in Coriolis Books by the way. :) And its available free online: http://cvsbook.red-bean.com/ -- 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: Feature sets [was Re: Templating System]
On 3 Aug 2000, (Randal L. Schwartz) wrote: > > "Drew" == Drew Taylor <[EMAIL PROTECTED]> writes: > > Drew> I suppose I could... I was planning on having a nice checklist of > Drew> features/systems that would be a pain to do in a fixed width font. An > Drew> HTML table would make my life MUCH easier there. Is there something in > Drew> POD that makes tables easier? > > Why don't you write it as XML, then use Template::Toolkit and the DOM > interface to generate what you want. Or XML::Simple with TT... Anyway, I've got a Pod::DocBookXML here somewhere if you want it. That would allow all authoring in POD, with =for docbook sections doing the tables. (of course you could do that with HTML too). -- 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: Feature sets [was Re: Templating System]
At 05:33 PM 8/3/00 -0700, Randal L. Schwartz wrote: > > "Drew" == Drew Taylor <[EMAIL PROTECTED]> writes: > >Drew> I suppose I could... I was planning on having a nice checklist of >Drew> features/systems that would be a pain to do in a fixed width font. An >Drew> HTML table would make my life MUCH easier there. Is there something in >Drew> POD that makes tables easier? > >Why don't you write it as XML, then use Template::Toolkit and the DOM >interface to generate what you want. One problem is deciding off the bat what you want to support in terms of XML tags. Perhaps this could resolved quickly by simply mapping the POD tags to XML from the start as a lowest common denominator format. And then also using an XML Editor that helps you conform to the DOM. I have to say that I find it much easier to write in POD because it's a lowest common denominator format right off the bat. And then generate other things from it (could even generate XML and do a transform on that I guess). From my old fogey perspective, for writing raw docs, I dislike writing XML about as much as I dislike writing direct HTML. Perhaps I dislike it even more because every XML markup is different and I hate having all the XML markups I deal with swim about my small head. I already know POD and POD is a suitable LCD language, so... Another thing that is nice about a POD format from the beginning is kind of the same thing that is nice about coding in Perl. Instant gratification. I know I can see immediately the results of my writing. As opposed to going through a compile cycle because I am already writing in one of the formats I like to read docs in. I know there are XML editors out there though that can be fed a DOM of sorts. And that could probably help that issue. Anyway, I guess for these reasons I''ve been a fan of Stas' guide generator because it's easy for me and I already know POD. Although I imagine it would be an interesting addition to the Guide Generator to make it use XML instead of POD as the basis. And who knows, maybe I am just being old by suggesting that native POD has advantages over XML... and that maybe COBOL could be used to format the tables for the feature comparison. Oops, I realize I hadn't suggested that. Yet. :) Later, Gunther
Re: Feature sets [was Re: Templating System]
At 05:10 PM 8/3/00 -0700, Perrin Harkins wrote: >On Thu, 3 Aug 2000, Drew Taylor wrote: > > Having recently discovered the joy of CVS, I look forward to it. Awfully > > nice to able to roll back to a previous version - although (knock on > > wood!) I haven't had to use it yet. > >I can help if you get stuck. One book I would highly recommend on CVS is Open Source Development with CVS by Karl Franz Fogel. I found it to be not only highly informative but an incredibly fun read as well. Each of the semi-dry CVS chapters is followed up by a fun anecdotal chapter about open source development processes and how and why they work (esp focusing if possible on how CVS helps that process). I've also found it to be a better "advanced" reference than any of the CVS documentation I have. Somehow it just "feels" indexed better. I own no stock in Coriolis Books by the way. :) > > > I hope that you write the doc is POD :) > > > > I suppose I could... I was planning on having a nice checklist of > > features/systems that would be a pain to do in a fixed width font. An > > HTML table would make my life MUCH easier there. Is there something in > > POD that makes tables easier? > >Write the text in POD, and put the checklist data in with some neutral >format. Then we can use a customized pod2html converter on it to generate >a pretty table. XML would be a nice way to store the raw data. This >might end up being kind of big for an in-line, so we could do something >like "=table data_file.xml" and keep it in a separate file. (Or is it >better to use "=for html" and put the rest inside that, so that it still >passes syntax checks for standard POD?) > >Stas, do you have code available for the guide generator? That might come >in handy. I have to second this suggestion. Stas does make the source available to the guide generator. Download the guide from CPAN and poke around the distribution... :) We've been using it to do ALL our extropia documentation for 2 months now (actually we use a modified older version, and am waiting to get some time to upgrade since Stas has done many improvements). Does this format look familiar (albeit a little old)? http://www.extropia.com/docs/webdb/ It's really awesome. I generate standalone HTML for standalone distribution of scripts, HTML docs that integrate into the look and feel of our website, and PDF within seconds each time we make a change. :) >Drew, if this all sounds like too much trouble for the first draft and you >already started in HTML, I'd say just finish that up and we'll distill it >into POD later. (html2pod?) Could be. Although, HTML is a pain in the ass to add onto anyway. It's a lot easier to see differences between versions of docs in POD than in HTML where you have all the formatting tags that interfere with reading diffs. Later, Gunther
Re: Feature sets [was Re: Templating System]
> "Drew" == Drew Taylor <[EMAIL PROTECTED]> writes: Drew> I suppose I could... I was planning on having a nice checklist of Drew> features/systems that would be a pain to do in a fixed width font. An Drew> HTML table would make my life MUCH easier there. Is there something in Drew> POD that makes tables easier? Why don't you write it as XML, then use Template::Toolkit and the DOM interface to generate what you want. /me shows hint of bias :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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: Feature sets [was Re: Templating System]
Perrin Harkins wrote: > On Thu, 3 Aug 2000, Drew Taylor wrote: > > Having recently discovered the joy of CVS, I look forward to it. Awfully > > nice to able to roll back to a previous version - although (knock on > > wood!) I haven't had to use it yet. > > I can help if you get stuck. > > > > I hope that you write the doc is POD :) > > > > I suppose I could... I was planning on having a nice checklist of > > features/systems that would be a pain to do in a fixed width font. An > > HTML table would make my life MUCH easier there. Is there something in > > POD that makes tables easier? > > Write the text in POD, and put the checklist data in with some neutral > format. Then we can use a customized pod2html converter on it to generate > a pretty table. XML would be a nice way to store the raw data. This > might end up being kind of big for an in-line, so we could do something > like "=table data_file.xml" and keep it in a separate file. (Or is it > better to use "=for html" and put the rest inside that, so that it still > passes syntax checks for standard POD?) sounds like we need a good templating system to do this for us. anyone know a good templating system? sorry - couldn't resist. :-)) > > > Stas, do you have code available for the guide generator? That might come > in handy. > > Drew, if this all sounds like too much trouble for the first draft and you > already started in HTML, I'd say just finish that up and we'll distill it > into POD later. (html2pod?) > > - Perrin -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/