Menu
▾
▴
cgi-prototype-users
|
From: A. P. <pag...@gm...> - 2005-08-03 03:01:30
|
Hi all,
and hi Randall in particular. I have a working version of this,
largely derived from ::Hidden for consistency in slot names. (It
also let me copy 95% of the POD verbatim. Writing documentation
is easy when it’s already done for you. *g*)
It has a somewhat distinct personality in that it wants an
explicit list of page names to validate (I’d rather prefer if
::Hidden worked the same way – I like my code hardwired for “no
surprises ever possible”) and works slightly differently in a few
minor aspects. But by and large a well-written ::Hidden app would
translate to a ::PathInfo one with almost no changes.
I’ve also added a little twist so that “foo.cgi/bar/42” will
dispatch to “My::App::bar” and set the “page_id” slot to 42 in
the process. (The slot defaults to undef.) This is very handy for
cruft-free, clean URLs.
I’ve pondered doing more extensive URL parsing than what I
currently have, based on the fact that the list of valid page
names is known; but I couldn’t think of good, simple conventions
for the meaning of the addition path segments, so I left it out
for the time being. I think the best course of action would be to
pass those to a slot so the user can define any behaviour they
desire, and leave the default implementation of that slot empty.
Now my question is: should I put this on CPAN, or should I leave
the space to an “official” version? Or should I just post it
here, maybe? If I put this on CPAN myself, what should I put in
the AUTHOR and COPYRIGHT & LICENSE sections of the POD? There is
so little code in there that the notion of authorship is a bit
ridiculous either way, but I also copied several pages of POD
that I can hardly claim authorship of.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
|
|
From: Terrence B. <ba...@me...> - 2005-08-03 18:05:10
|
"A. Pagaltzis" <pag...@gm...> writes: > I have a working version of this, > largely derived from ::Hidden for consistency in slot names. > Now my question is: should I put this on CPAN, or should I leave > the space to an âofficialâ version? 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. If the decision is to post at sf.net, just tell me what I need to do on the sourceforge site to set you up since I admin this list and sf.net site. |
|
From: A. P. <pag...@gm...> - 2005-08-03 18:46:38
|
* Terrence Brannon <ba...@me...> [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;
|
|
From: <me...@st...> - 2005-08-07 16:07:41
|
>>>>> "A" =3D=3D A Pagaltzis <pag...@gm...> writes: A> I just don=E2=80=99t want to step on Randalls=E2=80=99s toes in case he= =E2=80=99s already A> done this =E2=80=93 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. --=20 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <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 trainin= g! |
|
From: Terrence B. <ba...@me...> - 2005-08-03 19:47:43
|
"A. Pagaltzis" <pag...@gm...> writes: > * Terrence Brannon <ba...@me...> [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. |
|
From: <me...@st...> - 2005-08-07 16:07:09
|
>>>>> "A" =3D=3D A Pagaltzis <pag...@gm...> 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=E2=80=99s 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=E2=80=99d rather prefer if
A> ::Hidden worked the same way =E2=80=93 I like my code hardwired for =E2=
=80=9Cno
A> surprises ever possible=E2=80=9D) 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 clas=
s)
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=E2=80=99ve also added a little twist so that =E2=80=9Cfoo.cgi/bar/42=
=E2=80=9D will
A> dispatch to =E2=80=9CMy::App::bar=E2=80=9D and set the =E2=80=9Cpage_id=
=E2=80=9D 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 =E2=80=9Cofficial=E2=80=9D version? Or should I just pos=
t 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.
--=20
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <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 trainin=
g!
|
|
From: Terrence B. <ba...@me...> - 2005-08-07 21:22:22
|
me...@st... (Randal L. Schwartz) writes: >>>>>> "A" == A Pagaltzis <pag...@gm...> writes: > > 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: I have added Aristotle (sf.net id: apag) as a developer with plenty of liberal admin rights to the whole project - let me know if you need more. I couldn't find Randal Schwartz in the sf.net user list and someone has the name merlyn already. Right now, it looks like Aristotle needs the privs more than Randal, but as soon as I get his name, I will heap on lots of privs for him as well. Yes, as soon as this PathInfo baby gets uploaded, I can de-Mason-ize a site of mine with the greatest of ease :) -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. |
|
From: A. P. <pag...@gm...> - 2005-08-10 23:08:05
|
* Terrence Brannon <ba...@me...> [2005-08-07 23:30]: > I have added Aristotle (sf.net id: apag) as a developer with > plenty of liberal admin rights to the whole project – let me > know if you need more. Okay, I’ve gone in and put up a plain homepage cribbed together from the Randall’s and your POD, and corrected the project description (CGIP is not a template system and it does not use a database). Now back to the code… Regards, -- Aristotle “Like punning, programming is a play on words.” – Alan J. Perlis, “Epigrams in Programming” |
|
From: Terrence B. <ba...@me...> - 2005-08-11 02:42:11
|
"A. Pagaltzis" <pag...@gm...> writes: > * Terrence Brannon <ba...@me...> [2005-08-07 23:30]: >> I have added Aristotle (sf.net id: apag) as a developer with >> plenty of liberal admin rights to the whole project â let me >> know if you need more. > > Okay, Iâve gone in and put up a plain homepage Plain nothing! That's a very nice page. I use CGIP without Template Toolkit, so I dont like that part of the description. > cribbed together from the Randallâs and your POD, and corrected > the project description (CGIP is not a template system and it does > not use a database). OMG. I hope I didnt write something that off-base. -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. |
|
From: A. P. <pag...@gm...> - 2005-08-11 04:12:03
|
* Terrence Brannon <ba...@me...> [2005-08-11 04:50]: > Plain nothing! That's a very nice page. I use CGIP without > Template Toolkit, so I dont like that part of the description. Heh, thanks. And well, CGIP *does* integrate TT by default, after all. But I added a clause saying that TT is optional – that better? > > cribbed together from the Randallâs and your POD, and > > corrected the project description (CGIP is not a template > > system and it does not use a database). > > OMG. I hope I didnt write something that off-base. Write, not exactly, but it was categorized as templating system and said that it used Perl/DBI as database environment. (It’s true that one would likely use DBI for database apps written with CGIP, but CGIP itself has nothing to do with that.) I was kind of surprised to find those bits in the profile. Anyway, it’s fixed. Regards, -- Aristotle “If you can’t laugh at yourself, you don’t take life seriously enough.” |
|
From: <me...@st...> - 2005-08-11 06:26:53
|
>>>>> "A" =3D=3D A Pagaltzis <pag...@gm...> writes: A> Heh, thanks. And well, CGIP *does* integrate TT by default, after A> all. But I added a clause saying that TT is optional =D0 that A> better? My phrasing is "biased toward TT (Randal's favorite), but any templator can be chosen insteasd". --=20 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <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 trainin= g! |
|
From: A. P. <pag...@gm...> - 2005-08-11 06:45:46
|
* Randal L. Schwartz <me...@st...> [2005-08-11 08:35]:
> My phrasing is "biased toward TT (Randal's favorite), but any
> templator can be chosen insteasd".
Okay then; I twiddled it to closely match that phrasing.
Note that I’ve made the file group-writable, so whoever of you
guys wants to change something there can go right ahead.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
|
|
From: A. P. <pag...@gm...> - 2005-08-10 23:29:05
|
* 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” |
|
From: A. P. <pag...@gm...> - 2005-08-11 13:03:21
|
* A. Pagaltzis <pag...@gm...> [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;
|
|
From: <me...@st...> - 2005-08-11 15:03:52
|
>>>>> "A" =3D=3D A Pagaltzis <pag...@gm...> writes: A> Ok, so I=A2d like to dive in there and get the bits moving right A> now, but I don=A2t 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... :) --=20 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <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 trainin= g! |
|
From: A. P. <pag...@gm...> - 2005-08-11 15:31:37
|
* Randal L. Schwartz <me...@st...> [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/> |
|
From: A. P. <pag...@gm...> - 2005-08-15 12:43:01
|
Randal, * A. Pagaltzis <pag...@gm...> [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/> |
|
From: <me...@st...> - 2005-08-15 16:30:31
|
>>>>> "A" == A Pagaltzis <pag...@gm...> 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
<me...@st...> <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!
|
|
From: A. P. <pag...@gm...> - 2005-08-15 17:19:36
|
* Randal L. Schwartz <me...@st...> [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
/edit/user/ap
is supposed to mean
state => 'My::App::edit::user',
positional_param => ['ap'],
rather than
state => 'My::App::edit',
positional_param => ['user,'ap'],
or
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,
f.ex.
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.
Regards,
--
Aristotle
“Like punning, programming is a play on words.”
– Alan J. Perlis, “Epigrams in Programming”
|
|
From: <me...@st...> - 2005-08-15 17:43:48
|
>>>>> "A" =3D=3D A Pagaltzis <pag...@gm...> 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 =3D> 'My::App::edit::user',
A> positional_param =3D> ['ap'],
A> rather than
A> state =3D> 'My::App::edit',
A> positional_param =3D> ['user,'ap'],
A> or
A> state =3D> 'My::App::edit::user::ap',
A> positional_param =3D> [],
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=A2t 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.
--=20
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <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 trainin=
g!
|
|
From: <me...@st...> - 2005-08-15 17:51:29
|
>>>>> "Randal" == Randal L Schwartz <me...@st...> 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 <me...@st...> <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! |
|
From: A. P. <pag...@gm...> - 2005-08-15 18:36:13
|
* Randal L. Schwartz <me...@st...> [2005-08-15 20:00]:
> 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.
I currently do that by authenticating the user in ->app_enter.
The ->respond in pages which require authentication can then
switch to the login state for rendering a reponse. The login
state consists of nothing but a login form that includes all the
incoming state. So the user repeats the same request when he
submits the form, only this time with his credentials included.
->app_enter then picks them up, so the ->respond which previously
switched to the login state now finds the user authenticated, and
the request proceeds as it would have the first time around.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
|
|
From: A. P. <pag...@gm...> - 2005-08-15 18:19:30
|
* Randal L. Schwartz <me...@st...> [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;
|
|
From: Terrence B. <ba...@me...> - 2005-09-02 14:17:14
|
"A. Pagaltzis" <pag...@gm...> writes: > I suppose that Iâll stick with the current monolithic design and > mind my own business for the time being, then. I'm also in need of using PathInfo to render pages on a dynamic site. Can you make the PathInfo stuff you are doing available on sourceforge or elsewhere? -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. |
|
From: <me...@st...> - 2005-09-02 14:41:27
|
㸾㸾㸠≔敲牥湣攢‽㍄㴳䐠呥牲敮捥⁂牡湮潮‼扡畨慵獀浥瑡灥牬潭㸠睲楴敳㨊敲牥湣放•䄮⁐慧慬瑺楳∠㱰慧慬瑺楳䁧浸放⁷物瑥猺ਾ㸠䤠獵灰潳攠瑨慴⁉㵆䔽䙆㴰〽䔲㴰〽㠰㴰〽㤹汬瑩捫⁷楴栠瑨攠捵牲敮琠浯湯汩㴊瑨楣敳楧渠慮搊㸾楮搠浹睮畳楮敳猠景爠瑨攠瑩浥敩湧Ⱐ瑨敮⸊敲牥湣放⁉❭汳漠楮敥搠潦⁵獩湧⁐慴桉湦漠瑯敮摥爠灡来猠潮祮慭楣敲牥湣放楴攮⁃慮⁹潵慫攠瑨攠偡瑨䥮景瑵晦⁹潵牥潩湧癡楬慢汥渊呥牲敮捥㸠獯畲捥景牧攠潲汳敷桥牥㼊ੁ湤獰散楡汬礠楦⁹潵潵汤牧慮楺攠楴潭整桩湧汯湧⁴桥楮攠潦礊灲潰潳慬Ⱐ潲硰污楮⁴漠浥⁷桡琠楳渧琠杯潤扯畴⁴桡琮†乯楳捵獳楯渊潮⁴桡琠慦瑥爠浹⁰楴捨⸠㨨ਊⴭ㴲《剡湤慬⁌⸠卣桷慲瑺⁓瑯湥桥湧攠䍯湳畬瑩湧⁓敲癩捥猬⁉湣⸠ⴠ⬱‵〳‷㜷‰〹㔊㱭敲汹湀獴潮敨敮来潭㸠㱕剌㩨瑴瀺⼯睷眮獴潮敨敮来潭⽭敲汹港㸊健牬⽕湩砯獥捵物瑹潮獵汴楮本⁔散桮楣慬⁷物瑩湧Ⱐ䍯浥摹Ⱐ整挮瑣⸊卥攠健牬呲慩湩湧⹓瑯湥桥湧攮捯洠景爠潮獩瑥湤灥渭敮牯汬浥湴⁐敲氠瑲慩湩渽੧ℊਊ |
Thanks for helping keep SourceForge clean.
X