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

I have a set of scripts that I did not write in an Object Oriented manner (Bad programmer! No buiscit!). I'm trying to go back and rewrite them, as it appears that I'll be adding features, but I'm having some troubles.
Summary:
File: mylib.pl #This file defines two subroutines. sub My_Load_Func { ($file_to_load, $ID)=@_; #ID is the page id in a database, used by some of the embedded rou +tines. # If I could set ID as a variable in the mylib.pl object, I could +use # this slot in the templates to pass the object, but I haven't fig +ured out how #Function calls My_Define_Vars, passing it the $ID, then #Function now loads $file_to_load via Text::Template, # placing a "require /path/to/mylib.pl" in the PREPEND section # (Text::Template allows you to embed perl code, # but each embedded block is in a new namespace. # Text::Template also passes in the Vars defined in My_Define_Vars } sub My_Define_Vars { #This function sets several variables, #Some are static (such as RootPath, which is prepended to any paths +) #some are looked up in a database based on the passed ID. #Under the current system, I have several variants of mylib.pl, #Each with different variations on these variables. #This lets me use the same content pages (below) with different tem +plates and variables #to generate different pages (for example, test site vs live site, +text site vs graphical, etc) } file: Content.html # This is a sample content file. #I have several hundred of these, and don't have sole control over the +m # so any redesign of the system shouldn't modify how these look #Text::Template is set to look for <!! !!>tags <!!&My_Load_Func($Var_With_Header_Template_Path,$ID)!!> <!!$BeginText #depending on version of mylib.pl, can be blank or can b +e <TEXTAREA> wrapper for editing !!> HTML content here <!! $EndText!!> <!!&My_Load_Func($Var_With_Trailer_Template_Path, $ID)!!> file: Template #there are many templates. Each template can # call other templates through cascading &My_Load_Func calls. # Eventually results in HTML. file: Calling script #There are several calling scripts, each with a different purpose #THese scripts are little more than: #--Determining which file and ID to pass to an initial call to My_Load +_Func, #--which mylib.pl to use, #--what to do with the results.
My trouble is that the "new namespace" feature of Text::Template means that I can't just turn mylib.pl into a module with my script setting the vars in My_Define_Vars, because they won't survive in nested My_Load_Func calls. (Under the current model My_Define_Vars gets called for every new block of embedded perl)

Lastly, I know the current method is hideously inefficient, but that was not a design concern, as they deliver static informational pages. I use the scripts to build the flat HTML files that are served normally. The templating system is used to help with development. (Which it has succeeded at). Any advice on modifying this system to a more expandable, maintainable format appreciated.

Replies are listed 'Best First'.
RE: Objectifying after the fact
by Aighearach (Initiate) on Jun 17, 2000 at 00:02 UTC
    From the book of St. Larry:
    : Let's say I have a perl object in an OO database.
    
    Let's not.
                 -- Larry Wall in <199904091918.MAA06535@kiev.wall.org>
    
    I guess no biscuit for Larry, either... oh well, I guess we can all pitch in for some fries.
    Paris Sinclair    |    4a75737420416e6f74686572
    pariss@efn.org    |    205065726c204861636b6572
    I wear my Geek Code on my finger.
    
Re: Objectifying after the fact
by swiftone (Curate) on Jun 16, 2000 at 22:26 UTC
    Note to any who may be curious: I think I have found the answer. Text::Template lets you use a package in import variables as well as a Hash (as I'm currently doing). A package should be namespace independant, so I'm tackling it now. I'll update this if/when I have results.
Re: Objectifying after the fact
by swiftone (Curate) on Jun 16, 2000 at 19:02 UTC
    D'oh! No _biscuit_ either.