It can sometimes depend on your environment. If you want to create template objects with different constructor arguments per request (different template search paths) you would want to create a new object per request. Of course, if nothing changes for the object per request then it would benefit you to create the template object once so as to take advantage of caching and keeping object in memory as opposed to re-initializing.
At least that is how I have interpreted things : ) > > Given the chocie of constructing the Template object once per child > > versus constructing it in the apache root process (before forking) > > and letting it be shared, is there any advantage of one approach > > over the other? > > I'm initiating template before forking. I think will save some initiation > time for the first TT request for the child process. > > But as I understand, this will only be effective if you can get all > the tempaltes to be cached in memory during the initation. There are > some suggestion on how to do this in the list archive. > > > > > I will take this time to ramble in public of things I't thinking of > right now, on how to create a TT application framework under > mod_perl. > > > *** There are some things that all my TT+mod_perl-based applications > do. This list has grown for each new application I have done. > > The basic design is the same as previously explained. > > * TT files handels *presentation* of data (TT files is called handlers) > * Perl modules handels DB modification (modifications is called actions) > > The website is created just as with html pages, only they are tt > pages. This means that the URL shows the tt page and links will point > to other tt pages. Apache gives the URL to the TT handler. > > > Basicly, the handler does these things: > > # 1. Reset global variables > # 2. User authentication > # 3. Page is already generated? (redirect) > # 4. Set language > # 5. Perform the actions (DB modifications) > # 6. Set up the TT parameters > # 7. Choose handler (a failed Action could cause a redirection) > # 8. Check route (This is a stack of pages to visit) > # 9. Check handler (find actual file requested) > #10. Construct header (including cookies, et al) > #11. Process template > #12. Clean up > > > > I have now expanded this by allowing diffrent applications to expand > and modify the behaviour but still use the common library. The actual > apache configuration for a specific application, in a .htaccess file: > > PerlFixupHandler Frame::Handler > PerlSetVar approot /usr/local/my_app > PerlHandler My::App::Handler > > The fixup handler sets the library path (approot/lib) and the > individual application can set up the enviroment before calling the > common frame code doing those 12 steps. > > > > I am now thinking about how to redesing this to encapsulate all the > diffrent configuration options. Each application could use it's own > user authentication, session handling and other things. I'm thinking > about: > > 1. What should be global varaibles and what should be objects > 2. In what object/variable should I put the diffrent things > 3. What should the process look like, object initation, et al > > > This is a possible object heiarcy: > > Framework --> Application --> User --> Session --> Request > > The framework has many application. Each application has many users > (guests or identified users). A user can have many sessions and each > session consists of many requests. > > > But the above doesn't say how to initiate the objects. You will > basicly start out with just an Apache request object. The process > will be something like this: > > During Apache startup: create a $FRAME object as a global variable. > > In FixupHadler: Set path to app. Create a new Request object for $FRAME > > In the app Handler: Create User and possible Session obj. Set up > hooks and other things. Execute the Frame request. Clean up. > > > > > This framework is indipendant of data storage. DBI, if used, is > called in the app handler. The app also implements or choses user and > session handling. > > > > > > Maby this could be of some help or inspiration. Maby not. :-) > > -- > / Jonas - http://jonas.liljegren.org/myself/en/index.html > > _______________________________________________ > templates mailing list > [EMAIL PROTECTED] > http://www.template-toolkit.org/mailman/listinfo/templates
