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

[cgi-prototype-users] a fascinating little bug "Bad header=" bug from Apache

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

I added a little more functionality to my guestbook to have it tar up
the whole site and send it. For some reason, I kept getting this error
in the Apache log

[Sat Sep 10 15:00:05 2005] [error] [client 24.130.176.67] malformed
header from script. Bad header=metaperl.org/:
/var/www/terry/metaperl.org/cgi-bin/Guestbook.cgi

and I googled and googled. At first I thought I need autoflush on but
that was not it. Then I looked at exactly when the error was occurring
and reazlied that it was right when I started to tar the file. 

What was happening was that tar was issuing output to STDOUT and
apache was trying to interpret it as an HTTP header!

So my fix would be to silence tar or redirect the system command
output elswhere or use Archive::Tar from CPAN.

What a great way to spend 1.5 hours on a Sunday morn...

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

[cgi-prototype-users] Re: $this_page and $next_page lack access to $self...

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

Totally bogus bug report. Ignore. I don't know how I futzed up
CGIP::PathInfo so bad as to wreck the 5-level inheritance chain, but
everything went away, when I replaced my hackery with Aristotle's
original file.

> I have most of a guestbook program implemented using
> CGI::Prototype::PathInfo. You can play around with everything but the
> "view source for this page" button here:
>
>       http://www.metaperl.org/Guestbook
>
> I used Rose::DB::Object for the database stuff, HTML::Seamstress for
> "templating" and CGI::Protoytpe::Pathinfo as my controller.
>
> So anyway, when I got ready to do the "view source for this page", I
> needed access to resource_type for the current request but $this_page
> and $next_page (in CGPI::activate()) are not given these values from
> the self that starts activate().
>
> $this_page and $that_page also lack access to $self->CGI as a result.
>
> What this means is that I cannot rewrite the "View source for this
> page" to be $self->resource_type in this module:
>
>    http://www.metaperl.org/Guestbook/App/welcome.pm
>
> Of course, this is perplexing given that Guestbook::App::welcome
> inherits from Guestbook::App which inherits from
> CGI::Prototype::PathInfo and CGIP::PathInfo does reflect and add the
> resource->type slot and have a CGI slot with data from the initial
> resource->request.
>
> So, given that my render methods in $this_page or $next_page could
> take advantage of such a method, should there be some way of them
> being granted this info?
>
> -- 
> 	Carter's Compass: I know I'm on the right track when,
> 	   by deleting something, I'm adding functionality.
>
>
>
> -------------------------------------------------------
> 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

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

[cgi-prototype-users] please patch PathInfo with this

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

I am using this in my version of PathInfo. There could be some
refactoring to share code with name_to_page, but that's not done right
now.

=item name_to_pm

Called with a page name, translates it to a .pm file name, and returns it.

This module expects page names to look like relative URLs and will translate to
package names like you'd expect, ie assuming the default
C<config_class_prefix>, C<foo/bar> will translate to C<My/App/foo/bar.pm>.

=cut

sub name_to_pm {
  my $self = shift;
  my ( $name ) = @_;

		    my $pkg = join '::', (
		      $self->config_class_prefix,
		      split( m{/}, $self->validate_name( $name ) ),
		     );

  $pkg =~ s!::!/!g;

  "$pkg.pm";
}

[cgi-prototype-users] Guestbook app in Rose::DB, CGI::Prototype::PathInfo, and Seamstress

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

Since I could not beat Darren Duncan to first post, I had to beat him
to first complete app in Rose::DB::Object :). Other technologies were
Data::FormValidator, CGI::Prototype::PathInfo, and HTML::Seamstress.

I have implemented a cgi guestbook using Rose::DB::Object. Play with
it here:

  http://www.metaperl.org/Guestbook

You can look at the Rose-based code here:
  
   # db setup classes ...
   http://www.metaperl.org/Guestbook/DB.pm
   http://www.metaperl.org/Guestbook/Model.pm

   # The row-class for the entry table
   http://www.metaperl.org/Guestbook/Model/entry.pm

   # The Manager-class for the entry table
   http://www.metaperl.org/Guestbook/Model/entry/Manager.pm

   # A class which uses the row and manager to unroll a table
   http://www.metaperl.org/Guestbook/viewsrc/view
  
   # A class which uses the row and manager to count a rowset
   http://www.metaperl.org/Guestbook/viewsrc/stats

If you want to get the entire Guestbook app, then install darcs and
type:

  darcs get http://www.metaperl.org

The thing I enjoyed about using Rose is that Class::DBI
*requires* that you give the primary key column when creating row
objects. With Rose, I just left it out and it formulated the right
SQL. DBIx::SQLEngine tried to put a NULL for the primary key column
when I left it out and I could not supply either DEFAULT or
nextval('seq_name') to it without it munging it in someway that
DBD::Pg would not accept.

I built the database schema using the excellent Alzabo schema
editor. Here is the schema (all one table of it):

  http://www.metaperl.com/alzabo/schema/view_table.html?table=entry&schema=terry_guestbook


I'm sorry about how ugly the web app is: I'm reading my first book on
css and xhtml right now, so I expect that part to get prettier and
prettier the more I read :)

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

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

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

* Terrence Brannon <ba...@me...> [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;

[cgi-prototype-users] $this_page and $next_page lack access to $self...

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

I have most of a guestbook program implemented using
CGI::Prototype::PathInfo. You can play around with everything but the
"view source for this page" button here:

      http://www.metaperl.org/Guestbook

I used Rose::DB::Object for the database stuff, HTML::Seamstress for
"templating" and CGI::Protoytpe::Pathinfo as my controller.

So anyway, when I got ready to do the "view source for this page", I
needed access to resource_type for the current request but $this_page
and $next_page (in CGPI::activate()) are not given these values from
the self that starts activate().

$this_page and $that_page also lack access to $self->CGI as a result.

What this means is that I cannot rewrite the "View source for this
page" to be $self->resource_type in this module:

   http://www.metaperl.org/Guestbook/App/welcome.pm

Of course, this is perplexing given that Guestbook::App::welcome
inherits from Guestbook::App which inherits from
CGI::Prototype::PathInfo and CGIP::PathInfo does reflect and add the
resource->type slot and have a CGI slot with data from the initial
resource->request.

So, given that my render methods in $this_page or $next_page could
take advantage of such a method, should there be some way of them
being granted this info?

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

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

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

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

> * Terrence Brannon <ba...@me...> [2005-09-09 14:30]:
>> Thing is, can't a path have more than just 2 components? There
>> is no reason it can't have much more is there?
>
> Sure. You can include `'thread/post'` in your valid pages and
> invoke `forum.cgi/thread/post/283188/43`, in which case the
> object Forum::thread::post will be loaded with `resource_id`
> being `'283188/43'`.

I think the resource id should be a reference to an anonymous array
 [ 283188, 43 ]

Re: [cgi-prototype-users] REST architecture for a guestbook application

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

* Terrence Brannon <ba...@me...> [2005-09-05 14:15]:
> I have been trying to figure out how to model the resources of
> a guestbook cgi program using REST.

I think we’re getting rather far off topic for the list at this
point.

> GET /guestbook
>   returns the first 10 entries of the guestbook with links to
>   page forward to 11-20. REST supposedly works without cookies,
>   so if a user had a preference for entry listings per page,
>   what to do?

There’s no such thing as a “preference” between applications
talking to each other, which is what REST is mainly relevant to:
machine-oriented webservice APIs. Browser interfaces for humans
have different needs.

> POST /guestbook
>   adds an entry to the guestbook. But here is my problem, I
>   need a URL which returns a page that the user can fill in and
>   hit submit. What would such a URL look like?

In my book, `GET /guestbook?view=add`.

Regards,
-- 
Aristotle
“Like punning, programming is a play on words.”
   – Alan J. Perlis, “Epigrams in Programming”

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

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

* Terrence Brannon <ba...@me...> [2005-09-09 14:30]:
> Thing is, can't a path have more than just 2 components? There
> is no reason it can't have much more is there?

Sure. You can include `'thread/post'` in your valid pages and
invoke `forum.cgi/thread/post/283188/43`, in which case the
object Forum::thread::post will be loaded with `resource_id`
being `'283188/43'`. What’s your question?

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

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

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

From  Aristotle's CGIP::PathInfo, we have this:

sub prototype_enter {
	my $self = shift;

	$self->SUPER::prototype_enter();

	my ( $resource, $id ) = $self->parse_path( $self->CGI->path_info() );
	$self->reflect->addSlot( resource_type => $resource, resource_id => $id );
}

Thing is, can't a path have more than just 2 components? There is no
reason it can't have much more is there?

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

[cgi-prototype-users] require DBIx::SQLEngine::Criteria fails from CGI::Prototype::PathInfo

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

I have an issue with import and inheritance that I cannot figure
out. When a certain module of mine is loaded at runtime, it forces a
chain of requires through the DBIx::SQLEngine distribution, leading to
this error:

"new_group_from_values" is not exported by the
DBIx::SQLEngine::Criteria module
Can't continue after import errors at
/home/terry/perl/share/perl/5.8.7/DBIx/SQLEngine/RecordSet/Set.pm
line 318
BEGIN failed--compilation aborted at
/home/terry/perl/share/perl/5.8.7/DBIx/SQLEngine/RecordSet/Set.pm
line 318.
Compilation failed in require at
/home/terry/perl/share/perl/5.8.7/DBIx/SQLEngine/Record/Table.pm line
64.
Compilation failed in require at
/home/terry/perl/share/perl/5.8.7/Class/MixinFactory/Factory.pm line
55.
Compilation failed in require at
/var/www/terry/metaperl.org/Guestbook/App/sign_commit.pm line 7.
BEGIN failed--compilation aborted at
/var/www/terry/metaperl.org/Guestbook/App/sign_commit.pm line 7.
Compilation failed in require at
/var/www/terry/metaperl.org/Guestbook/App.pm line 17.
BEGIN failed--compilation aborted at
/var/www/terry/metaperl.org/Guestbook/App.pm line 17.
Compilation failed in require at Guestbook.cgi line 32.
BEGIN failed--compilation aborted at Guestbook.cgi line 32.
[Fri Sep  9 01:25:56 2005] [error] [client 24.130.176.67] Premature
end of script headers:
/var/www/terry/metaperl.org/cgi-bin/Guestbook.cgi


... and if you look at the file Criteria.pm you would not be surprised
to see this import error because no such sub exists in this file:

http://hcoop.net/~terry/perl/share/perl/5.8.7/DBIx/SQLEngine/Criteria.pm

However, I can run 2 separate static small scripts which emulate what
is happening during the above chain of failed requires and they all
work. 

First, a script which loads Guestbook::Model::entry (the module whose
require from Guestbook::App::sign_commit creates the error chain)
and does a commit to database... it does the commit perfectly.

entry.pl and entry.pm are here:

http://www.metaperl.org/Guestbook/Model/

In other words, even though it loads Guestbook::Model::entry, it does
not fail when loading the other modules in the DBIx::SQLEngine
distribution. 

Now, the last thing that happens before the "not exported" error is
that Record/Table.pm does a require  DBIx::SQLEngine::RecordSet::Set,
so I wrote a script which only does that and it runs just fine:

http://hcoop.net/~terry/perl/share/perl/5.8.7/DBIx/SQLEngine/RecordSet/Set.pl


So, the question becomes: why is it when CGI::Prototype::PathInfo does
a dynamic require of Guestbook::App::sign_commit and then
Guestbook::App::sign_commit does a use Guestbook::Model::entry that
the above chain of errors is thrown?

You can view PathInfo.pm here:

http://hcoop.net/~terry/perl/lib/CGI/Prototype/PathInfo.pm


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

[cgi-prototype-users] CGI::Prototype::PathInfo unified diff

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

Here is my unified diff of the attachment you emailed earlier. I like
this module a lot and will be retooling my simple guestbook app to use
it. This is our first step towards a CGI::Prototype on Rails type
thing. Maybe we could publish a Perl Review article if everything is
clean and easy to follow. 

I am going to play with DBIx::SQLEngine for the database part of this
based on a recent discussion between Simon and Sebastien about their
interests in it.

terry@Abulafia:~/perl/dl$ diff -u PathInfo.pm.orig PathInfo.pm
--- PathInfo.pm.orig	2005-09-05 11:34:56.000000000 +0000
+++ PathInfo.pm	2005-09-05 12:46:14.000000000 +0000
@@ -57,38 +57,73 @@
 
 =head2 ENVIRONMENT INFORMATION SLOTS
 
+These slots provide access to information about the request loosely modelled
+on the REST architectural elements described in sectoin 5.2 of Fielding's
+seminal Ph.D disseration on the subject:
+
+http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2
+
 =over 4
 
-=item resource_type
+=item resource_name
+
+The resource name is, to quote Fielding, "the intended conceptual target of 
+a hypertext reference." This would imply that such a target is a noun but in
+practical terms it may not be. In practical terms, the C<resource_name> is the
+first thing after the domain name and the cgi-script in the URL. Examples:
+
+http://metaperl.org/guestbook/sign has domain metaperl.org, cgi-script
+C<guestbook> and C<resource_name> sign
+Here we are providing a resource to sign the guestbook.
 
-FIXME
+=item resource_qualifiers
 
-=item resource_id
+path elements after the the resource name. Example:
 
-FIXME
+http://www.livingcosmos.org/meditation/ernest-wood/notes/
+
+would bind @resource_qualifiers to qw(ernest-wood notes)
+and of course resource_name would be 'meditation'
+
+This was initially a scalar named C<resource_id> but it is clear that many
+websites use more than one element after the resource_name, Drupal for 
+instance:
+http://sequence.complete.org/node/add/blog
 
 =back
 
+It is important to note that some resources just use paths to logically
+categorize all of its information. Taking the livingcosmos.org URL above, 
+meditation is not a "service" or "resource" as much as it is just an area on a 
+website. However, having access the path info is useful for dynamically 
+rendering the look-and-feel of a website without resorting to things like
+HTML::Mason and its autohandler.
+
 =cut
 
 sub prototype_enter {
-	my $self = shift;
+  my $self = shift;
 
-	$self->SUPER::prototype_enter();
+  $self->SUPER::prototype_enter();
 
-	my ( $resource, $id ) = $self->parse_path( $self->CGI->path_info() );
-	$self->reflect->addSlot( resource_type => $resource, resource_id => $id );
+  my ( $resource, @qual ) = $self->parse_path( $self->CGI->path_info() );
+  $self->reflect->addSlot( 
+    resource_name => $resource, 
+    resource_qual => \@qual 
+   );
 }
 
 =head2 MANAGEMENT SLOTS
 
-This is where the real changes over L<CGI::Prototype::Hidden> lie.
+This is where CGI::Prototype::PathInfo is quite different from 
+L<CGI::Prototype::Hidden>
 
 =over 4
 
-=item name_to_page
+=item resource_name_to_page
 
-Called with a page name, translates it to a package name, and returns a page
+Called with a resource name, translates it to a package name, and 
+returns a page
 object. Will also autoload the package.
 
 This module expects page names to look like relative URLs and will translate to
@@ -98,22 +133,23 @@
 =cut
 
 sub name_to_page {
-	my $self = shift;
-	my ( $name ) = @_;
+  my $self = shift;
+  my ( $name ) = @_;
 
-	my $pkg = join '::', (
-		$self->config_class_prefix,
-		split( m{/}, $self->validate_name( $name ) ),
-	);
+  my $pkg = join '::', (
+    $self->config_class_prefix,
+    split( m{/}, $self->validate_name( $name ) ),
+   );
+
+  if ( do { no strict 'refs'; not defined ${ $pkg . '::' } } ) {
+    eval "require $pkg";
+    die $@ if $@;
+  }
 
-	if( do { no strict 'refs'; not defined ${ $pkg . '::' } } ) {
-		eval "require $pkg";
-		die $@ if $@;
-	}
-
-	return $pkg->reflect->object;
+  return $pkg->reflect->object;
 }
 
+
 =item dispatch
 
 Overridden from L<CGI::Prototype::Hidden>. Selects either the page named
@@ -127,7 +163,7 @@
 
 	my $prefixes = join '|', map quotemeta, $self->config_valid_pages;
 
-	return $self->name_to_page( $self->resource_type || $self->config_default_page );
+	return $self->name_to_page( $self->resource_name || $self->config_default_page );
 }
 
 =item render_enter
@@ -186,17 +222,38 @@
 
 L<CGI::Prototype::Hidden>, L<CGI::Prototype>, L<Template::Manual>
 
+=over 4
+
+=item Paul Prescod's REST resources
+
+L<http://www.prescod.net/rest/>
+
+=item the REST wiki
+
+L<http://rest.blueoxen.net/cgi-bin/wiki.pl?FrontPage>
+
+=item The REST discussion email list
+
+L<http://groups.yahoo.com/group/rest-discuss/>
+
+
+=back
+
+
+
 =head1 BUG REPORTS
 
-Please report any bugs or feature requests to
-L<mailto:bug...@rt...>, or through the web interface
-at L<http://rt.cpan.org/>. I will be notified, and then you'll automatically
-be notified of progress on your bug as I make changes.
+Please report any bugs or feature requests to the CGI::Prototype users mailing
+list on Sourceforge (L<http://cgi-prototype.sf.net)
+so that all 3 authors of the package (sourcemerlyn, apag, metaperl) can 
+be notified.
 
 =head1 AUTHOR
 
 Aristote Pagaltzis, L<mailto:pag...@gm...>
 
+contributions from Terrence Brannon and Randal Schwartz.
+
 =head1 COPYRIGHT AND LICENSE
 
 Copyright (C) 2005 by Aristotle Pagaltzis
terry@Abulafia:~/perl/dl$ 

[cgi-prototype-users] REST architecture for a guestbook application

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

I have been trying to figure out how to model the resources of a
guestbook cgi program using REST. My CGI program is named guestbook
and my domain name is metaperl.org

GET /guestbook
  returns the first 10 entries of the guestbook with links to page
  forward to 11-20. REST supposedly works without cookies, so if a
  user had a preference for entry listings per page, what to do?
GET /guestbook?o=xml
  returns the entire guestbook in XML format
POST /guestbook
  adds an entry to the guestbook. But here is my problem, I need a URL
  which returns a page that the user can fill in and hit submit. What
  would such a URL look like?
GET /guestbook/stats
  returns a page showing the stats on the guestbook.



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

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

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

* Terrence Brannon <ba...@me...> [2005-09-05 13:30]:
> What if you had to visit aristotle.perlmonks.org instead of
> simply visiting perlmonks.org and having it authenticate you
> based on a cookie? 

You are forgetting HTTP authentication. You’d visit (in common
URI syntax) http://user:pa...@ex.../. REST does not preclude
authentication with its expose-resources-as-URIs approach.

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

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

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

* Terrence Brannon <ba...@me...> [2005-09-05 13:15]:
> You are using a REST-inspired approach to web design, not pure
> REST:

Yes. I never claimed otherwise; part of the reason for this is
that I’m writing plain old user-operated web apps, not (yet)
machine-operated XML-based web services.

And since I use cookies purely for authentication (see merlyn’s
article on how to use them), it won’t be very hard to switch to
a cookie-less modus operandi.

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

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

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

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

> * Terrence Brannon <ba...@me...> [2005-09-04 03:15]:
>> To me, that means "no cookies". But your discussion of 401 and
>> 403 would imply such a mechanism for recognizing who made the
>> request?
>
> I do (still?) use cookies.

I think it is pragmatic that the first hit to a website be
cookie-based if possible.

What if you had to visit aristotle.perlmonks.org instead of simply
visiting perlmonks.org and having it authenticate you based on a
cookie? 

Nothing but cookie-based recognition will ever fly in the corporate
world for the first hit.

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

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

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

* Terrence Brannon <ba...@me...> [2005-09-05 13:05]:
> This is what Paul Prescod lists as Common Design Mistake #3
> when building a REST website:

I don’t expect clients to construct these URLs manually. Of
course they get there by following links from elsewhere on the
interface. The idea is to view URIs locations of a resource,
which can be manipulated by the appropriate HTTP verbs – as
opposed to viewing them as the name of a callable function.

See also:
http://www.intertwingly.net/blog/2005/03/09/Distributed-State-Machines

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

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

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

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

> * Terrence Brannon <ba...@me...> [2005-09-04 03:15]:
>> To me, that means "no cookies". But your discussion of 401 and
>> 403 would imply such a mechanism for recognizing who made the
>> request?
>
> I do (still?) use cookies.

You are using a REST-inspired approach to web design, not pure REST:

<quote src="http://www.prescod.net/rest/state_transition.html">

REST basically advises you choose between these two strategies: send
all of the state back and forth (in this case using GET and URIs) or
capture parts of the state as resources with URIs and transmit links
to that state back and forth. What REST advises against is state
without a URI name. COOKIES ARE AN EXAMPLE OF UN-REST-LIKE DATA. Cookes
are implicit, so third parties have no access to them and even the
client application will not typically have any way to know what
cookies were in effect when a particular message was created hours
ago. REST stands for REpresentational State Transfer - the constant
transfer of state (or references to state) back and forth as
representations are key to its design.

</quote>

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

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

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

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

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

This is what Paul Prescod lists as Common Design Mistake #3 when
building a REST website:

   http://www.prescod.net/rest/mistakes/

<quote>
  Do not depend on URI's internal structure. Some people think about
  REST design in terms of setting up a bunch of URIs. "I'll put
  purchase orders in /purchases and I'll give them all numbers like
  /purchases/12132 and customer records will be in /customers..."
  That can be a helpful way to think while you are whiteboarding and
  chatting, but should not be your final public interface to the
  service. According to Web Architectural principles, most URIs are
  opaque to client software most of the time. In other words, your
  public API should not depend on the structure of your URIs. Instead
  there would typically be a single XML file that points to the
  components of your service. Those components would have hyperlinks
  that point to other components and so forth. Then you can introduce
  people to your service with a single URI and you can distribute the
  actual components across computers and domains however you want.
  My rule of thumb is that clients only construct URIs when they are
  building queries (and thus using query strings). Those queries return
  references to objects with opaque URIs. 

</quote>

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

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

* Terrence Brannon <ba...@me...> [2005-09-04 20:25]:
> "A. Pagaltzis" <pag...@gm...> writes:
> > Yes, I shall, though it might take me a few days.
> 
> I really need this now, even if it's just a tarfile emailed to
> ba...@me.... 

Okay, the .pm is attached. I wanted to write a couple of tests,
but haven’t gotten to those (it’ll be a while before I get in the
habit of working by writing those first…), so this is offered at
your own risk. I’m also unsure about some of the design.

So I’d welcome any comments.

> Will your module work with plain CGI?

Of course – what else?

Regards,
-- 
Aristotle
“If you can’t laugh at yourself, you don’t take life seriously enough.”

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

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

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

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

I really need this now, even if it's just a tarfile emailed to
ba...@me.... 

Will your module work with plain CGI? I have avoided using REST
vocabulary in my URLs for something I'm working on because I don't
have your module:

	<li> <a href="/gb/x.cgi?task=sign_book">  Sign Guestbook  </a> </li>
	<li> <a href="/gb/x.cgi?task=view_book">  View Guestbook  </a> </li>
	<li> <a href="/gb/x.cgi?task=book_stats"> Guestbook Stats </a> </li>

I want to be jet-set like you and use paths:

	<li> <a href="/gb/x/sign">  Sign Guestbook  </a> </li>
	<li> <a href="/gb/x/view">  View Guestbook  </a> </li>
	<li> <a href="/gb/x/stats"> Guestbook Stats </a> </li>

So much cleaner


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

What a cute use of icons!

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

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

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

* Terrence Brannon <ba...@me...> [2005-09-04 03:15]:
> To me, that means "no cookies". But your discussion of 401 and
> 403 would imply such a mechanism for recognizing who made the
> request?

I do (still?) use cookies.

I’m still learning. :-) And several of my apps are already
modelled the “old” way. I’m rolling them over slowly.

Just two weeks or so ago I mentioned an URL `/edit/user/12` on
this list; now that is `/user/12?view=edit`, with the POST going
to `/user/12`.

I’ve found that following REST principles (even only partially)
has made the HTTP-side interface of my apps self-evident.
Previously, I guessed a lot. Now, the separations are obvious.
I like that.

401 vs 403 still holds, though – it would apply just the same if
I used HTTP authentication. (Ie no auth headers => 401, auth
headers for an account with insufficient permissions => 403.)

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

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

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

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

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

I googled for REST and found this:
   http://www.xfront.com/REST-Web-Services.html

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

Do you use cookies? The paper I read stated this:
<quote>
Stateless: each request from client to server must contain all the
information necessary to understand the request, and cannot take
advantage of any stored context on the server.
</quote>

To me, that means "no cookies". But your discussion of 401 and 403
would imply such a mechanism for recognizing who made the request?

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

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

>>>>> "Terrence" == Terrence Brannon <ba...@me...> writes:

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

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

Yeah, even though I call them "page objects" in my head, I'm really
thinking of "operations", selected by the dispatcher, with each operation
able to "stay here" to redo a step, or "go somewhere else" to continue
in the interaction.

-- 
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] content-type and content: do they deserve separation / methods

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

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

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

A>     Content-type: [% self.content_type %]

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

A> I found responsibilities are actually separated more cleanly this
A> way.

Correct.  Not knowing (really) what would happen when you say
->render, the best thing is to leave the content-type to the renderer,
and if you wanted to push some part of that back to controller
callbacks, the framework is definitely there.

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