Front page | perl.beginners |
Postings from May 2012
Re: Template toolkit issue [SOLVED]
Thread Previous
|
Thread Next
From:
Lawrence Statton
Date:
May 3, 2012 08:18
Subject:
Re: Template toolkit issue [SOLVED]
Message ID:
4FA2A1BB.5000508@cluon.com
On 05/03/2012 09:19 AM, Mark Haney wrote:
> On 05/03/2012 09:06 AM, John SJ Anderson wrote:
>>
> Okay, perhaps that was hyperbole on my part. Although, honestly, I
> included all the other things websites can do not just output HTML.
>
And you can do all of those things with Perl. You just need to pick a
tool to integrate Perl with HTTP. Yes, you could do that with CGI (the
protocol) and you could use CGI.pm to handle the HTTP parts of serving
web pages.
> Again, you're probably right, I should leave that bit out of the
> replies. I really want to build this entirely in perl. Too much of the
> existing code is pure perl. Maybe I hadn't made that clear throughout
> the posts I put on this list. If that's the case, that's my mistake, and
> should certainly not be any indictment of anyone misunderstanding my
> problem.
>
Then stop being so damned snarky - you are not going to get people to
help you by playing the "I'm going to insult your toolchain so you will
feel compelled to defend it and do my job for me" card. That almost
always ends with your threads either being ignored, or given one-line
answers. If you want interactive help, *adjust your attitude*.
>
> This was really more of a point that in some cases I've been told 'don't
> do this', or 'it's not done this way' without any real explanation for
> /why/ it's not done that way, or at least get me to resources that do so.
>
I guarantee - if someone says "Do this" or "Don't do that" and you ask
the group "Why did Bob say that? What are the plusses and minuses of
Template versus Mason versus XML::LibXSLT?" then your mailbox will be
FILLED with different people's experiences with the different toolchains.
> No one is here to solely hold my hand. I am well aware of that, which is
> why I've asked not just for a solution, but additional places I can do
> my own research. There's nothing more frustrating that hearing 'don't do
> this' without knowing why not.
Well - if you want the exhaustive answer it's going to be "Learn every
one of the different ways for generating a site with Perl and pick the
one you like," but since that task would take several months, I can
guess you'd like to short-circuit that with "Which toolchain will work
for me?"
I'll reiterate -- I like Mason ... I've been using it for a long time.
If you're comfortable with PHPs <% $foo %> syntax, then Mason will play
into your wheelhouse.
If you LIKE the feel of TT (Template Toolkit) then, by all means,
continue using that - and take a look at Catalyst.
>
> I appreciate the time taken for you to reply. As it is, please point me
> to how I can get perl to do CGI without CGI.pm.
I'll follow up to my own response in a few minutes with a trivial
program that produces content without using CGI.pm I need to configure
a webserver to do CGI which I have none at hand.
> I'm actually quite
> curious about how to do this as /why/ the move away from the module in
> the first place. (Although the latter is completely irrelevant other
> than for my personal curiosity.)
>
I think the reason *I* abandonded CGI the module is because I abandoned
CGI the protocol - the performance hit of compiling your code *every
time* a resource is accessed was just too much for the vast majority of
resources on the web. Your mileage may vary - if you have a resource
that needs to be generated once every few hours, and the run-time to
PRODUCE the content is high compared to the overhead of the Perl compile
phase, then CGI may work just fine for you. Giving you the answer to
that question requires YOU to give us much more information.
Nobody but you can tell you what your favorite flavor of ice-cream is.
Further - one of my big beefs with CGI.pm was it conflated two totally
different missions into one module - the first was the "Handling HTTP"
phase (picking up arguments, producing HTTP headers) and the "Generating
HTML" phase with it's methods like p().
In fact - I think I can safely speculate - your conflation of three
separate concepts: CGI the protocol, HTTP and HTML, can be attributed
in part to the fact that you have done what Web programming you've done
to date with that module.
> Any resources out on the web about this will be greatly appreciated.
I know of none. I'm not saying they don't exist - but I've never seen one.
Thread Previous
|
Thread Next