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.
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.
So some options are:
* Use a different namespace for the new system (e.g. CA::URLMaps,
CA::Routes, CA::Launcher, CA::StartMeUp etc.)
* Put all the old docs in CA::Dispatch::COMPAT.pod, but leave all the
old features turned on for backwards compatiblity.
* Do something as Rob suggests with a pluggable dispatch architecture.
In this case CA::Dispatch would probably become
CA::Plugin::Dispatch, anyway.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
