[OT] bOP (was: Re: [ANNOUNCE] Petal 0.1)
and on top of that I want people to be able to edit templates easily in dreamweaver, frontpage, etc and send templates thru HTML tidy to be able to always output valid XHTML. If you are an OO-advocate, you would hide the presentation format in objects, e.g. Table, String, and Link. This ensures the output is valid through the (re)use of independently tested objects. Objects also provide a mechanism for overriding behavior. Well, there is an interesting example on this page: input type=text name=username size=25 And the question which is raised is: How does the graphic designer know that the display size of a username is 25?. Here is what you'd write with Petal: input type=text name=username size=25 petal:attributes=size user.login_preferred_length; maxsize user.login_maxlength / Then no matter what, the display size of a username would be OK. And the graphic designer could still move this tag around or change the 'size' attribute. Better, you could do the following: span style=border-style:solid; border-color: blue petal:attributes=style default_style input type=text name=username size=25 petal:attributes=size user.login_preferred_length; maxsize user.login_maxlength / /span And then the dynamic component would have a blue border when it is edited (so that the graphic designers knows that this bit of the page is subject to change) but which would be set to default_style when the page is processed... I find it really really horrible to mix HTML and Perl code. So let's say that some different kind of HTML is needed, it means that I have to create a new object, subclass an existing widget, etc... With a templating system, this can all be done by someone who has knowledge of HTML. Better, with Petal, all the presentational stuff can be done with a WYSIWYG editor a la frontpage. No need to go and tweak some strange declarative language. Actually I don't think these two things are incompatible. After all you could have 'independently tested objects' which would themselves use templates... Then you could organize your templates into two kinds: 'system / admin' templates which are related to the 'web application', you the programmer, would be in charge of maintaining these templates. 'presentational' templates which would just delegate method calls to your template driven widget library. You'd give these templates for your graphic designers to play with... And here is the HTML-less source: http://petshop.bivio.biz/src?s=View.items Well, sorry, I find it really, really horrible :-) For example: image = 'add_to_cart', field = 'add_to_cart', alt = 'Add Item to Your Shopping Cart', or: cellpadding = 2, cellspacing = 2, You are definitely tying your objects with HTML. 'cellpadding' or 'alt' are _definitely_ HTML-specific, and I don't see why they should be polluting your business logic. I see that all the code which you output is html 4.0 transitional. What if you want to make everything XHTML 1.1 strict? Or if you want to get rid of all the 'font face' tags? You want to rewrite all your widget library? Wouldn't it be easier to have templates which you can send through some kind of HTML fixed / validator such as tidy? Apologies to those who are tired of the *ML vs. Perl debate. Well, as long as we don't start trolling and that we agree to disagree we'll be fine :-) Best regards, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [ANNOUNCE] Petal 0.1
I'm curious though, why you've chosen to implement it as a handler for XML::Parser rather than as a SAX Handler (or even better, a Filter)? What SAX buys (among other things) is the ability for folks to invisibly use whatever XML parser is installed, including a pure Perl implementation. Doing Petal as a SAX Filter would mean that it would be totally easy to add it to the mix in things like AxKit and custom SAX pipeline publishing systems. So, doing complex, multi-stage transformations like My::NonXML::SAXGenerator - Petal - SomeXSLT - SomeOtherXSLT come for free. Interesting stuff... And I think it would be quite easy to implement! At the moment Petal features two XML event generators: Petal::Parser::XMLWrapper (based on XML::Parser) Petal::Parser::HTMLWrapper (based on HTML::TreeBuilder) I suppose I could write a Petal::Parser::SAXWrapper... it would be quite trivial to generate the XML::Parser events from that :-) My only problem deals with template caching. Currently Petal does the following: * Generate events to build a 'canonical' template file * Convert that template file to Perl code ** Cache the Perl code onto disk * Compiles the Perl code as a subroutine ** Caches the subroutine in memory Cache is kept fresh using the template file mtime() information. If I had a SAX event parser, then maybe caching could be a bit troublesome? Maybe what I really need would be to write something a bit more generic, i.e. my $template = new Petal ( event_generator = $event_generator, cache_key = $cache_key, cache_expires = \coderef ); I do not have much experience with SAX and pipelines or things, but if you feel like looking at the code and make sensible architectural suggestions to make Petal as generic and modular as possible then I'll be quite happy to implement them :-) Anyway, just random thoughts, really. Petal seems nice and it seems a shame to lock it in the XML::Parser-based-one-off jail. Well, it's not *really*. Take a look at Petal::Parser::HTMLWrapper, you'll see it's pretty straightforward :-) Oh by the way, Petal 0.2 is out, it fixes a stupid critical bug and a couple of documentation bugs... http://search.cpan.org/doc/JHIVER/Petal.0.2/lib/Petal.pm Best regards, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [ANNOUNCE] Petal 0.1
On Wed, 17 Jul 2002, Jean-Michel Hiver wrote: My only problem deals with template caching. Currently Petal does the following: * Generate events to build a 'canonical' template file * Convert that template file to Perl code ** Cache the Perl code onto disk * Compiles the Perl code as a subroutine ** Caches the subroutine in memory Cache is kept fresh using the template file mtime() information. If I had a SAX event parser, then maybe caching could be a bit troublesome? If you could skip the whole perl code part you could use XML::Filter::Cache (a SAX caching filter) as a cache rather than worrying about a built in one. Sorry for getting off topic for this list though. Just trying to pass around the SAX kool aid ;-) -- !-- Matt -- :-Get a smart net/:-
Re: [ANNOUNCE] Petal 0.1
Jean-Michel Hiver writes: My only problem deals with template caching. Currently Petal does the following: * Generate events to build a 'canonical' template file * Convert that template file to Perl code ** Cache the Perl code onto disk * Compiles the Perl code as a subroutine ** Caches the subroutine in memory I wonder how much code you would save if you wrote the templates in Perl and let the Perl interpreter do the above. Sorry, I know this doesn't help you answer your question, but by eliminating XML from the design, the debate about SAX vs XML::Parser would be irrelevant. Your code would run faster, and you would need fewer 3rd party APIs. Rob
Re: [ANNOUNCE] Petal 0.1
I wonder how much code you would save if you wrote the templates in Perl and let the Perl interpreter do the above. I recommend that you read this Page: http://www.perl.com/pub/a/2001/08/21/templating.html?page=2 I'm an OO-advocate, I believe in proper separation of logic, content and presentation and on top of that I want people to be able to edit templates easily in dreamweaver, frontpage, etc and send templates thru HTML tidy to be able to always output valid XHTML. Petal lets me do that. If that's not of any use to you, fine. The world is full of excellent 'inline style' modules such as HTML::Mason, HTML::Embperl and other Apache::ASP. After all, TIMTOWDI :-) Regards, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [ANNOUNCE] Petal 0.1
Jean-Michel Hiver writes: I wonder how much code you would save if you wrote the templates in Perl and let the Perl interpreter do the above. I recommend that you read this Page: http://www.perl.com/pub/a/2001/08/21/templating.html?page=2 Please read the Application Servers section of: http://www.bivio.biz/hm/why-bOP I'm an OO-advocate, I believe in proper separation of logic, content and presentation Moi aussi. What does this have to do with using Perl for business logic and presentation logic? and on top of that I want people to be able to edit templates easily in dreamweaver, frontpage, etc and send templates thru HTML tidy to be able to always output valid XHTML. If you are an OO-advocate, you would hide the presentation format in objects, e.g. Table, String, and Link. This ensures the output is valid through the (re)use of independently tested objects. Objects also provide a mechanism for overriding behavior. Petal lets me do that. If that's not of any use to you, fine. The world is full of excellent 'inline style' modules such as HTML::Mason, HTML::Embperl and other Apache::ASP. These all work on the assumption that the template is written in HTML. If you start with OO Perl, you do not inline anything, not even the HTML. Here is an example page: http://petshop.bivio.biz/items?p=RP-LI-02 And here is the HTML-less source: http://petshop.bivio.biz/src?s=View.items Apologies to those who are tired of the *ML vs. Perl debate. Rob
Re: [ANNOUNCE] Petal 0.1
On Wed, 17 Jul 2002, Rob Nagler wrote: Petal lets me do that. If that's not of any use to you, fine. The world is full of excellent 'inline style' modules such as HTML::Mason, HTML::Embperl and other Apache::ASP. These all work on the assumption that the template is written in HTML. Actually, neither Mason nor Embperl are HTML-specific these days. Mason never really was, and Embperl has become much more generic with version 2, which is in fact now simply called Embperl. Mason will probably changes its name eventually as well. -dave /*== www.urth.org we await the New Sun ==*/
Re: [ANNOUNCE] Petal 0.1
On Wednesday 17 July 2002 22:06, Rob Nagler wrote: Apologies to those who are tired of the *ML vs. Perl debate. We might get tired if the vs in there made any sense. -- Robin Berjon [EMAIL PROTECTED] -- for hire: http://robin.berjon.com/ Windows may be pretty. And easy. But it has no depth or soul. It's like the one-night stand of operating systems. You feel cheap after using it. -- Steph, in User Friendly
Re: [ANNOUNCE] Petal 0.1
Rob Nagler wrote: Apologies to those who are tired of the *ML vs. Perl debate. I think you're confusing the issue. You're not talking about in-line Perl vs. templating languages, but rather templating vs. a whole different concept. Jean-Michel clearly wants to use HTML-based templates, and wrote his module specifically for that purpose. When most people talk about templates for web pages, this is what they have in mind: HTML (or XML or PDF or whatever) bristled with processing instructions in Perl or a templating language. It's an easy transition for people who already know HTML, and provides what most people want from a templating solution. What Bivio uses could reasonably be called a template, but it's a completely different animal from the sort of fill-in-the-blank templates that most people mean, and maybe deserves a different name. It's more like a declarative program, or a configuration file, or CGI.pm widgets. It is an alternative to traditional templating, but suggesting that this will fix issues with XML parsing is kind of like saying you wouldn't need that winter coat if you lived in Hawaii -- true, but not very helpful to someone who lives in Montreal and likes it. - Perrin
Re: [ANNOUNCE] Petal 0.1
Dave Rolsky [EMAIL PROTECTED] wrote: On Wed, 17 Jul 2002, Rob Nagler wrote: Petal lets me do that. If that's not of any use to you, fine. The world is full of excellent 'inline style' modules such as HTML::Mason, HTML::Embperl and other Apache::ASP. These all work on the assumption that the template is written in HTML. Actually, neither Mason nor Embperl are HTML-specific these days. Mason never really was, and Embperl has become much more generic with version 2, which is in fact now simply called Embperl. Mason will probably changes its name eventually as well. -nod- (As an example of a non-HTML [and potentially twisted] app:) I'm working on our next-generation administrative web application (handles some system account management and other similar things for the University). I decided early on to use the MVC paradigm because the programmers (me) are better at programming the MC part than writing the content for the V part. So, looking at the modules available on CPAN (I'm trying to make maximal use of CPAN), I decided to use the following: Mason (Controller): provides easy management of form values from the client, clean division between sections (init, once, shared, etc.), and nice inheritance. For now, Mason is called from AxKit. TT2 (View): makes it easy for non-programmers to edit XML and embed occasional references to data without having to understand the underlying object model -- views are ultimately called from Mason. I use Data::FormValidator to decide which view to use. AxKit (View): translates the XML to the output device the customer is using. Also can support themes. Allows us to internally structure content in a logical manner that may ultimately aid in building a search engine (for a document repository, for example). Also provides the site a the consistent look feel. Perl (Model): actual database manipulation is done through Perl modules I think I am using each item in its strongest area. There is no HTML until AxKit sends it to the client. It's also easier to throw a few more CPUs or sticks of RAM at the solution than half-a-dozen programmers that can't write anything customer-friendly or technical writers that can't deal with code. (Of course, one of my other mantras is: Always write for a webfarm.) -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: [ANNOUNCE] Petal 0.1
At 10:41 AM 07/16/2002 +0100, Jean-Michel Hiver wrote: Hi list, I am glad to announce the first release of Petal, the Perl Template Attribute Language module. You will find a rather copious documentation here: http://search.cpan.org/doc/JHIVER/Petal-0.1/lib/Petal.pm It should be pretty stable, however the more people have a play with it the more likely I am to be aware of potential bugs :-) Tell me what you think! Interesting work, cheers. I'm curious though, why you've chosen to implement it as a handler for XML::Parser rather than as a SAX Handler (or even better, a Filter)? What SAX buys (among other things) is the ability for folks to invisibly use whatever XML parser is installed, including a pure Perl implementation. Doing Petal as a SAX Filter would mean that it would be totally easy to add it to the mix in things like AxKit and custom SAX pipeline publishing systems. So, doing complex, multi-stage transformations like My::NonXML::SAXGenerator - Petal - SomeXSLT - SomeOtherXSLT come for free. Anyway, just random thoughts, really. Petal seems nice and it seems a shame to lock it in the XML::Parser-based-one-off jail. -kip Kip Hampton Perl and XML: http://xml.com/pub/q/perlxml AxKit: http://axkit.org/ Join Us In San Diego! http://conferences.oreillynet.com/os2002/ http://conferences.oreillynet.com/cs/os2002/view/e_sess/2533
