On Mon, Nov 10, 2008 at 4:52 AM, David Pollak <[EMAIL PROTECTED]> wrote:
> The content types are declared as pattern matching.
>
Are they are matched in the order of preference stated by the client based
on the q parameter?
>> 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.
>
> And that is exactly what happens. The pattern matching is against the
> parsed request. The framework does in fact handle the request parsing.
>
So what did you mean by "vagraries"?
>
>
> 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?
>
> Yes. There's nothing in this whole discussion about changing the semantic
> meaning of a given URL based on the the suffix. What is being discussed is
> how to format the response to a given request.
>
I was thinking in the context of the framework doing decisions. But if its
all application code my comment can be taken as just a general observation
of design consequences, referring to my earlier question wrt to why it was
desirable to have .js and .xml in the URL.
>
>
>
>>
>> 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.
>
> The framework *DOES NOT* put the semantics in the URL. This is *ALL* how a
> given application registers how to handle particular requests. This is
> *ALL* application level.
>
>From the example code I got the impression that the second parameter to
RequestState was exactly the suffix of the URL, separated by the framework
and presented as an API. The general consequence being that the framework
puts focus on the URL-suffix rather than the Accept header. Which I think
your example also ilustrates. Was it not your point to argue that the API
for handling the Accept header is harder to use?
BR,
John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
