There was a reason for the [-1]. T3 (not t2) is a wysiwyg wiki that works on gae and allows you to embed {{=t2....}} tags in the pages. The pages are then saved in the datastore. In tis case there is a single action and args[0:-1] are used to identify the page. args[-1:] are used by the embedded components.
I am no saying this is the best way. Just explaining my reasoning. Massimo On Oct 24, 1:17 pm, billf <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---