> Thanks for sharing this idea. From your example with the "Navigation" > module, it looks like it provides some useful services that may be used > by run modes, but are not run modes themselves. I am fond seperating > "run mode" code from supporting services code, but this isn't a way that > is intuitive for me to do it. The module Navigation was meant to show what one would need to write to glue different modules together, sorry I did not do a good job of saying that. If you look back in my email I say that modules submitted to CPAN would need to follow some manners, they should not claim the start mode. The module one would write to glue them together would claim the start mode. > Instead, I think about having modules that can be "used" and then > provide extra CGI::App run modes that can be used. > CGI::Application::ValidateRM works like this. This is what I said, I think. The array @Modules is filled with all the modules the will be used by the CGI::App. > Or alternatively, a module could have it's own OO interface, and the > CGI::Application project would talk to it through that. That design > seems the best to me, because it makes the module potentially available > to non-CGI::App projects as well. That is nice, so the best thing to do if that is what you want is to make to different modules in different name spaces. > In either design, it makes sense to me to "use" the supporting modules > from the Run-mode modules that need them. That is what I said. > What I think about the idea of having a instance script that patches > together multiple run mode modules, I wonder why it wouldn't work to > just have two instance scripts and create pages which hyperlink between > them (assuming they really are seperate applications). That is black box integration, I am proposing white box, or glass box integration. Say I want to make a web page that uses two or more pre-packaged CGI::Apps, I need to users to authenticate to my site, as well as CGI::Carp carpout. This would be a pain to maintain three or more scripts, don't more get I need to write a script to glue them together. If they where written to use this super class then all I would need to do is create my glue module, probably just navigation, a super class of my own to provide authentication in the pre-run, and the script would handle the carpout. This is much easier to maintain than three or more different scripts. P.S. I forget to push the use base of CGI::Application to the array @Modules, this way you can easily use your own super class in the mix. Thanks, JF --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/suppressed/ To unsubscribe, e-mail: suppressed For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.