Late chime-in, but my vote: -1
I'm a strong H::T proponent (despite Cees' multiple attempts to sway me
to the dark side ;)), so I enjoy the coupling of functionality.
That's subjective, of course, so let me add something objective. If it
were to become decoupled, I would have to go through
Hmm, I just saw this (catching up on my email, if you can't tell already
;)) after I replied directly to Robert's previous email on this topic.
I wanted to share that I'm using/enjoying Rose, too, but also that I
stumbled onto it and gave it a shot after reading Randal's columns on
the
Wow, your elegant argument has convinced me that all my issues are
irrelevant and I will switch immediately.
Ben
On Oct 20, 2007, at 2:33 PM, Ron Savage wrote:
Ben Hitz wrote:
Hi Ben
I am not a fan of inside-out objects in perl, because I have much
old code which uses old-style hash
A. Pagaltzis wrote:
* Robert Hicks [EMAIL PROTECTED] [2007-10-21 21:10]:
I have only seen you post things you don't like.
Heh. So it goes.
So, what would you use?
Well, as I said, both Mason and Petal have things that
immediately put me off – but I’ve yet to use them in anger.
So I don’t
Jason Purdy [EMAIL PROTECTED] wrote:
Late chime-in, but my vote: -1
(Not that this is a democracy, but...) I vote no, too :-)
HTML::Template, while it annoys me at times, is a small, fast and
easy-to-install. Therefore it is an entirely reasonable default templating
engine, which you can
On 10/22/07, Jason Purdy [EMAIL PROTECTED] wrote:
H::T is a simple and fast templating engine that enforces strict MVC,
too.
Simple, yes -- to a fault. In my experience, I find what constitutes
the parts of MVC to be subjective. I haven't heard much of an argument
about what belongs in the
I think of HT as a nice freebee that's pretty transparent and
inexpensive to install (pure Perl, etc.) and relatively unobtrusive. I
don't use it, but it's been used here before I came in and put a TT
stake in the ground. I've been using TT for a number of years now, and
am comfortable with its
On 10/22/07, Berg, Eric [EMAIL PROTECTED] wrote:
So, again, now that we've been all over this, what's the rub here?
I was kind of wondering that here as I wrote my last message.
Templating religion aside, I *think* it's a choice/modularity vs.
backwards compat debate at the heart of it. Perhaps
* Ricardo SIGNES [EMAIL PROTECTED] [2007-10-19T18:10:17]
I see that the devel version of CGI::Application uses Class::MOP. Neat.
Except it doesn't.
I thought, Hey, I'll just send Mark a patch to remove this. I had an ancient
checkout of CGI::Application, and I did a pull and saw:
Thu Aug
I didn't notice CA::Dispatch::Server when I was doing some poking at some code
the other day so instead I patched CGI::Application::Server to handle
::Dispatch modules.
I think this was a good mistake: CADS doesn't really strike me as being as good
a design as CAServer. In CADS, you say:
*
* David Kaufman [EMAIL PROTECTED] [2007-10-22 21:35]:
a) harder to install
(not easier, as the OP suggests) because new users whould then
have to jump through the additional hoops of choosing and then
installing a templating engine. And the choosing would lead new
users to threads full of
* Robert Hicks [EMAIL PROTECTED] [2007-10-22 20:35]:
http://www.fs-output.com/trac/wiki/Nenshi
Is that you then?
Whoa! No, I had not seen that. I’ll have to take a look and see
if our ideas about the design agree sufficiently.
Thanks for the link!
Regards,
--
Aristotle Pagaltzis //
I vote a gigantic -1. I like H:T and don't believe it's bad C:A
requires it as a default. Those savvy enough to use TT (or others)
shouldn't be affected by the required install of a simple default.
Mark
# CGI::Application community mailing list
##
13 matches
Mail list logo