Thanks for the thoughtful reply, John. It was very helpful. One
follow-up question:
John D. Mitchell wrote:
One way to do this is to use different representations for the
different types of clients. I.e., support the usual (x)html for the
"human" web interface and a pure xml (or the current hype-child...
json) for the programmatic clients.
Then in your resource classes, check the media type requested and
bundle up the different content and responses based thereon.
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.
My question is whether folks use a different media type for HTML fragments.
For a web browser, when somebody looks at a resource I want to render a
whole page, with navigation and whatnot. However, if I'm fetching the
same resource from an Ajax call, I may just want the HTML snippet that
represents the actual object, so that I can pop it into an existing page
structure.
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.
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.
Thanks,
William
--
William Pietri - [EMAIL PROTECTED] - +1-415-643-1024
Agile consulting, coaching, and development: http://www.scissor.com/
Use your geek-fu to fight poverty: http://www.mifos.org/
