Hi William, [...]
> That makes perfect sense, and the example code was helpful. > Setting the > status code in a case statement in the resource constructor leaves me > feeling like there's an opportunity for an additional > abstraction, but > it's perfectly workable for now, and I'll let you know if I > come up with > anything useful. I don't think John was suggesting setting the status code in the constructor but in the "getRepresentation(Variant)" method (or "represent(Variant)" method in Restlet 1.1). [...] > One solution is to return JSON or XML and do the rendering in > Javascript, but in a lot of cases that would leave me with duplicate > implementations of the same rendering, one client-side and one > server-side. That doesn't sit well with me. > > Another solution is to pass in some additional parameter in > the request, > which would work fine, but I feel like there's some > conceptual overlap > with the media type. My newbie understanding of the Restlet > approach is > that the media type is how you express what representation you'd like > from the resource. The mediatype is only one of the dimensions used for content negotiation in Restlet (and HTTP). Other dimensions are the character set, the encoding, the language or any application specific criteria. See the org.restlet.data.Dimension enumeration and the "Request.dimensions" property for additional details. For example, you could also discriminate based on the client's user agent (see "Request.clientInfo.agent" property). > But there doesn't seem to be a defined media type for HTML > fragment. I'm > glad to make one up, but given that you folks have been doing > this for a > while, I figure I might be missing something. Indeed, defining new mediatype is a perfectly acceptable solution as well. Your clients can also specify their preference using the "Accept" header. You resource logic could generate the representations using the same template (see FreeMarker and Velocity extension) with an parameter indicating which fragments should actually be inlined. Best regards, Jerome
