>>>>> "A" == A Pagaltzis <[EMAIL PROTECTED]> writes:

A> and hi Randall in particular. I have a working version of this,
A> largely derived from ::Hidden for consistency in slot names. (It
A> also let me copy 95% of the POD verbatim. Writing documentation
A> is easy when it’s already done for you. *g*)

Cool.

A> It has a somewhat distinct personality in that it wants an
A> explicit list of page names to validate (I’d rather prefer if
A> ::Hidden worked the same way – I like my code hardwired for “no
A> surprises ever possible”) and works slightly differently in a few
A> minor aspects. But by and large a well-written ::Hidden app would
A> translate to a ::PathInfo one with almost no changes.

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)

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).

As usual, my time is limited, but if someone wants to go into more
thoughts on that, I'm willing to discuss it.  I'm also looking at
moving my sources to SF so that I can have more committers.

A> I’ve also added a little twist so that “foo.cgi/bar/42” will
A> dispatch to “My::App::bar” and set the “page_id” slot to 42 in
A> the process. (The slot defaults to undef.) This is very handy for
A> cruft-free, clean URLs.

Nice.

A> Now my question is: should I put this on CPAN, or should I leave
A> the space to an “official” version? Or should I just post it
A> here, maybe? If I put this on CPAN myself, what should I put in
A> the AUTHOR and COPYRIGHT & LICENSE sections of the POD? There is
A> so little code in there that the notion of authorship is a bit
A> ridiculous either way, but I also copied several pages of POD
A> that I can hardly claim authorship of.

Well, if we create the SF archive, this can stay one or two distros.
I'd actually like to see separate distros like:

        CGI::Prototype
        CGI::Prototype::Hidden (mixin for param->state)
        CGI::Prototype::Autoload (mixin for state->class via autoload)
        CGI::Prototype::Pathinfo (mixin for info->state)
        CGI::Prototype::$mumble (mixin for state->class via $mumble)

etc.  Or maybe even go down one layer... where
CGI::Prototype::GetState::$mumble is for all state determiners, and
CGI::Prototype::DoState::$mumble is for all state mappers.  I hate those
names, but I hope the idea is clear.

-- 
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

Reply via email to