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

2005-09-09 Thread A. Pagaltzis
* Terrence Brannon [EMAIL PROTECTED] [2005-09-09 21:05]:
 I think the resource id should be a reference to an anonymous
 array
  [ 283188, 43 ]

Then split the string into an array and save it in a slot in
`app_enter`?

It might be a good thing if this were the default behaviour, but
I have no basis on which to make that call, so I didn’t.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;


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


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

2005-08-15 Thread A. Pagaltzis
Randal,

* A. Pagaltzis [EMAIL PROTECTED] [2005-08-11 17:40]:
 I was hoping to start refactoring ::Hidden into bits that can
 be reused in ::PathInfo and others and those which can’t.
 ::PathInfo could then be separate or be part of the distro, but
 that’s a different issue.
 
 Do you agree with my assessment that the state-to-class mapper
 can be reused by state deductors, but vice versa does not work
 so well?

could you please give an answer to these questions?

Or if you are too busy to coordinate this right now, could you
please say that instead?

I need to get some work done in the Here And Now; I can’t spend
much more time waiting. If you don’t have time either, I’ll start
a separate ::PathInfo distro for now and we can always merge bits
later.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/


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


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

2005-08-15 Thread Randal L. Schwartz
 A == A Pagaltzis [EMAIL PROTECTED] writes:

A could you please give an answer to these questions?

See, that's the problem when I try to take a weekend off, like normal
people. :)

First, I hate ::Simple.  On any module.  If the interface was so
complicated that it needed a simple thing that doesn't describe how
it's simpler, then the designer failed.

So let's look at the problem:

Every hit requires four steps, not three.  There's a bit of a misdesign,
which is affecting the proper refactoring:

1) map incoming to state
2) map state to a respond class
3) invoke responder, getting render class
4) invoke renderer

Right now CGIP-dispatch does the first two.  The difference between
Hidden Fields and Pathinfo is only in step 1 though.

So, I propose a refactoring of CGIP so that CGIP-dispatch calls
CGIP-get_state, taking the results of that to call CGIP-get_class,
which then is returned as the result of CGIP-dispatch.  This keeps
the top-level unchanged, and permits backward compatibility.

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

And release those parts all as separate distros, although maybe just
bundled initially.  The current CGI::Prototype::Hidden would then
be backward compatible, again.

The mixins would be added individually as:

package My::App;
use base CGI::Prototype;
__PACKAGE__-reflect-addSlots(
   '*' = 'CGI::Prototype::State::Hidden',
   '*' = 'CGI::Prototype::Mapper::Prefix',
   '*' = 'CGI::Prototype::Render::TTWrapper',
);

## other subs for My::App;

1;

And in fact, the current CGI::Prototype::Hidden would be a pm with
just this in it, to be backward compatible.

Other mixins:

  CGI::Prototype::State::Pathinfo (yours)
  CGI::Prototype::Mapper::StrictLookup (yours)
  CGI::Prototype::Render::HTMLTemplate::* (for people that prefer H::T)

I'm not attached to the ::Mapper::* name.  Just making these up as I go.

How does this grab ya?

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


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

2005-08-15 Thread Randal L. Schwartz
 A == A Pagaltzis [EMAIL PROTECTED] writes:

A Looks sensible enough, but the mapper must be more abstract than
A you propose. Abstraction on the level you have in mind is not
A tenable because ::State::Pathinfo needs knowledge from
A ::Mapper::StrictLookup to be able to tell that

A /edit/user/ap

A is supposed to mean

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

A rather than

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

A or

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

Ewww.  I'd never use code like that.  But if you want to do it,
I suppose you can replace all of -dispatch isntead.

A How would a generic protocol for ::State::* to ask ::Mapper::*
A for possible states look? Is it sensible to define one?
A ::Mapper::Prefix would have to crawl @INC or something like that,
A f.ex.

Yeah, hadn't envisioned that.  In my mind, state should come entirely
from the incoming environment.  Mapping that to a class should be a
separate responsibility for maximum pluggability.  Looks like the
best way is to leave -dispatch and call yours something like

CGIP::Dispatch::VariablePathinfo

or something like that, using ::Dispatch:: rather than ::State:: or
::Mapping:: to show that it's replacing both.

A After all is said and done, ::State::Pathinfo will have to be
A specific to ::Mapper::StrictLookup anyway, so that separation
A makes no sense. The only thing that does make sense to abstract
A is how a state is mapped to a class *after* it is fully looked up
A and validated.

A But that is so trivial a task that I don’t really see the point
A in a separate ::Mapper::* hierarchy. Putting a -get_class with a
A default `eval require ${prefix}::${state}` implementation into
A CGIP would suffice.

I'm presuming the default -get_class simply returns the prefixed
string classname, which is presumedly defined using some other means
(like all in one file).  The autoload override allows it to be
dynloaded if it doesn't exist, but there are CGIP instances where that
won't be necessary, and I'm trying to keep the core CGIP as lean as
possible.

Consider also something like Slashdot, where the templates are loaded
from a database... I can also see that here.  Maybe state-to-class is
dynamic based on current user ID or other security parameter?  Really,
there's policy there, and it's best to let that be plugged in.

But if you need to poke around in order to even know the state, you've
got a tight coupling there, so you're going to be overriding all of
-dispatch, it seems.

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


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

2005-08-15 Thread Randal L. Schwartz
 Randal == Randal L Schwartz merlyn@stonehenge.com writes:

Randal Consider also something like Slashdot, where the templates are loaded
Randal from a database... I can also see that here.  Maybe state-to-class is
Randal dynamic based on current user ID or other security parameter?  Really,
Randal there's policy there, and it's best to let that be plugged in.

To further this, let's say I had a $big_client that needs to show a
login page if the user isn't logged in, regardless of whatever state
the -get_state returns.  They can override -get_class to simply
return the login page if not logged in, regardless of whatever state
it's asked to show, and yet the old state is preserved for a return
to FOO link.  And then the -get_state can be changed from hidden
fields to pathinfo without messing up the authorization section.

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


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

2005-08-15 Thread A. Pagaltzis
* Randal L. Schwartz merlyn@stonehenge.com [2005-08-15 19:50]:
 Ewww.  I'd never use code like that.

At the HTTP level, it is cleaner design. Nobody on the other side
of the app interface will care whether it requires uglier
scaffolding under the hood, nor should they. Thus, neither do I.

 Yeah, hadn't envisioned that.  In my mind, state should come
 entirely from the incoming environment.  Mapping that to a
 class should be a separate responsibility for maximum
 pluggability.  Looks like the best way is to leave -dispatch
 and call yours something like
 
CGIP::Dispatch::VariablePathinfo
 
 or something like that, using ::Dispatch:: rather than
 ::State:: or ::Mapping:: to show that it's replacing both.

I suppose that I’ll stick with the current monolithic design and
mind my own business for the time being, then. Since ::PathInfo
builds onto CGIP itself it should be unaffected by stuff that
gets added on top of that. I will see how it can be merged with
the future CGIP design that materializes.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;


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


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

2005-08-11 Thread A. Pagaltzis
* A. Pagaltzis [EMAIL PROTECTED] [2005-08-11 01:40]:
 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.

Ok, so I’d like to dive in there and get the bits moving right
now, but I don’t want to step on any toes, particularly with
architectural (more or less) decisions like this one. How are we
going to be handling issues like this one?

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;


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


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

2005-08-11 Thread Randal L. Schwartz
 A == A Pagaltzis [EMAIL PROTECTED] writes:

A Ok, so I’d like to dive in there and get the bits moving right
A now, but I don’t want to step on any toes, particularly with
A architectural (more or less) decisions like this one. How are we
A going to be handling issues like this one?

I've checked in the current releases to dist/* in the CVS.  If you
are proposing a separate release, feel free to start another leg.  If
you are thinking that the release currently called CGI-Prototype
should be altered, we can talk about making the changes directly
there.

Let's settle on the naming first... :)

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


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

2005-08-11 Thread A. Pagaltzis
* Randal L. Schwartz merlyn@stonehenge.com [2005-08-11 17:20]:
 If you are thinking that the release currently called
 CGI-Prototype should be altered, we can talk about making the
 changes directly there.

Well, kinda; I was hoping to start refactoring ::Hidden into bits
that can be reused in ::PathInfo and others and those which
can’t. ::PathInfo could then be separate or be part of the
distro, but that’s a different issue.

I’d like to know your thoughts on this; see my previous, more
detailed mail.

 Let's settle on the naming first... :)

We need to sort out the structure first; do you agree with my
assessment that the state-to-class mapper can be reused by state
deductors, but vice versa does not work so well?

I used ::Simple for the mapper in ::Hidden which ::PathInfo would
reuse, but I’m not wedded to that name at all.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/


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


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

2005-08-07 Thread Randal L. Schwartz
 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


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

2005-08-07 Thread Randal L. Schwartz
 A == A Pagaltzis [EMAIL PROTECTED] writes:

A I just don’t want to step on Randalls’s toes in case he’s already
A done this – but I also have very specific ideas about how to do
A this and a CPAN directory longing for something to put in it. :-)

And no, I have the idea to do it, but not the immediate motivation or
time. :( Glad to see someone else is finding the framework useful.

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


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

2005-08-03 Thread A. Pagaltzis
* Terrence Brannon [EMAIL PROTECTED] [2005-08-03 20:15]:
 If you put it on CPAN and it is based on hidden, then perhaps
 it should be CGI::Prototype::Hidden::PathInfo?
 
 I never could figure out Hidden, I use the vanilla
 CGI::Prototype for everything. 

Hmm, I found it extremely straightforward. Just read the code, in
the worst case, and you’ll understand how it works. It’s just a
minor collection of shortcuts that saves you from setting up the
same scaffolding over and over.

In any case, ::Hidden::PathInfo is not the right name. I don’t
inherit from ::Hidden and the code has nothing to do with any
state parameter.

I just don’t want to step on Randalls’s toes in case he’s already
done this – but I also have very specific ideas about how to do
this and a CPAN directory longing for something to put in it. :-)

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;


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


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

2005-08-03 Thread Terrence Brannon
A. Pagaltzis [EMAIL PROTECTED] writes:

 * Terrence Brannon [EMAIL PROTECTED] [2005-08-03 20:15]:
 If you put it on CPAN and it is based on hidden, then perhaps
 it should be CGI::Prototype::Hidden::PathInfo?
 
 I never could figure out Hidden, I use the vanilla
 CGI::Prototype for everything. 


 In any case, ::Hidden::PathInfo is not the right name. I don’t
 inherit from ::Hidden and the code has nothing to do with any
 state parameter.

good point.



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