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:

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..

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'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?

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.

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."

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.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other