You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Greger <bo...@gregerhaga.net> on 2006/09/13 12:03:55 UTC
design patters with mod_perl
Is there anything in particular that one should take into account regarding
modperl and design patterns vs trad CGI-scripting?
As for now, I return XML from the package methods, and use XSLT for the
transformation to XHTML. This works very well, seems flexible, but are there
better ways?
I guess it all depends on what one is doing, naturally. In this case it is an
application using the mysql database.
Thank's for any input.
Greger
--
QxRSSReader v1.2.6a released (30-06-2006)
PortScanner v1.2.2 ( 09-08-2006 )
http://www.gregerhaga.net/
There are no stupid questions, but there are stupid answers.
Re: design patters with mod_perl
Posted by Tom Schindl <li...@bestsolution.at>.
You might have a look at the following projects:
- AxKit1 - http://search.cpan.org/~msergeant/AxKit-1.6.2/
- AxKit2 - http://search.cpan.org/~msergeant/AxKit2-1.1/
- Apache2::TomKit - http://search.cpan.org/~tomson/Apache2-TomKit-0.01_6/
Tom
Greger schrieb:
> Is there anything in particular that one should take into account regarding
> modperl and design patterns vs trad CGI-scripting?
>
> As for now, I return XML from the package methods, and use XSLT for the
> transformation to XHTML. This works very well, seems flexible, but are there
> better ways?
>
> I guess it all depends on what one is doing, naturally. In this case it is an
> application using the mysql database.
>
> Thank's for any input.
> Greger
> --
> QxRSSReader v1.2.6a released (30-06-2006)
> PortScanner v1.2.2 ( 09-08-2006 )
> http://www.gregerhaga.net/
> There are no stupid questions, but there are stupid answers.
Re: design patters with mod_perl
Posted by John ORourke <jo...@o-rourke.org>.
Greger,
Greger wrote:
>Is there anything in particular that one should take into account regarding
>modperl and design patterns vs trad CGI-scripting?
>
>As for now, I return XML from the package methods, and use XSLT for the
>transformation to XHTML. This works very well, seems flexible, but are there
>better ways?
>
>
The only thing I'd say there is that while it's flexible, you're doing a
lot of processing that you might not need to - why not get the package
methods to return a Perl structure (eg. a ref to a hash of hashes/lists
etc), and if you want to XML-ify it, make a wrapper class that extends
your base class by converting the return values into XML.
That way you can re-use the original package in code without unnecessary
XML encoding/decoding.
Also check out the wiki http://www.perldesignpatterns.com/ - I wish I'd
known about design patterns sooner, I'm trying to tidy up a god object
now :(
cheers
John
Re: design patters with mod_perl
Posted by Matt Sergeant <ma...@sergeant.org>.
Frank Wiles wrote:
> What I typically recommend to people is that they use a template
> engine like Template-Toolkit.org. You simply pass it a Perl data
> structure and then you have all of the same transformation
> possibilities as XSLT ( at least as I understand it ). And if you
> ever need the data as XML, you simply create a template for
> that ( or pass a special option to your handlers to return XML,
> etc. ).
FWIW TT doesn't quite have the same transformation possibilities as XSLT
(and on the flip side, XSLT doesn't quite have the same data input
possibilities as TT). There's quite a big gap between the two in terms
of those concepts.
I prefer the XSLT way - there's WAY too much code creeps into TT
stylesheets for my liking (it may be the TT syntax, but it's still
code), but mileage definitely varies on the opinions there.
Personally I prefer TAL (AxKit2 supports TAL for XML) for the simple
stuff, and XSLT for the more complex stuff.
Matt.
Re: design patters with mod_perl
Posted by Greger <bo...@gregerhaga.net>.
On Wed, 13 Sep 2006 13:50:27 -0400, Jonathan Vanasco wrote
> On Sep 13, 2006, at 9:28 AM, Frank Wiles wrote:
>
> > What I typically recommend to people is that they use a template
> > engine like Template-Toolkit.org. You simply pass it a Perl data
> > structure and then you have all of the same transformation
> > possibilities as XSLT ( at least as I understand it ). And if you
> > ever need the data as XML, you simply create a template for
> > that ( or pass a special option to your handlers to return XML,
> > etc. ).
>
> I agree with everything said so far
> Perl Data Structures
> Templating Engines
> only toss into XML if you really want to. otherwise why bother
> with 2x the work?
>
> I go a step further...
>
> All of my packages return Perl data structures
> The structures are then tossed into an *abstract* template class
> That abstract class wraps several templating engines , and will
> output to any of them on the fly. This way i can use Petal and
> HTML:: templates with the same app. I just pass a different render
> flag or set a variable/constant.
> If you did that, you could just wrap something that will parse the
> perl structure into XML (or write a template to do it in your
> langauge of choice )
>
> If you're wondering why I'm wrapping in an abstract class, here's
> the top 5 reasons It makes me less 'locked into' a templating
> engine I can trivially switch engines on some pages where there are
> performance concerns ( Petal was killing me on a specific page
> render... but HTML::Template redid it in a fraction of time ) It's
> less code to change when I need to switch templating engines It's
> less code to change when I want to switch templating engines I've
> already switched templating engines before, it wasn't fun.
>
> All of the 'web frameworks' do it to offer users better choice. I
> do it to keep my options open.
Yes, great, many thank's for all your advice and opinions.
I have some experience with templates, but not much, but understand the basics
with them and their use.
However, there is one thing that concerns me:unit testing the web application
along with the framework. I understand that this is slightly off topic now,
but still an important thing in the context.
I am completely impossible with remembering things, I need to test and verify
each small step/progress I do in development. Therefore I need a
framework/system to work with that allows also for unit testing, this so that
I can test the output of methods before they reach the client/consumer.
I have an idea that if I release this app, I'd like to deliver also the
testsuite along with the system, so that I can tell the prospective client
that "here's the suite, lets run and verify that all is good.". And in case of
problem, I can just ask them to run it, and return the results, to find the
source of eventual problems. Of course this can be done by verifying
datastructures like lists and hashes, naturally, but I sort of fancy the XML
output for this reason, as I could use XPath to do check the methods. ( Now, I
don't really know if these thoughts are sane*S*S*S*S*. ).
Yes right, okey so thank's again. I am happy with your help, but of course if
you have thoughts on this you are most welcome to reply.
Best
Greger
--
QxRSSReader v1.2.6a released (30-06-2006)
PortScanner v1.2.2 ( 09-08-2006 )
http://www.gregerhaga.net/
There are no stupid questions, but there are stupid answers.
Re: design patters with mod_perl
Posted by Jonathan Vanasco <mo...@2xlp.com>.
On Sep 13, 2006, at 9:28 AM, Frank Wiles wrote:
> What I typically recommend to people is that they use a template
> engine like Template-Toolkit.org. You simply pass it a Perl data
> structure and then you have all of the same transformation
> possibilities as XSLT ( at least as I understand it ). And if you
> ever need the data as XML, you simply create a template for
> that ( or pass a special option to your handlers to return XML,
> etc. ).
I agree with everything said so far
Perl Data Structures
Templating Engines
only toss into XML if you really want to. otherwise why bother with
2x the work?
I go a step further...
All of my packages return Perl data structures
The structures are then tossed into an *abstract* template class
That abstract class wraps several templating engines , and will
output to any of them on the fly. This way i can use Petal and
HTML:: templates with the same app. I just pass a different render
flag or set a variable/constant.
If you did that, you could just wrap something that will parse the
perl structure into XML (or write a template to do it in your
langauge of choice )
If you're wondering why I'm wrapping in an abstract class, here's the
top 5 reasons
It makes me less 'locked into' a templating engine
I can trivially switch engines on some pages where there are
performance concerns ( Petal was killing me on a specific page
render... but HTML::Template redid it in a fraction of time )
It's less code to change when I need to switch templating engines
It's less code to change when I want to switch templating engines
I've already switched templating engines before, it wasn't fun.
All of the 'web frameworks' do it to offer users better choice. I do
it to keep my options open.
Re: design patters with mod_perl
Posted by Michael Greenish <gr...@yahoo.com>.
I definitely recommend using a template engine and
using an Model-View-Controller (MVC) framework; the
template engine helps with the view part. I was first
introduced to it on the tutorials under documentation
on perl.apache.org. It took me a little while to
figure out how to create & instantiate objects in
perl, but once I figured that out, it has been smooth
sailing since. I have since learned to apply the
concepts to my php web programming at work.
greanie
--- Frank Wiles <fr...@wiles.org> wrote:
> On Wed, 13 Sep 2006 13:03:55 +0300
> "Greger" <bo...@gregerhaga.net> wrote:
>
> > Is there anything in particular that one should
> take into account
> > regarding modperl and design patterns vs trad
> CGI-scripting?
> >
> > As for now, I return XML from the package methods,
> and use XSLT for
> > the transformation to XHTML. This works very well,
> seems flexible,
> > but are there better ways?
> >
> > I guess it all depends on what one is doing,
> naturally. In this case
> > it is an application using the mysql database.
>
> There are a bunch of people who do this, from Perl
> CGIs, mod_perl,
> and even with other languages/frameworks/etc.
>
> It's a perfectly reasonable way of doing things,
> but does cause you to
> do a bunch of extra processing. Putting your data
> into XML, and then
> transforming it into XHTML with XSLT.
>
> What I typically recommend to people is that they
> use a template
> engine like Template-Toolkit.org. You simply pass
> it a Perl data
> structure and then you have all of the same
> transformation
> possibilities as XSLT ( at least as I understand
> it ). And if you
> ever need the data as XML, you simply create a
> template for
> that ( or pass a special option to your handlers
> to return XML,
> etc. ).
>
> There are tons of different ways to do it. What I
> would look for is
> to optimize for the "general case" of "I need to
> deliver XHTML" and
> worry about "I might need this as XML at a later
> date" for that later
> date. :)
>
> ---------------------------------
> Frank Wiles <fr...@wiles.org>
> http://www.wiles.org
> ---------------------------------
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: design patters with mod_perl
Posted by Frank Wiles <fr...@wiles.org>.
On Wed, 13 Sep 2006 13:03:55 +0300
"Greger" <bo...@gregerhaga.net> wrote:
> Is there anything in particular that one should take into account
> regarding modperl and design patterns vs trad CGI-scripting?
>
> As for now, I return XML from the package methods, and use XSLT for
> the transformation to XHTML. This works very well, seems flexible,
> but are there better ways?
>
> I guess it all depends on what one is doing, naturally. In this case
> it is an application using the mysql database.
There are a bunch of people who do this, from Perl CGIs, mod_perl,
and even with other languages/frameworks/etc.
It's a perfectly reasonable way of doing things, but does cause you to
do a bunch of extra processing. Putting your data into XML, and then
transforming it into XHTML with XSLT.
What I typically recommend to people is that they use a template
engine like Template-Toolkit.org. You simply pass it a Perl data
structure and then you have all of the same transformation
possibilities as XSLT ( at least as I understand it ). And if you
ever need the data as XML, you simply create a template for
that ( or pass a special option to your handlers to return XML,
etc. ).
There are tons of different ways to do it. What I would look for is
to optimize for the "general case" of "I need to deliver XHTML" and
worry about "I might need this as XML at a later date" for that later
date. :)
---------------------------------
Frank Wiles <fr...@wiles.org>
http://www.wiles.org
---------------------------------