* Randal L. Schwartz <merlyn@stonehenge.com> [2005-08-15 18:40]:
> Then, I wanna refactor the current Hidden into its pieces:
>
> a mixin for ->get_state (call it CGI::Prototype::State::Hidden)
> - uses the hidden param to get a state name, or a default state
> a mixin for ->get_class (call it CGI::Prototype::Mapper::Prefix)
> - uses the state name with a prefix and does an autoload
> a mixin for ->render_enter and ->engine_params (call it
> CGI::Prototype::Render::TT::Wrapper)
> - uses a TT search path = @INC and defines a wrapper
>
> Other mixins:
>
> CGI::Prototype::State::Pathinfo (yours)
> CGI::Prototype::Mapper::StrictLookup (yours)
> CGI::Prototype::Render::HTMLTemplate::* (for people that prefer H::T)
>
> How does this grab ya?
Looks sensible enough, but the mapper must be more abstract than
you propose. Abstraction on the level you have in mind is not
tenable because ::State::Pathinfo needs knowledge from
::Mapper::StrictLookup to be able to tell that
/edit/user/ap
is supposed to mean
state => 'My::App::edit::user',
positional_param => ['ap'],
rather than
state => 'My::App::edit',
positional_param => ['user,'ap'],
or
state => 'My::App::edit::user::ap',
positional_param => [],
How would a generic protocol for ::State::* to ask ::Mapper::*
for possible states look? Is it sensible to define one?
::Mapper::Prefix would have to crawl @INC or something like that,
f.ex.
After all is said and done, ::State::Pathinfo will have to be
specific to ::Mapper::StrictLookup anyway, so that separation
makes no sense. The only thing that does make sense to abstract
is how a state is mapped to a class *after* it is fully looked up
and validated.
But that is so trivial a task that I don’t really see the point
in a separate ::Mapper::* hierarchy. Putting a ->get_class with a
default `eval "require ${prefix}::${state}"` implementation into
CGIP would suffice.
Regards,
--
Aristotle
“Like punning, programming is a play on words.”
– Alan J. Perlis, “Epigrams in Programming”
-------------------------------------------------------
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
