> > 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.
>
> Let me ask the same question I put out earlier. Why not? Mark put out
> his and I addressed how his issues could be addressed in that
> framework. I don't see what you mean or why such a path is so
> necessary.
Sorry, I may be stating the obvious, but all I'm saying is that the
following are two very different systems, but similar enough in spirit
that they may confuse new users:
# old style
TABLE => {
'blog' => 'MySite::Blog',
'admin_users' => 'MySite::Admin::Users',
}
# new style
TABLE => [
'blog/:rm' => { app => Blog },
'admin/:app/:rm' => { prefix => 'MySite::Admin' },
]
But maybe I'm not understanding your question. Are you asking me why I
think these systems are different? Or are you asking me to justify why
I want the second one?
> I don't agree with adding @DISPATH and a new system for mapping
> though. That is an artificial distinction IMHO. TABLE contains a
> reference to a hash in the current implementation. It would be trivial
> to check what type of reference is in there and act accordingly. This
> way backwards compatibility is maintained and users used to the old
> way can keep using it.
Good point - there's no reason why it can't still be called TABLE. That
has the nice side effect that the system doesn't have to figure out what
to do if the user provides both a new-style and an old-style mapping at
the same time.
> > * Use a different namespace for the new system (e.g. CA::URLMaps,
> > CA::Routes, CA::Launcher, CA::StartMeUp etc.)
>
> If the community is serious about taking some cues from Rails then
> adding more similar, but different options is not advisable.
I tend to favour standardization over competition myself. All I'm
saying is this has to be balanced with legacy code and backwards
compatibility issues. Sometimes it's cleaner to start fresh.
> > * Put all the old docs in CA::Dispatch::COMPAT.pod, but leave all the
> > old features turned on for backwards compatiblity.
>
> Once again, I don't see why this would be necessary. Adding a note in
> the documentation stating the array reference is the preference and
> were the hash reference came from should be sufficient.
I'm certainly willing to go this route. I'm just saying we should be
careful, is all. I've seen modules with layers of legacy documentation
that were really confusing to me when I approached them as a new user.
The Rails quotes on flexibility were interesting. I tend to agree with
whoever said "absense of constraints are the enemy of art".
In terms of this discussion, I hope it doesn't look like I'm arguing for
flexibility for its own sake. I'm trying very hard not to request
features that I *might* need in the future. Sure I've done some
speculation, but when I've requested features, I've tried to restrict
myself to real URLs that I already use in my own homegrown mapping
system.
From my perspective, with my variety of real-world mapping requirements,
allowing '/string/:app/:rm' => { prefix => 'Foo' } is a *minimalist*
solution. Believe it or not. :)
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]
