I was just looking at another post wondering why DOM is even used in
this type of arch. Seems that these two forms should be deprecated as
they don't follow the REST paradigm. I also started thinking that in my
post about using .getEntityAsObject(). Would all this be better to use a
cache system instead of adding it to Restlet? This is why I started
looking at the SAX implementation. No matter which way you do it, aren't
you adding a Servlet session?
Rob Heittman wrote:
(Changed subject line to reflect drift) Adam and I were discussing
this at our shop yesterday ...
One of the issues I have seen bite Restlet newbies is that Form is the
idiomatic path to access query string parameters and such, but
getEntityAsForm() consumes the request. If someone calls
getEntityAsForm() in, say, a Guard, to look for an authentication
token on the URI, a downstream Restlet trying to get the
representation will fail and this results in puzzlement.
Now, it is not good REST to mix a function call paradigm with
representational state transfer in the same call; while it is a common
Web practice to glue query string parameters onto an unrelated
representation as a signalling mechanism, this is not RESTful, and it
is probably good that the NRE discourages this. Notionally, a single
HTTP operation transacts a single representation, and that
representation should represent a single thing.
But I think it would be perfectly fine, however, if getEntityAsForm()
and getEntityAsDom() could be called repeatedly, and subsequent calls
against the same Entity would simply retrieve a reference to the Form
or DomRepresentation created in the prior call. This neither
encourages sloppy REST nor breaks scalability. The relevant in-memory
objects have already been created and will go away when the request
completes. While the underlying representation types (e.g.
StreamRepresentation or SaxRepresentation) are indeed transient, the
Form and DomRepresentation actually represent a completed in-memory
parse of the underlying transient representation ... and need not be
transient themselves.
So this would work:
Form form1 = request.getEntityAsForm();
String f1s = form1.getFirstValue("foo");
Form form2 = request.getEntityAsForm(); // just
returns another reference to form1
String f2s = form2.getFirstValue("foo"); // should not
throw an exception
While you might no longer be able to access the original entity or a
/different/ Representation after calling one of these methods, there's
no reason that a number of Restlets in the same chain, needing to
operate on a Form or DomRepresentation, actually need to implement
their own private caching mechanism. We already have some fairly long
chains of Restlets using components that are supposed to be pluggable
and interoperable; the less they have to be aware of each other the
better.
I haven't looked into a patch yet, but I can't imagine it would be
tragically complex.
Thoughts?
----- Original Message -----
From: "Thierry Boileau" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, August 28, 2007 2:59:36 AM (GMT-0500) America/New_York
Subject: Re: Custom gaurds
Hello Alan,
well, you're right, Jerome could have define Representations with some
caching system allowing to get content anytime we want. I think that
Jerome had made the design choice that :
- gives you the lighter and cheaper way to use transient
representations, when you read them once (which is a basic but
probably the most frequent case, I think)
- let you free to simply and transparently convert a transient
representation to a StringRepresentation (or any kind of self defined
representations) for example in case you want to read it several times
which means unavoidably that the content is "stored" in memory, in a
file, etc.
best regards,
Thierry Boileau
On 8/27/07, *Alan* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Thierry Boileau <thboileau <at> gmail.com <http://gmail.com>> writes:
>
> Hi,
>
> This "limitation" concerns the following representation classes (and
> descendants included in the Restlet API and NRE) :
>
Ok, for my clarification:
the "limitation" is due to the implementation of the NRE library,
not a limitation of the http model?
In theory, an implementation could do something like cache the
initial input
source to make subsequent calls to getEntityAsFoo work.
Is there a reason for this?
Looking at the source I saw that it is possibly due to the fact
data is read
off a stream of unknown length and caching request data may be
prohibitively
expensive?
By the time the server is processing the request is the client
pipe closed? (I guess I'm thinking about something like
continuations).
I'm just curious, I have no plans to offer another implementation :)
I suppose I'll need to rethink my implementation if I wish to make
restlets
behave in an filter/guard agnostic manner.
By the way, this is a nice paradigm, I much prefer it over servlets.
thanks.
--
Justin Stanczak
Stanczak Group
812-735-3600
"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
