> home
> how we work
> who we're working for
> about us
> publications
> buy apache essentials
> client login

play
static·red
edmonton and area web development

Current Projects

Edmonton Weather


>>Le blog.

speakeasy archives


embedded perl

<< how long till doublespeak comes along? | Main | good for her eyes on the laptop... >>

update: Talked with Brian about it a bit more, and he managed to clear up some of the issues I had below. I'm going to give it the old college try, and see what happens.

OK, so I've been researching Embedded Perl, and for the life of me I can't see a reason for me to move over to it. Here are first blush impressions...

From a perl coder's point of view, I can see how it would be a great thing -- you can embed your code directly in the document to increase performance as well as 'hide' your code from the general populace (a great thing from a security perspective, as they now don't know what language you've developed your app in). From a programmer's point of view, embedded perl is likely a very good thing.

The point of view of a content manager is another beast entirely, however. Perl code in my content is the last thing I want to see. The beauty of SSI and CSS is that I can totally seperate my content from any form of presentation. From my perspective, that's a very good thing ™. The way it's set up seems to separate content in the same way as SSI, so no worries there

From the looks of it (and with some explanation by Alan), you set up a single base.epl file, which contains both your header and footer information, seperated by a [- Execute ('*') -]. Conceptually, I can see how this works -->the server wraps the base.epl around whatever file is currently being requested, filling in whatever needs to be filled in...

I'm not yet sure how embperl deals with multiple footer files. For example, on my work site I have different footer files for different sections of the site -- products, support, etc. Instead of doing the very very simple #include virtual='/ssi/sectionfooter.shtml' it sounds as though the base.epl will have to have a set of if/then conditions to deal with this -- which is a hell of a lot more complicated than I need it to be. Though I don't like the organization method much, you can place 'replacement' footer files (or header files) in the directory you want affected, and it'll replace the 'stock' files with those. The only thing i can't see yet is how to do multiple footer files in the same directory.

But I'm still checking it out, and playing with it myself, so I may have a change of mind

Posted by Darren James Harkness on Wednesday, January 9, 2002 03:25 PM
Trackbacks...


Comments:
>> Arcterex » Wednesday, January 9, 2002 04:32 PM

Just as a note, this is what I have been experimenting with on peer2peer personals and it works very well so far. When I have time I'll move it into the user stuff (search, submit) and not just use it in the admin side of things.


As darren says, it's better for programmers who are sick of cgis and want something nice like php but with perl, but from what I've seen (and I haven't used it on a large scale site yet) the embperlobject (inheritance, what darren described) could have very cool possibilities. The main thing though is the mental shift from "including multiple headers/footers" to "doing it the embperl way" (which I'll not describe here but simply redirect all to http://perl.apache.org/embperl


Kudos to darren for giving it a chance though.


Post a comment









Remember personal info?


Comments:


* under no circumstances will your email address be traded for a sack of quarters. No-sirree.