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

[A. Pagaltzis]

* Terrence Brannon <[EMAIL PROTECTED]> [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 // 


---
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] each page is really an operation

[Terrence Brannon]

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

> * Terrence Brannon <[EMAIL PROTECTED]> [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:

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.


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





---
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] each page is really an operation

[Randal L. Schwartz]

> "Terrence" == Terrence Brannon <[EMAIL PROTECTED]> 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
 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] each page is really an operation

[A. Pagaltzis]

* Terrence Brannon <[EMAIL PROTECTED]> [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;


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

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

[Terrence Brannon]

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.



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