> What are the basic advantages, disadvantages, and limitations of: > (a) stuffing all this setup/framework code into a module (either a new module or subclassing Apache::RegistryNG as you mention below), > versus, > (b) stuffing it into a handler that all requests for a large subset of the pages on this site have to go?
Subclassing RegistryNG is pretty much identical to making your own handler. In both cases, you have some common code that runs on every request and then it decides what other code should be run to handle this specific action. In my opinion it's clearer this way than if you make a module with the init code and call it explicitly, but I can't think of a very good technical argument for it. The handler/RegistryNG approach lets you do neat things with subclassing, like create a special subclass that does some additional setup for a certain group of scripts. That wouldn't be as clean if you use the init module approach, since you'd have different scripts calling different init modules. > Other than the speedup from reduced overhead, what are the primary advantages > to using handlers rather than Apache::Registry for content handlers? You can actually use subroutines without fear! Also, reducing the amount of magic (i.e. all of that package generation and eval stuff that Registry does) can help clear up confusion. And you can use __END__ and __DATA__. The big change in moving from Registry (or RegistryNG) to a handler is that you have to move your code from the main part of the script into a subroutine and turn the script into a proper module. There's good stuff on this in the guide. > The primary disadvantage seems to be that I have to restart httpd an awful > lot, but maybe Apache::Reload can help here. Can it be used to reload > modules that implement handlers? Yes, it should cover your needs. > This is a very helpful article. I have read it several times and still > keep coming back to it. I would also like to learn more about the > "model-view-controller" approach in general. A Google search will give you tons to read, but most of it refers to Java. It's all applicable to mod_perl though. - Perrin
