Thinking about this a bit more I wanted to run my ideas past the list for feedback.
First of all, the application is more or less an application server, with the feature set being heavily on ecommerce functions (shopping cart, payment processing, file/user/group security, etc..). The server accepts incoming requests, passes them off to various internal handlers based on what the request was, and displays the results either through the template toolkit, or through some other custom modules if the response is not html. Rather than passing stuff around in globals or via pnotes, I was thinking about making a request object and then using an all OO structure. Modules that have functions that are called via callbacks could have a new() method that is called before the template processing, and the new method would be passed the request object so it can setup all the variables it needs for the other methods that are accessed via callbacks at a later time. Does this sound like a good way to go? Once this project is finished we are moving a lot of clients over to it from another solution, so I really want to get this right the first time. Chris ----- Original Message ----- From: "Chris Ochs" <[EMAIL PROTECTED]> To: "Perrin Harkins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, March 21, 2004 5:51 PM Subject: Re: tied hashes frustration > Ah yes pnotes. You know actually I think you mentioned this once before in > a similar thread I brought up, not sure why I didn't remember it. > > > > since some of the methods in my modules are called from the template > toolkit > > > via callbacks, it's really difficult to make sure those methods have > access > > > to the session variable without using global variables (making the > session > > > variable an argument to the template page functions is not an option). > > > > Why is that? You may run into more trouble later on if you have > > designed things in a way that prevents you from passing data to Template > > Toolkit. > > > It's not an option simply because I don't want to make people pass extra > stuff that shouldnt' be needed (variables that the application server > already has access to), not because of a design limitation. > > Chris > > > > > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > > -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
