Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
Let me know if you are still interested in this project. I started it
when I had some idle time between projects, but obviously haven't had
time to work on it lately. It was more of an academic endeavor (I
wonder what it would take to do this, and what I could learn) than
anything else, but perhaps it could be useful in the real world.
Zak
Original comment by zak.burke
on 22 May 2011 at 1:21
Yes, I'm still definitely interested in it. I've also invested some time in
studying the ability of perl to do php-like tags where templated blocks can
contain opening tags with the matching closing tag in a different block.
None of the perl template languages so far can seem to do that.
I can provide an example if you like. But yes I think a perl version of
CodeIgniter is spectacular. CodeIgniter is a popular framework for its
no-nonsense approach. I've used it (the php version) on a number of
projects.
Dan
Original comment by dhaart...@gmail.com
on 14 Jun 2011 at 5:38
I'll add you as a committer.
I don't think you'll find a way for Perl to mimic PHP's approach of hopping
back and forth between code interpretation and output, but I don't think that's
a great loss. You can write your own templating language that supports
if-then-else and foreach-loops and you've covered most of what you'll need.
Anything more complicated than that and I think you should question whether
that much logic belongs in a view-template, rather than in a library or
controller.
Original comment by zak.burke
on 14 Jun 2011 at 6:13
With all due respect, I despise that approach. :) That's what everyone else
tried to do. I've worked a great deal with Text::Template and some others,
and I've seen how messy things can get with the realities of code having to
exist in templates.
Soon I'll commit some examples of my progress on a php-like tag
preprocessing pragma in perl. I got it working and it really wasn't too
complicated.
Dan
Original comment by dhaart...@gmail.com
on 16 Jun 2011 at 7:15
Nice work. The render and expand methods you wrote should probably be in
kbzb::libraries::output, rather than on kbzb::libraries::controller. You could
also add logic to inspect the view's extension to determine how it is parsed,
e.g. .htmx files just get variable substitution and .tmpl files get the
full-blown eval treatment. Or you could switch output handlers via a config
preference. Your call, bu there needs to be some way to choose.
I figured you would have to be doing some kind of read-and-eval. Have you done
any performance benchmarks? In the past, eval EXPR had performance issues due
to the way it runs: each EXPR is parsed and executed as its own program.
Original comment by zak.burke
on 22 Jun 2011 at 1:51
Original issue reported on code.google.com by
dhaart...@gmail.com
on 13 Oct 2010 at 3:02