On Sun, Nov 9, 2008 at 2:27 PM, David Pollak <[EMAIL PROTECTED]> wrote:
>
> Um... and how would you change it?
>
I would probably have the application code just declare content types for
various resource handlers and let the framwork figure out which resource
handler to use.
> On a broader note, pattern matching against the vagaries of the "accepts"
> header is far less clean than pattern matching against the suffix of a
> request.
>
If you mean pattern matching against the text of the request I agree. But
details of the request parsing should be handled by the framework, not the
application code. So the complexity of the implementation shouldn't affect
client code.
> I think Rails got it right in terms of using the suffix of the request
> and Lift follows Rails in this being the "easy path":
>
I think the semantics of PUT and DELETE are easier to to implement if the
URL actualy identifies the resource rather than its wire representation. If
I DELETE a ".js" URL, should the corresponging ".xml" URL also be deleted?
>
> case RequestState("api" :: "myservice" :: Nil, "js", GetReqeust) =>
>
> vs.
>
> case RequestState("api" :: "myservice" :: Nil, _, GetRequest) if
> acceptsJavaScript =>
>
I'm not saying it's wrong to base decisions on the URL. But the framework
probably shouldn't put to much semantics into the URL. It should let the
application do it, as per the example above though. For accept headers the
framework should have more freedom to provide an easi API.
BR,
John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" 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/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
