Michael Graham wrote: > Timothy Appnel <[EMAIL PROTECTED]> wrote: > >>I'm realizing that I may have jumped to the conclusion that we are >>working with CGI::Application::Dispatch as opposed to starting over. >>Does anyone disagree with building on what CGI::Application::Dispatch >>has established? > > > CGI::Application::Dispatch has a very central namespace, and it would be > good if the community-endorsed "next generation" dispatcher could use > it.
I agree. > However, what we are suggesting is quite different from what > CGI::Application::Dispatch currently does. It's similar in spirit, but > in implementation, there are lots of little details that differ. > > I'm worried that the documentation becomes very confusing because the > old terminology and new terminolgy are similar, even though the > implentation is different. E.g.: > > %TABLE is used to map specific URLs to specific modules. > @DISPATCH is a new system for mapping URL-rules to specific modules. > > A user familiar with the old system will understand this. A new user > will be totally confused. > > And you can't leave the old behaviour undocumented, because people are > still using it and they'll want to look up stuff in the docs. I'm not so sure this would be a problem. I think we can document both approaches and note that the old one is deprecated (like D::FV does). Put the newer approach in all examples, but leave the older stuff there, maybe in a different section. > So some options are: > > * Use a different namespace for the new system (e.g. CA::URLMaps, > CA::Routes, CA::Launcher, CA::StartMeUp etc.) Dispatch is a much better name though :) > * Put all the old docs in CA::Dispatch::COMPAT.pod, but leave all the > old features turned on for backwards compatiblity. Right now I'm inclined to do something like this, even if I don't split it out into it's own separate pod file. > * Do something as Rob suggests with a pluggable dispatch architecture. > In this case CA::Dispatch would probably become > CA::Plugin::Dispatch, anyway. But C::A::D can't really be plugin since it sit's outside of C::A. Especially in mod_perl where it becomes you PerlHandler. It doesn't add anything to C::A, it just handles the mapping of URL to module/rm. That said, the new approach would be a mixture of both. C::A::D would still need to sit outside of C::A, but there would need to be another module (or maybe just a different usage of C::A::D) that acts as a plugin to add the uri_for() and link_to() methods to C::A My preference would be to keep all the old features of C::A::D but point people to ways of accomplishing the same thing with the "new-way". Maybe even make the "old-way" work behind the scenes by using the "new-way". I'm kinda busy right now, but I have something in my head. If I get some time today or tomorrow, I'll write it up the API and see what others think. -- Michael Peters Developer Plus Three, LP --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
