|P is for Practical|
thoughts on creating modular perl for web applicationby emilford (Friar)
|on Mar 14, 2005 at 20:58 UTC||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:
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..