John Nilsson wrote:
> On Sun, Nov 9, 2008 at 2:27 PM, David Pollak <[EMAIL PROTECTED] 
> <mailto:[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.
And that is exactly what happens.  The content types are declared as 
pattern matching.
>
>
>     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. 
>  
>
>       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.
>  
>
>
>     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.


>
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to