modperl-templating_a_balanced_axkit_review_from_matt_seargent_oddly_enough

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



To: modperl@apache.org
From: "Richard L. Goerwitz III" <richard@Goerwitz.com>
Subject: HTML forms and piplining templating systems
Date: Mon, 10 Dec 2001 08:14:31 -0500

I've been using Embperl happily for several years now, and the only
real drawback I've seen to it was (until recently) that it lacked a
mechanism for doing inheritance/cascading.  EmbPerlObject seems to
remedy this deficiency.

I've been hearing lots about AxKit lately.

I'm curious about one thing:  How easy is it to do fill-out forms
with pipelining templating systems like AxKit?  I'd think that in
such cases the stylesheet would have to do so much work that it
would become, in essence, like a CGI script.  In other words, the
neat separation between content and presentation would be lost be-
cause the presentation of the form doesn't have much to do with
its "content" ("content" meaning the textual information on which
it's based).

Anyway, I'm just curious about forms and pipelining templating
systems generally.  Does this really work?  Work well?

===
To: "'richard@Goerwitz.com'" <richard@Goerwitz.com>
From: Matt Sergeant <msergeant@startechgroup.co.uk>
Subject: RE: HTML forms and piplining templating systems
Date: Mon, 10 Dec 2001 14:07:39 -0000

I tend to use PerForm for complex forms:

http://theoryx5.uwinnipeg.ca/CPAN/data/AxKit-XSP-PerForm/PerForm.html

Others write custom taglibs:

http://theoryx5.uwinnipeg.ca/CPAN/data/AxKit/Apache/AxKit/Language/XSP/Tagli
bHelper.html

The general idea is that the output is an abstract representation of a form,
not specifically a HTML form. We then transform that to the desired output
format.

But then if you're happy with EmbPerl, why switch?

===
To: Matt Sergeant <msergeant@startechgroup.co.uk>
From: "Richard L. Goerwitz III" <richard@Goerwitz.com>
Subject: Re: HTML forms and piplining templating systems
Date: Mon, 10 Dec 2001 09:37:36 -0500

Matt Sergeant wrote:

> But then if you're happy with EmbPerl, why switch?

A couple of reasons, really:

  1) well, I actually wouldn't switch per se; people think in
     different ways, and it's often useful to support (and feel
     comfortable with) different development paradigms

  2) EmbPerl is great, but if you're undisciplined it's very
     easy to mix content and presentation

Like a lot of other people, I suspect, I've written my own ad hoc
pipelining templating system several times over.  E.g., when I did
a system in 1997 called the Quran Browser

  http://www.stg.brown.edu/webs/quran_browser/

I created a back end that vended just the text, with very simple
markup.  The HTML is all added by the front end.

While this made maintenance easy in some respects (you can add new
texts, replace old ones, etc. without changing having to do much
work on the front end), I found that pipelining tended to make the
front end (in AxKit terms, the stylesheet) unnecessarily complex
and hard to maintain.  For very simple systems, it's not a big
deal.  But the more complex and interactive the system is, the more
I actually have come to prefer the callback paradigm (like Embperl).
The problem here is that if you're not careful, the callback para-
digm leads to the very sort of mixing of content and presentation
that makes changing either very difficult (e.g., try upgrading an
Embperl system from HTML to XML, or even XHTML).

So actually I'm not looking to move away from Embperl towards AxKit
so much as try to keep my foot on both sides of the line.  The call-
back paradigm is good for some things.  And the pipelining is good
for others.

Is AxKit the best of the pipelining breed, though?  (I personally
am finding XML to be a ghastly, ugly thing; it all started with
namespaces, which are implemented via attributes in a horribly
kludgy way - and now we're finding new schema mechanisms entering
in, plus complex and unintuitive beasts like XSL.  So I wonder just
how slick AxKit can possibly be, given its foundation in these
technologies.)

===
To: "'richard@Goerwitz.com'" <richard@Goerwitz.com>
From: Matt Sergeant <msergeant@startechgroup.co.uk>
Subject: RE: HTML forms and piplining templating systems
Date: Mon, 10 Dec 2001 14:56:03 -0000

> -----Original Message-----
> From: Richard L. Goerwitz III [mailto:richard@Goerwitz.com]
> 
> Is AxKit the best of the pipelining breed, though?  (I personally
> am finding XML to be a ghastly, ugly thing; it all started with
> namespaces, which are implemented via attributes in a horribly
> kludgy way - and now we're finding new schema mechanisms entering
> in, plus complex and unintuitive beasts like XSL.  So I wonder just
> how slick AxKit can possibly be, given its foundation in these
> technologies.)

Well AxKit certainly has its flaws (it's almost to the point where I either
have to do major re-writes, or a complete re-write, or just work really hard
to fix the flaws, as happens with most projects of its kind when you have
used them to do serious work), but I can't agree with you that XML is one of
them. It's just a syntax for describing data after all, so don't think in
terms of the syntax - think in terms of data! That's the biggest problem I
have when people start saying "Well, but XML sucks!".

I wouldn't necessarily say it's best of breed. For a real "best of breed" I
would look towards Cocoon2. But you get what you pay for, so while AxKit
might not be as well designed and thought out as Cocoon2, it's a hell of a
lot easier to get started with, and continue working with, and it still
seems to be faster and more flexible in some ways.

Besides, I'm the wrong person to ask ;-)

===

To: <richard@Goerwitz.com>, "Matt Sergeant"
<msergeant@startechgroup.co.uk>
From: "Gerald Richter" <richter@ecos.de>
Subject: Re: HTML forms and piplining templating systems
Date: Mon, 10 Dec 2001 18:24:14 +0100

>
> > But then if you're happy with EmbPerl, why switch?
>
> A couple of reasons, really:
>
>   1) well, I actually wouldn't switch per se; people think in
>      different ways, and it's often useful to support (and feel
>      comfortable with) different development paradigms
>

Embperl 2.0 (starting with b4) also supports pipelining and XML. This
especialy gives a lot of possibilites to use the best of both worlds
together or standalone.

Of couse such things are new in Embperl and not everything is documentated
very good right now, but I think it's worth a look. In 2.0b6 I plan to
finish the Perl API so you can easly write your own Embperl's
provider/processor/filter in Perl.

===

To: <richard@Goerwitz.com>
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: HTML forms and piplining templating systems
Date: Mon, 10 Dec 2001 12:59:01 -0500

> I'm curious about one thing:  How easy is it to do fill-out forms
> with pipelining templating systems like AxKit?  I'd think that in
> such cases the stylesheet would have to do so much work that it
> would become, in essence, like a CGI script.

Can you explain what work you're talking about here?  In general, form
processing works great with a pipeline style.  If you're displaying an empty
form, there is nothing to do before running the template.  If you're
displaying a form with data filled in, you collect the data in the
processing part of your code and then pass it to the template.  What is it
that's giving you trouble?

As for which system to use, AxKit certainly has the broadest support for
XML.  If you're not enjoying working with XML you could try a system like
Template Toolkit or HTML::Template that allow you to pass your data as
normal perl data structures.  Of course you can do that with Embperl too if
you can be disciplined about keeping separate components for application
logic vs. display.

===



the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu