On Saturday, April 5, 2003, at 09:59 PM, Kip Hampton wrote: <snip>
Actually, notes and pnotes are "used by Apache modules to pass messages amongst themselves" (from the Apache man page).
This is fine and good, but using pnotes to pass data around _inside_ a single module (AxKit) is a bit of a hack. There's a couple of reasons I think this:
1) It's inefficient - or at the least it makes it very difficult to optimize data handling.
Explain. How is using a mechanism that's already there less efficient than re-inventing it?
2) It makes the data flow within the system unclear. It's effectively like using a global variable in the code to pass data around in - and we all know global variables are generally bad design.
Apples and oranges. The use of pnotes in AxKit provides a predictable place to for *all* AxKit classes to access/set metadata-- that's not the same thing as having a global var. And anyway, how is re-inventing pnotes' functionality (e.g. "a place to store metadata so all classes can access it") within AxKit any less "global"?
3) It ties the core of AxKit to the Apache object interface and implementation. If it was ever desired to use AxKit separate from Apache (eg. via CGI or something) then it makes the implementation quite complex as you'd have to reimplement the Apache object completely.
"What if" cases carry no weight. IMO, the individual silly enough to run a heavy framework like AxKit via CGI needs to take careful aim at their foot, and we would be wrong to help them. If you want to provide a fake $r for use in CGI, be my guest, but I don't think AxKit itself should be slanted in that direction.
I'm not simply resisting you here, Chris. There are some good ideas in the patches that you proposed, but part of what makes AxKit robust, flexible and able to perform well despite the heavy requirements of XML-based Web publishing is the fact that it takes advantage of what's already there in Apache and mod_perl. So, every little bit is not encapsulated behind some AxKit-specific interface-- so what? Sometimes the more pragmatic approach of simply using what's already there (and has proven to work) is greatly to be preferred over any subjective notions of OO-cleanliness.
-kip
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
