* 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


is supposed to mean

    state => 'My::App::edit::user',
    positional_param => ['ap'],

rather than

    state => 'My::App::edit',
    positional_param => ['user,'ap'],


    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,

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.

“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

Reply via email to