You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Jesse Erlbaum <je...@erlbaum.net> on 2006/08/16 01:48:26 UTC
HTML::Mason?
Hi All --
Question for the group, at the very distinct risk of starting a holy
war:
What is the general opinion of HTML::Mason?
It seems to be the framework of choice, nowadays, for Perl-based server
page systems (i.e., PHP, JSP, ASP -- any system which puts code in
pages). By the look of it, Mason seems like it has more life than
EmbPerl. Is that correct? Are there any other leading Perl-based *SP
systems I should consider?
(Those who know me probably are concerned I've lost my mind.
Rest-assured, I'm not about to abandon CGI-App/HTML-Tmpl in favor of any
*SP system. This is for a particular project need which is best served
by a server-page architecture.)
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
jesse@erlbaum.net
Phone: 212-684-6161
Fax: 212-684-6226
RE: HTML::Mason?
Posted by Todd Finney <tf...@boygenius.com>.
At 08:44 PM 8/15/2006 -0400, Jesse Erlbaum wrote:
>This is a different situation. I'm not looking for a templating system.
>I'm looking for a system which embeds Perl code in HTML -- a server page
>system.
I've done a lot of work using ePerl, going back several years now. It
doesn't seem to be very popular any more, but I've never had a problem with it.
For a while there, you used to need to patch it to get it to work with
recent perl versions. I don't know if that's still the case. If it is,
check out the debian package page, iirc that's where I picked up the patch
last time. If you still can't find it, drop me a note - I still have the
patches sitting around.
Re: HTML::Mason?
Posted by Jonathan Vanasco <mo...@2xlp.com>.
I feel that Mason is too much tied into the Mason approach. I didn't
think it was as extensible or easy to override as some other options.
I'm running my own MVC framework, but if Catalyst were stable when I
started work, I would have chosen it.
Personally, I only use TAL for view components. Petal compiles it
into fast enough Perl, and Template::TAL works if you don't want
caching. I've run into a few bottlenecks in code, and have been able
to keep the same templates and just proxy the URL to a python daemon
or a quick PHP page ( you're thinking php- he must be crazy. but
yes, php. when you're dealing with data on a certain URL thats
unpredictable and can bump up your mod_perl server by 20mb for a
single request to process, you can proxy only that url to a single
fcgi php handler on lighttpd that takes up 3mb of memory when
dormant and spikes to 20 then releases ASAP unlike mod_perl when
needed ) Little stupid stuff like that makes TAL my choice for views
in any language.
If you're looking at putting raw-perl into a page... i think embperl
would probably perform better than Mason, as it looks to have less
magic going on than mason (ie, embperl is more of perl in html, and
mason is more mason code in html )
You can also look at danga's Perlbal. its supposedly fast as hell,
but like all their stuff: undocumented
-- i just saw the next message you wrote. I'd probably strongly
suggest having people write for you in TAL. serve it via modperl or
serve if on ( lighttpd + fcgi + php + eaccelerator ( sounds like a
lot of overhead, but its a fraction of the apache resources and
outperforms apache by 20%))
Re: HTML::Mason?
Posted by Torsten Foertsch <to...@gmx.net>.
On Wednesday 16 August 2006 02:44, Jesse Erlbaum wrote:
> think "better
> server-side includes"
Are you aware of Apache::IncludeHook?
Torsten
RE: HTML::Mason?
Posted by Jesse Erlbaum <je...@erlbaum.net>.
Hi Joel --
> It's a big and fairly powerful templates-on-steroids system. I have
> ideological objections to the mixing of code and HTML
You'll get no argument from me in the separation of code from HTML
department! I've not been active on the mod_perl list in the last year,
but do a search in the archive -- I'm pretty rabid about it.
This is a different situation. I'm not looking for a templating system.
I'm looking for a system which embeds Perl code in HTML -- a server page
system. If you want to think about it as I do, think "better
server-side includes". I have another automatic system which is going
to write out pages containing this code from templates, so there is no
human who is going to ever edit these pages.
> Er. Are you sure? Most people who want to get stuff done use Catalyst
> for the framework side, and TT for the View component.
> Recently, anyway.
I use CGI::Application and HTML::Template, but I'm biased. ;-)
The need in this case is not for serious applications. This is "better
SSI" for predominantly static web sites.
> Again, not to be awfully fanboyish, but I would hesitate to
> use H::T in
> a new site. Sure, it's fast, but so is TT once you take the
> compilation
> hit. CGI::Application is fast, too, but you end up writing a lot more
> code than you do with a framework like Catalyst.
We're going to disagree on these points, but that's grist for another
mill.
> what is the intended platform for
> your app? Does it have to run as a CGI, rather than via mod_perl or
> FCGI?
This would be a mod_perl server.
The reason I'm asking is because I'm looking for a "better SSI", and I
was actually leaning towards PHP -- mostly because PHP is popular I have
ample access to PHP coders (while all my Perl coders are up to their
eyeballs with work). When I said that in the office, one of my
programmers clarified how much he hated PHP, so I thought I'd take a
second look at Perl *SP systems. Plus, why not leverage our software
infrastructure?
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
jesse@erlbaum.net
Phone: 212-684-6161
Fax: 212-684-6226
Re: HTML::Mason?
Posted by Joel Bernstein <jo...@fysh.org>.
On Tue, Aug 15, 2006 at 07:48:26PM -0400, Jesse Erlbaum wrote:
> Hi All --
>
> Question for the group, at the very distinct risk of starting a holy
> war:
>
> What is the general opinion of HTML::Mason?
It's a big and fairly powerful templates-on-steroids system. I have
ideological objections to the mixing of code and HTML, but apart from
that it's OK. I'd much rather be using Template Toolkit, though. And I'm
much more confident that I could teach TT's minilanguage to a web
designer than Mason.
> It seems to be the framework of choice, nowadays, for Perl-based server
> page systems (i.e., PHP, JSP, ASP -- any system which puts code in
> pages). By the look of it, Mason seems like it has more life than
> EmbPerl. Is that correct? Are there any other leading Perl-based *SP
> systems I should consider?
Er. Are you sure? Most people who want to get stuff done use Catalyst
for the framework side, and TT for the View component. Recently, anyway.
Of course, reading back, you said you want something that embeds code in
pages. I'd question the logic and taste of this, but clearly lots of
people like doing it. I guess as long as you stick to embedding purely
presentation layer logic in the page it's not fundamentally horrible,
but I still don't like it.
I don't think I would start a new project using Mason without thinking a
great deal about why it was a better approach. It seems to encourage
sloppiness by allowing much more logic to exist in the View than I'm
really happy about. Probably requires greater discipline on the part of
developers to not do naughty things.
> (Those who know me probably are concerned I've lost my mind.
> Rest-assured, I'm not about to abandon CGI-App/HTML-Tmpl in favor of any
> *SP system. This is for a particular project need which is best served
> by a server-page architecture.)
Again, not to be awfully fanboyish, but I would hesitate to use H::T in
a new site. Sure, it's fast, but so is TT once you take the compilation
hit. CGI::Application is fast, too, but you end up writing a lot more
code than you do with a framework like Catalyst.
In summary, I'd go for TT and Catalyst, for most applications. Of
course, there will be exceptions -- what is the intended platform for
your app? Does it have to run as a CGI, rather than via mod_perl or
FCGI?
/joel
Re: HTML::Mason?
Posted by Leo Lapworth <le...@cuckoo.org>.
On 16 Aug 2006, at 15:23, Jesse Erlbaum wrote
> (Imagine a list of the users currently logged into the site
One could quite easily have this written out into a JSON file and read
in/displayed with JavaScript/AJAX (though the JS can be a pain to
start).
> or a
> database query on the 5 products most relevant to the current page,
> for
> example.)
How often does this need to be updated? - can this not be part of the
CRM? Have you considered getting the CRM to write out TT code, which
you then parse with ttree (comes with Template Toolkit for offline
processing
of templates) and generating a set of static pages off-line.
There's also Apache::Template which you would want to look at.
As you might guess I'm a big fan of doing as much off-line as possible.
> For any serious application dev, we'd probably reach for an MVC
> framework... CGI::Application/HTML::Template, for example.
Yea, I use Catalyst for small to medium size proejcts/admin systems,
then separate the front end code for larger projects (still using TT).
The other thing to consider is you can always use apache SSI:
<!-- #include="/cgi-bin/get_content.pl?section=foo" -->
and point to a backend CGI (cgi/mod_perl/php/foo) script to
return the relevant content.
Not sure if this is helping or making you more confused, but there
you go :)
Bottom line, I would personally suggest TT over any other templating
system, how you tie that in with your system is a matter of personal
taste/specific requirements and environment.
Leo
Re: HTML::Mason?
Posted by Mike Whitaker <mi...@altrion.org>.
> One way that I've done this kind of thing in the past is to really use
> SSI and call a mod_perl handler or Registry script with it. In other
> words, you write a "list users logged in" thing in CGI::Application as
> usual and then call it like this from a page:
>
> <!--#include virtual="/perl/users?rm=list&max=5" -->
>
> That just makes an Apache subrequest and is very efficient.
>
> If what you want is a bunch of little "portlet" widgets, this can be a
> good way to do it.
Dire warning from bitter experience. If your little portlet widget
does something slow, your whole page will be suitably slowed.
(We used to insert banner ads, using a less-than-optimal ad selection
engine, this way. For this., IFRAMEs are the way forward - or for
that matter client-side JS).
RE: HTML::Mason?
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2006-08-16 at 10:23 -0400, Jesse Erlbaum wrote:
> This is for primarily static web sites which are managed by a CMS. The
> CMS publishes out pages which would contain HTML + various bits of code
> to generate possibly navigation and semi-interactive bits of the page.
> (Imagine a list of the users currently logged into the site or a
> database query on the 5 products most relevant to the current page, for
> example.)
One way that I've done this kind of thing in the past is to really use
SSI and call a mod_perl handler or Registry script with it. In other
words, you write a "list users logged in" thing in CGI::Application as
usual and then call it like this from a page:
<!--#include virtual="/perl/users?rm=list&max=5" -->
That just makes an Apache subrequest and is very efficient.
If what you want is a bunch of little "portlet" widgets, this can be a
good way to do it.
- Perrin
RE: HTML::Mason?
Posted by Jesse Erlbaum <je...@erlbaum.net>.
> I think understanding what you are actually going to do in the SSI
> would help
> somewhat - is this dynamic content based on per user - or just
> navigation on
> the website depending on the section you are in?
This is for primarily static web sites which are managed by a CMS. The
CMS publishes out pages which would contain HTML + various bits of code
to generate possibly navigation and semi-interactive bits of the page.
(Imagine a list of the users currently logged into the site or a
database query on the 5 products most relevant to the current page, for
example.)
For any serious application dev, we'd probably reach for an MVC
framework... CGI::Application/HTML::Template, for example.
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
jesse@erlbaum.net
Phone: 212-684-6161
Fax: 212-684-6226
Re: HTML::Mason?
Posted by Leo Lapworth <le...@cuckoo.org>.
On 16 Aug 2006, at 15:04, Jesse Erlbaum wrote:
> My proverbial "better SSI".
I think understanding what you are actually going to do in the SSI
would help
somewhat - is this dynamic content based on per user - or just
navigation on
the website depending on the section you are in?
Personally I prefer TT for 90% of web work, but then we've also
recently used AJAX + JSON
+ JavaScript to make pages seem very dynamic when in fact they are
all static
and the JSON files are updated offline every hour or so. We've even
put JSON
in to cookies so the entire site is dynamic to the user's
preferences, so we've pushed
the SSI client side.
Just some ideas to think about.
Cheers
Leo
RE: HTML::Mason?
Posted by Jesse Erlbaum <je...@erlbaum.net>.
Hi Perrin --
> Depending on what you want to use it for, you might also consider just
> using Template Toolkit with the in-line perl option enabled.
That's an interesting idea. I was not familiar with that option. It is
possible that a full framework is not needed.
> Or... you could write your own! It would be like the others except
> lighter and faster! And you could put it on CPAN!
Lol... I think I'll pass on that. (Once is enough!)
Is there really a need for Yet Another Web Framework? At this point,
the value of having my own set of features seems much less than the
value of finding people who can hit the ground running. Particularly in
this case... My proverbial "better SSI".
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
jesse@erlbaum.net
Phone: 212-684-6161
Fax: 212-684-6226
Re: HTML::Mason?
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2006-08-15 at 19:48 -0400, Jesse Erlbaum wrote:
> It seems to be the framework of choice, nowadays, for Perl-based server
> page systems (i.e., PHP, JSP, ASP -- any system which puts code in
> pages). By the look of it, Mason seems like it has more life than
> EmbPerl. Is that correct? Are there any other leading Perl-based *SP
> systems I should consider?
>>From what I've seen on various mailing lists and at conferences, you're
correct: Mason is the most popular solution for in-line Perl these days.
Depending on what you want to use it for, you might also consider just
using Template Toolkit with the in-line perl option enabled. The choice
is whether you want a full-featured web development framework (Mason) or
just templates with in-line perl to fit into an existing application.
Text::Template is fine too for stripped-down use but Template Toolkit
handles more of the housekeeping for you, like caching the compiled
templates.
Or... you could write your own! It would be like the others except
lighter and faster! And you could put it on CPAN!
- Perrin