On Mon, Dec 21, 2009 at 3:31 AM, Mike Burrows (asplake)
<[email protected]> wrote:
>
> I was intrigued by the mention of resource()
The Atom-REST syntax for resources is mainly beneficial to
non-interactive user agents (robots and front ends), and cases where
the resource is isolated from a "web site" (Amazon S3). But when the
resource is embedded in a visual web site, it goes against traditional
website usage. Traditionally the form and its action were at the same
URL, and POST was used for all actions. So GET displays the form, and
POST creates/updates/deletes the resource. RESTifarians call this
inferior and it has been drummed out of Routes and Pylons (although it
can be reconstructed manually). This led to the splitting of the
controller action from one method (for both display, validating, and
processing), to two (one for display, another for
validating/processing), and the @validate decorator which tries to
synchronize the two but is inadequate for edge cases (what if the
validator needs state such as the current record ID or database
record?).
I also notice that all the biggest social networking sites --
Facebook, MySpace, YouTube, etc -- totally violate REST at all levels,
with query string monstrosities that we would never use. Yet that has
not caused the sites to be unpopular or the owners' stock dividends to
fall.
Another thing is that map.resource has no delete confirmation form, so
I have to add one to every application. And it creates all routes
even if some are disallowed by application policy; e.g., creating
resources or deleting them. Perhaps the site insists that all
creation or deletion is done outside the web.
So I think there's room for a compromise, a kind of resource route
that's not Atom compatible but still has good URL structure, and a
one-method action. I don't have the exact specs on hand but it's
something like this:
def resource2(self, name, path, new=True, edit=True, delete=True):
GET /myresource : view index
GET /myresource/new : new form
POST /myresource/new : new action
GET /myresource/1 : view record 1
GET /myresource/1/edit : edit form
POST /myresource/1/edit : edit action
GET /myresource/1/delete : delete form
POST /myresource/1/delete : delete action
If the boolean args are false, routes for those actions would not be created.
I'd also like to see a resource route object in the routing table.
Currently map.resource creates a bunch of independent routes, which
don't have a group identity when introspected. But that's another
issue and longer term.
- coincidentally I was
> working on the post [1] below in which I refactor my way to a much
> more flexible alternative that builds on the new SubMapper idea. I'd
> be interested to know what people think.
>
> [1] DRY up your routes - a Pylons routing refactoring
> http://positiveincline.com/?p=561
Could you make Routes tickets for these? Then they'll be easier to
follow up on.
.submapper is documented now, but I'm not sure if readers can infer
all the cases you describe.
If not, it just needs some examples added
http://routes.groovie.org/manual.html (search for "submapper")
The new methods may be more radical than Routes wants to do, but
having it in tickets will make them easier to address. Or maybe you
already did; I see there's one ticket by you.
http://bitbucket.org/bbangert/routes/issue/21/add-submappersubmapper
--
Mike Orr <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
