Massimo
If you read the last comments before the code under "The
implementation", I detail 3 patches to T2 code:
* in T2.__init__, use the first numeric request.arg as the id as
opposed to request.arg[-1]):
* copy requires_login, rename as authenticate and modify to allow
calling inline
* enable next function to be a list by modifying update() to not
override "None" with "[id]"
If delete() is changed to output read-only details with a "Delete"
button that would a fourth patch.
On Oct 24, 7:00 pm, mdipierro <[EMAIL PROTECTED]> wrote:
> What is authenticate()? Did you use a modified version of the plugin?
>
> Massimo
>
> On Oct 24, 12:11 pm, billf <[EMAIL PROTECTED]> wrote:
>
> > I have posted an alternative example based on the last couple of posts
> > which is, I think, an improvement. It can be found
> > at:http://www.wellbehavedsystems.co.uk/web2py/examples/rest_alt1.html
>
> > It is fully working (so far) with the exception of:
> > - it doesn't yet generate a read-only details page prior to a delete
> > (but the update form delete checkbox works)
> > - a cosmetic issue: lists are labelled 'resource' as opposed to the
> > table name
>
> > On Oct 24, 1:40 am, billf <[EMAIL PROTECTED]> wrote:
>
> > > Voltron
>
> > > I have read through the threads you referenced again and I think I can
> > > see where you are coming from.
>
> > > I think that part of the problem is that examples of REST rarely seem
> > > to include the parts of the user interaction where the user requests
> > > an HTML form to be used to create/update/delete. The examples seem to
> > > assume knowledge at the client end that would enable a PUT, POST or
> > > DELETE to be generated without any prior GET. I can see how this is
> > > possible but this is not generally the case with HTML interactions,
> > > hence the need to encode additional information in the GET to
> > > differentiate between:
> > > - return a list and return a create form
> > > - return a read-only version and return an edit form (with an option
> > > to delete?)
>
> > > Taking the list vs create case, which of the following forms of GET
> > > would you prefer to see (assuming .../default/locations returns a
> > > list):
> > > - ...default/locations/create
> > > - ...default/locations?form=create
> > > - ...default/createlocationform
>
> > > It would be a shame if you selected the last one :-) as I think that
> > > all the "locations" requests going through the same controller/action
> > > has a certain elegance. Whichever you select, I assume that "search"
> > > would be handled similarly.
>
> > > Taking the read-only vs update/delete case, which of the following
> > > forms of GET would you prefer to see (assuming .../default/locations/1
> > > returns a read-only version, i.e. not a form):
> > > - ...default/locations/1/update
> > > - ...default/locations/1?form=update
> > > - ...default/updatelocationform?id=1
>
> > > As for the "POST" or send part of the interaction, you suggest
> > > overloading POST via a CGI parameter (after the ?). This seems
> > > equivalent to overloading via a URI element (?_rest_method=DELETE
> > > versus /delete) but I think a parameter is better as it leaves a
> > > cleaner URI. The only downside is a lack of symmetry between the GET
> > > and POST for create and update but I don't think that is significant.
> > > The revision would mean that the POST for create and update would look
> > > like:
> > > ...default/lookups?_rest_method=PUT&etc
>
> > > ...and the action determined by the id parameter (present and non-zero
> > > for an update, absent or non-zero for a create).
>
> > > Depending upon your responses, I would be happy to write up an
> > > alternative example to enable people to compare.
>
> > > What do you think?
>
> > > On Oct 23, 6:07 pm, billf <[EMAIL PROTECTED]> wrote:
>
> > > > Voltron
>
> > > > As I say, REST is new to me, but I believe the practical problem is
> > > > the lack of true REST clients. Most of us have to make do with HTML
> > > > forms from clients that only support GET and POST. If someone wants
> > > > to develop a real-world app using REST "style" URIs then I think
> > > > something like I propose would be necessary.
>
> > > > To cater for true REST clients, it would seem easy enough (from your
> > > > links) to handle both. For example, (pseudo-code) if (http-
> > > > method==DELETE) or (http-method==POST and request.arg[-1]==delete) do
> > > > delete().
>
> > > > Whether checks are performed as decorators or inline ifs seems beside
> > > > the point.
>
> > > > On Oct 23, 5:40 pm, voltron <[EMAIL PROTECTED]> wrote:
>
> > > > > I am not sure if your proposal would work with RESTful clients
> > > > > because you are not using the HTTP protocol to differentiate the
> > > > > actions taken.
>
> > > > > What about using decorators?
>
> > > > >http://pylonshq.com/docs/0.9/module-pylons.decorators.rest.html
>
> > > > > Or a workaround as Massimo suggested once
>
> > > > >http://groups.google.com/group/web2py/browse_thread/thread/8506105246...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
