Re: [cgi-prototype-users] CGI::Prototype::PathInfo

[A. P. <pag...@gm...>]

* Randal L. Schwartz <me...@st...> [2005-08-07 18:15]:
> Cool.

Ok, great, then I’ll keep working on it.

> Right now, my thoughts are that Hidden is actually doing two
> different things:
> 
> 1) Figuring out the state (from hidden fields, as named)
> 2) Mapping the state to classes (autoloading based on a prefix for the 
> class)

Don’t forget the template location bits in #2.

Looking at the source, only `render_enter`, dispatch` and
`config_state_param` pertain to #1 at all. The rest is all
neutral.

I am thinking that the way to do this would be to pull all the
other bits into CGI::Prototype::Simple, then derive from that in
::Simple::Hidden or ::Simple::PathInfo.

> I'd like to refactor Hidden so that the pieces are separate
> mixins, so that the state tracking and the state-to-class
> mapping policy are independently reusable.  Your code would
> then provide an alternative for each of those (state via URL,
> mapping via explicit table).

The mapping is not entirely extricable from the state vehicle – I
need an explicit table for ::PathInfo because URLs look like
“/edit/post/261” or “/edit/user/ap” or “/user/ap”, and so the
pathinfo parser needs a means to know which part is the mode and
which is the positional parameters.

But that’s just a matter of refactoring `name2page` to call a
bunch of callbacks at the right points, and then it could provide
for basically any mapping scheme whatsoever. I’d already been
working on that, in fact.

So I think that rather than attempting to separate state
deduction and mapping entirely, it would be enough to factor out
the mapping into a common base and reuse that. As always, loads
of slots make the job pretty smooth.

Regards,
-- 
Aristotle
“Like punning, programming is a play on words.”
   – Alan J. Perlis, “Epigrams in Programming”