Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

thoughts on creating modular perl for web application

by emilford (Friar)
on Mar 14, 2005 at 20:58 UTC ( [id://439446]=perlquestion: print w/replies, xml ) Need Help??

emilford has asked for the wisdom of the Perl Monks concerning the following question:

My task is to write Perl modules that, when plugged into xyz template system, produces flat HTML. If my Java terminology is correct, think of it as a servlet. The template system is not my concern, but rather how to best construct this type of modular Perl. The end goal is to have a series of files, that generate HTML. They can be used however, whenever, and as often as liked. As an example, suppose someone down the hall created the following:
<html> <body> <table> <tr> <td>[% $monks->getNames() %]</td> ...etc...
The template system would know that '$monks->getNames()' is Perl and would trigger my code to return the expected HTML.

Here are my thoughts...

These modules would have the necessary HTML embedded within, as well as the Perl logic. My thought currently is to have the HTML stored under __DATA__ so that it is relatively seperate from all Perl code. What I want to avoid is having a seperate file, but instead having the module as a total package. The simplest case would return the contents of <DATA> as a string. The string would be plugged in by the template system.

I want to keep the modules fairly similar in concept. As in, I don't want to have 50 subroutines, all with different names. Instead, I'd rather have each module be contained within a seperate package, so that each module could have a subroutine called getContent() that would look to <DATA> and return the correct string. Thoughts?

I'll have to do some substitutions within the HTML code stored under __DATA__. I plan to use something similar to the "template" system in the Perl Cookbook. I will also need to "require" specific files that were written by other developers, for things like database connections, etc. Will this get tricky while using packages?

I'm hoping to get some input on the design aspect from someone who has perhaps tackled such an approach. Any and all information is appreciated..

Replies are listed 'Best First'.
Re: thoughts on creating modular perl for web application
by Hero Zzyzzx (Curate) on Mar 14, 2005 at 21:06 UTC

    What you're inventing is essentially Mason.

    In Mason land, your code could live in a <%shared> or <%init>section and your variables would then be available to your HTML in the mason page.

    Your global stuff could live in a site-wide autohandler, and you can call methods on other components and different developers could easily pitch in and create new components with a minimal amount of fuss.

    Check it out, if you haven't already.

    -Any sufficiently advanced technology is
    indistinguishable from doubletalk.

    My Biz

Re: thoughts on creating modular perl for web application
by merlyn (Sage) on Mar 14, 2005 at 21:10 UTC
Re: thoughts on creating modular perl for web application
by moot (Chaplain) on Mar 14, 2005 at 21:00 UTC
      No, the templating system isn't what I'm after, but rather how to logically organize the chunks of code that the templating system would reference. So I'd have 'monks.pm' that would have a subroutine called getContent(). When [% $monks->getContent(); %] is used in the template system, the correct HTML code would be returned based on monks.pm. Make sense?

        Mason offers more than mere templatting, give it a long look.

        -Any sufficiently advanced technology is
        indistinguishable from doubletalk.

        My Biz

        Mason's various pieces revolve around the notion of "components". A component is a mix of HTML, Perl, and special Mason commands, one component per file. So-called "top-level" components represent entire web-pages, while smaller components typically return HTML snippets for embedding in top-level components.

        This sounds like what you want, but my reading of the docs suggests that components don't quite work like subroutines. Maybe you could give us some more information about exactly how your existing "xyz" template system calls Perl functions. Can you tell us what "xyz" is or is that a trade secret at your company?

Re: thoughts on creating modular perl for web application
by dragonchild (Archbishop) on Mar 15, 2005 at 01:29 UTC
    You might want to check out Apache::ASP, Embperl, and possibly even PHP. A lot of places use PHP as a glorified rendering layer on top of a Perl backend.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      A lot of places use PHP as a glorified rendering layer on top of a Perl backend.
      I am curious, but why? Why use a hammer to bang a 3" nail in most of the way, and then use a screwdriver to hit on the nail head to drive it the last quarter inch? Why not just use the hammer all the way?

      Or, just throw away the hammer and turn the screwdriver around and make it into a hammer. Would justify the adage, "No pain, no gain."

      --

      when small people start casting long shadows, it is time to go to bed
        Because PHP started life as a Perl templating module. :-)

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

        The rap is that PHP is very easy to embed in HTML and it has a reputation of being "easier" for non-programmers to use. Whether or not that's true is up for interpretation, but that's the rap.

        One example that I'm extrapolating is MacWorld.com because it's listed as a Bricolage site but has some deeper pages (like this one) with PHP extensions. Extensions don't mean much because you can tweak apache to do whatever you want, but that's my theory and I'm sticking to it.

        -Any sufficiently advanced technology is
        indistinguishable from doubletalk.

        My Biz

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://439446]
Approved by moot
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2024-03-19 03:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found