cgi-prototype-users — the general mailing list for CGI::Prototype

Re: [cgi-prototype-users] each page is really an operation

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

* Terrence Brannon <ba...@me...> [2005-09-03 19:15]:
> A user requests *operations* - login, add user, view user which
> are materialized by model actions and feedback on success
> failure via the view/page. 

I model my applications as a set of resources, à la REST.

A GET request for `/user/12` brings up that user’s data. A POST
to the same resource will change his record. To receive the form
for editing a user record, you `GET /user/12?view=edit`. POSTing
to `/user/new` creates a new user resource, say `/user/42`, and
responds with a 302 redirect to that resource. (Actually, POSTing
always results in a 302, in order to make the browser’s back
button work and prevent accidental re-posts; but creating new
user resources would be a special case anyway.) Resources,
obviously, are only created or updated assuming credentials with
sufficient permissions; otherwise, the result is a 401 when not
logged in or a 403 when logged in, but lacking permission.

Etc.

This is the way HTTP was designed to work.

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

Re: [cgi-prototype-users] content-type and content: do they deserve separation / methods

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

* Terrence Brannon <ba...@me...> [2005-09-03 19:10]:
> This being the case, should these two aspects of the CGI
> response be two different methods, with $self->content_type
> existing in a base class and re-used for most of the app and
> $self->content (which is known as $self->render) be variant on
> each page?

That used to bug me until I started using CGI::Prototype::Hidden,
where the WRAPPER template takes care of this adequately. The
variables are all shared between the main template and the
wrapper, which includes `self`, so you just can do something like

    Content-type: [% self.content_type %]

at the top of the wrapper and have a `content_type` method which
sets the default in your application class, and then change it
for pages which deliver a different type of content.

I found responsibilities are actually separated more cleanly this
way.

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

[cgi-prototype-users] each page is really an operation

[Terrence B. <ba...@me...>]

While I'm having my philosophical catharsis, I thought I would mention
that CGI::Prototype is actually not a page-based approach to site
development. It is an operation-based approach. An operation consists
of several phases which are broken down by CGIP nicely. We have model
phases and view phases. The view phases create a page based on the
requested *operation*.

A user requests *operations* - login, add user, view user which are
materialized by model actions and feedback on success failure via the
view/page. 

If you take a look at Zanas:

  http://search.cpan.org/~dmow/Zanas-5.5.16/Zanas.pm

he says a similar thing.

-- 
	Carter's Compass: I know I'm on the right track when,
	   by deleting something, I'm adding functionality.

[cgi-prototype-users] content-type and content: do they deserve separation / methods

[Terrence B. <ba...@me...>]

CGI::Prototype is remarkably flexible, scaleable and practical. That
being the case, this is more of a philsophical question than any.

However, it is a fact that for most websites, the content-type will be
text/html for most of the pages and that the actual content will vary
on each page.

This being the case, should these two aspects of the CGI response be
two different methods, with $self->content_type existing in a base
class and re-used for most of the app and $self->content (which is
known as $self->render) be variant on each page?


-- 
	Carter's Compass: I know I'm on the right track when,
	   by deleting something, I'm adding functionality.

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

[<me...@st...>]

>>>>> "A" =3D=3D A Pagaltzis <pag...@gm...> writes:

A> PS.: merlyn, your mailer is misconfigured. It=E2=80=99s sending UTF-8,
A> but the headers claim it=E2=80=99s UTF-16BE. The end result is that your
A> mail literally looked like a bunch of chinese. I was surprised
A> for a moment=E2=80=A6

I've been having trouble for the past 24 hours with my existing emacs
session with regard to email.  I have rebooted emacs... let's see if
this helps.

I run "screen emacs", connecting to the same emacs session for up to
four or five months at a time.

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

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

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

* Terrence Brannon <ba...@me...> [2005-09-03 01:40]:
> "A. Pagaltzis" <pag...@gm...> writes:
> 
> > PS.: merlyn, your mailer is misconfigured. It’s
> > sending UTF-8,
> 
> Aristotle, what sort of control characters are in your mail?

There aren’t any control characters. It’s perfectly good
plaintext in UTF-8 encoding.

> I see little boxes and hex characters every so often, making
> the messages harder to read... I read mail with plain text
> Xemacs/Gnus under Debian.

I read and write mine on the console using mutt and vim.

I also know for a fact that Gnus can handle UTF-8.

That means your mailer is also misconfigured…

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

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

[Terrence B. <ba...@me...>]

"A. Pagaltzis" <pag...@gm...> writes:

> PS.: merlyn, your mailer is misconfigured. It’s sending UTF-8,

Aristotle, what sort of control characters are in your mail? I see
little boxes and hex characters every so often, making the messages
harder to read... I read mail with plain text Xemacs/Gnus under Debian.

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

[Ryan T. <li...@ry...>]

On 9/2/05, A. Pagaltzis <pag...@gm...> wrote:
> The end result is that your
> mail literally looked like a bunch of chinese.=20

I could not read it either, on gmail.

RT

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

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

* Randal L. Schwartz <me...@st...> [2005-09-02 17:40]:
> And especially if you could organize it something along the
> line of my proposal, or explain to me what isn't good about
> that. No discussion on that after my pitch. :(

I just don’t currently see a way to cleanly implement the design
I want using that approach, so I’ve fallen back to my usual
stance that solving the problem a couple of times over and then
extracting abstractions from code is better than designing in the
abstract.

Of course I haven’t helped that along either, since I haven’t put
my code anywhere yet…


PS.: merlyn, your mailer is misconfigured. It’s sending UTF-8,
but the headers claim it’s UTF-16BE. The end result is that your
mail literally looked like a bunch of chinese. I was surprised
for a moment…

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

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

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

* Terrence Brannon <ba...@me...> [2005-09-02 16:20]:
> Can you make the PathInfo stuff you are doing available on
> sourceforge or elsewhere?

Yes, I shall, though it might take me a few days.

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

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

[<me...@st...>]

㸾㸾㸠≔敲牥湣攢‽㍄㴳䐠呥牲敮捥⁂牡湮潮‼扡畨慵獀浥瑡灥牬⹣潭㸠睲楴敳㨊੔敲牥湣放•䄮⁐慧慬瑺楳∠㱰慧慬瑺楳䁧浸⹤放⁷物瑥猺ਾ㸠䤠獵灰潳攠瑨慴⁉㵆䔽䙆㴰〽䔲㴰〽㠰㴰〽㤹汬⁳瑩捫⁷楴栠瑨攠捵牲敮琠浯湯汩㴊瑨楣⁤敳楧渠慮搊㸾楮搠浹睮⁢畳楮敳猠景爠瑨攠瑩浥⁢敩湧Ⱐ瑨敮⸊੔敲牥湣放⁉❭⁡汳漠楮敥搠潦⁵獩湧⁐慴桉湦漠瑯⁲敮摥爠灡来猠潮⁡⁤祮慭楣੔敲牥湣放⁳楴攮⁃慮⁹潵慫攠瑨攠偡瑨䥮景⁳瑵晦⁹潵⁡牥⁤潩湧⁡癡楬慢汥渊呥牲敮捥㸠獯畲捥景牧攠潲⁥汳敷桥牥㼊ੁ湤⁥獰散楡汬礠楦⁹潵⁣潵汤牧慮楺攠楴⁳潭整桩湧⁡汯湧⁴桥楮攠潦礊灲潰潳慬Ⱐ潲⁥硰污楮⁴漠浥⁷桡琠楳渧琠杯潤⁡扯畴⁴桡琮†乯⁤楳捵獳楯渊潮⁴桡琠慦瑥爠浹⁰楴捨⸠㨨ਊⴭ㴲《剡湤慬⁌⸠卣桷慲瑺‭⁓瑯湥桥湧攠䍯湳畬瑩湧⁓敲癩捥猬⁉湣⸠ⴠ⬱‵〳‷㜷‰〹㔊㱭敲汹湀獴潮敨敮来⹣潭㸠㱕剌㩨瑴瀺⼯睷眮獴潮敨敮来⹣潭⽭敲汹港㸊健牬⽕湩砯獥捵物瑹⁣潮獵汴楮本⁔散桮楣慬⁷物瑩湧Ⱐ䍯浥摹Ⱐ整挮⁥瑣⸊卥攠健牬呲慩湩湧⹓瑯湥桥湧攮捯洠景爠潮獩瑥⁡湤灥渭敮牯汬浥湴⁐敲氠瑲慩湩渽੧ℊਊ

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

[Terrence B. <ba...@me...>]

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

[cgi-prototype-users] dispatch and rendering with HTML::Seamstress under CGIP

[Terrence B. <ba...@me...>]

This is more of an FYI post than anything. I've had the website
http://www.gimblerus.com under the control of CGIP for about 6-8
months now and it is great. This note explains the things I do because
(a) I don't under CGIP::Hidden and (b) because I use HTML::Seamstress
    instead of tt as my rendering engine.

First, let's look at a finished page:

  http://www.gimblerus.com/cgi-bin/x?task=show_rules

Ok, the first thing is notice the query parameter "task" with value
"show_rules"? That allows the CGIP script named "x" to figure out what
page we are on via module called Gimble::Dispatch. Gimble::Dispatch is
just a hash from this query parameter to a Gimble::Page::* class.

Re: [cgi-prototype-users] Re: changing page with respond

[<me...@st...>]

>>>>> "Carl" == Carl Franks <fir...@gm...> writes:

Carl> Ok, I've figured out what was going wrong and how to fix it, however
Carl> it's brought up another issue.

Carl> Firstly, my apologies that the code I posted didn't run - it was
Carl> copy-typed from one machine to another.
Carl> The line:
Carl> my $t = CGI::Prototype::Mech->new( protoapp => "One" );
Carl> should have read:
Carl> my $t = CGI::Prototype::Mecha->new( protoapp => "One" );

The problem here is probably one of documentation.  Your protoapp
doesn't exist, that's why it's broken.  It's not One, because Two
doesn't inherit from One.

You need your app, from which your pages inherit.  Then the
display method gets added into the right place.

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

[cgi-prototype-users] Re: changing page with respond

[Carl F. <fir...@gm...>]

Ok, I've figured out what was going wrong and how to fix it, however
it's brought up another issue.

Firstly, my apologies that the code I posted didn't run - it was
copy-typed from one machine to another.
The line:
my $t =3D CGI::Prototype::Mech->new( protoapp =3D> "One" );
should have read:
my $t =3D CGI::Prototype::Mecha->new( protoapp =3D> "One" );


The problem was caused, because CGI::Prototype does:

our $_mirror =3D __PACKAGE__->reflect;

$_mirror->addSlot
  (CGI =3D> sub { die shift, "->initialize_CGI not called" });

which adds the dummy CGI slot to the CGI::Prototype __PACKAGE__,
but then the initialize_CGI method adds the real CGI slot to $self,
which is the package 'One'...

sub initialize_CGI {
  my $self =3D shift;
  $self->reflect->addSlot
    ([qw(CGI FIELD autoload)] =3D> sub {
       require CGI;
       CGI::_reset_globals();
       CGI->new;
     });
}

When control passes to $next_page, which is package 'Two', it
inherit's CGI::Prototype's dummy CGI slot, but not the 'real' CGI slot
which is in 'One'.

The solution to that is to change the line in CGI::Prototype's
initialize_CGI from:
$self->reflect->addSlot
to:
$_mirror->addSlot

When this is done, the application works correctly.

However, my test file still does not pass... this is because in
CGI::Prototype::Mecha's 'new' method, it overrides the 'display' slot
for package 'One' (the protoapp that is passed).
When control passes to 'Two', it doesn't have the overridden 'display'
method, and so uses it's inherited 'display' from CGI::Prototype,
which prints to STDOUT.

Does anyone have any thoughts on how to deal with this?
Though, I admit to not being /too/ concerned about it, because my test
suite uses WWW::Mechanize through a real webserver.

I will post my suggested change to the initialize_CGI method to rt.

Cheers,
Carl

[cgi-prototype-users] changing page with respond

[Carl F. <fir...@gm...>]

I find that if I try to change the current page, by returning a
different value from 'respond', it dies with  "initialize_CGI not
called".
I think this is because when the new page's package is required, it
reruns the code in CGI/Prototype.pm which add's the 'dummy' CGI slot
which dies with that exact error message.

(I thought that a module's body was only run once, for the first 'use'
or 'require', but  I can't see any other explanation for what's
happening).

Am I doing this correctly?
Should I file a bug report on rt?

(Sample code below).

Cheers,
Carl


# file One.pm
package One;
use warnings;
use strict;
use base 'CGI::Prototype';

sub respond {
  require Two;
  return 'Two';
}

1;

# file Two.pm
package Two;
use warnings;
use strict;
use base 'CGI::Prototype';

sub template {
  return \'[% self.CGI.header %]Two';
}

1;

# file test.t
#!/usr/bin/perl
use strict;
use warnings;
use CGI::Prototype::Mecha;
use Test::More tests =3D> 2;
use Data::Dumper;
use lib '.';

my $t =3D CGI::Prototype::Mech->new( protoapp =3D> 'One' );

$t->get( 'http://mecha/' );

ok $t->success;
ok $t->res =3D~ 'Two';

print STDERR Dumper $t->res;

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

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

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

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

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

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

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

[<me...@st...>]

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

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

[<me...@st...>]

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

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

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

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

Re: [cgi-prototype-users] Using multiple base classes for an app

[<me...@st...>]

>>>>> "Andrew" == Andrew Gianni <ag...@bu...> writes:

Andrew> I'd like to be able to do something like this:

Andrew> sub config_class_prefix{
Andrew>     return qw( Project1::App Project2::App );
Andrew> }

Andrew> Then I could call name_to_page or shortname on pages from
Andrew> either project.  Does this sound like a good idea, or can you
Andrew> suggest a better way to share pages and functionality between
Andrew> applications?

This would be handled with a local-policy ::Mapper::*, as I just described
in my previous message.

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

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

[<me...@st...>]

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

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

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

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

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

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

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