* Randal L. Schwartz <email@example.com> [2005-08-07 18:15]:
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
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
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.
“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