Matthew Pressly <[EMAIL PROTECTED]> writes:
> 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
