>>>>> "A" == A Pagaltzis <[EMAIL PROTECTED]> writes:
A> Looks sensible enough, but the mapper must be more abstract than
A> you propose. Abstraction on the level you have in mind is not
A> tenable because ::State::Pathinfo needs knowledge from
A> ::Mapper::StrictLookup to be able to tell that
A> /edit/user/ap
A> is supposed to mean
A> state => 'My::App::edit::user',
A> positional_param => ['ap'],
A> rather than
A> state => 'My::App::edit',
A> positional_param => ['user,'ap'],
A> or
A> state => 'My::App::edit::user::ap',
A> positional_param => [],
Ewww. I'd never use code like that. But if you want to do it,
I suppose you can replace all of ->dispatch isntead.
A> How would a generic protocol for ::State::* to ask ::Mapper::*
A> for possible states look? Is it sensible to define one?
A> ::Mapper::Prefix would have to crawl @INC or something like that,
A> f.ex.
Yeah, hadn't envisioned that. In my mind, state should come entirely
from the incoming environment. Mapping that to a class should be a
separate responsibility for maximum pluggability. Looks like the
best way is to leave ->dispatch and call yours something like
CGIP::Dispatch::VariablePathinfo
or something like that, using ::Dispatch:: rather than ::State:: or
::Mapping:: to show that it's replacing both.
A> After all is said and done, ::State::Pathinfo will have to be
A> specific to ::Mapper::StrictLookup anyway, so that separation
A> makes no sense. The only thing that does make sense to abstract
A> is how a state is mapped to a class *after* it is fully looked up
A> and validated.
A> But that is so trivial a task that I don’t really see the point
A> in a separate ::Mapper::* hierarchy. Putting a ->get_class with a
A> default `eval "require ${prefix}::${state}"` implementation into
A> CGIP would suffice.
I'm presuming the default ->get_class simply returns the prefixed
string classname, which is presumedly defined using some other means
(like all in one file). The autoload override allows it to be
dynloaded if it doesn't exist, but there are CGIP instances where that
won't be necessary, and I'm trying to keep the core CGIP as lean as
possible.
Consider also something like Slashdot, where the templates are loaded
from a database... I can also see that here. Maybe state-to-class is
dynamic based on current user ID or other security parameter? Really,
there's policy there, and it's best to let that be plugged in.
But if you need to poke around in order to even know the state, you've
got a tight coupling there, so you're going to be overriding all of
->dispatch, it seems.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
cgi-prototype-users mailing list
cgi-prototype-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
