I thought the same thing, but I haven't looked at the code. Is the Unfiltered request object recreated from Plan to Plan? If that's the case, then it would be tricky.
Dustin
On Mon, Mar 21, 2011 at 10:42 AM, chris_lewis [via Databinder] <[hidden email]> wrote: I may be missing something obvious - it's early and the weekend was long - but I don't see why that matters. The half-baked idea I had is essentially a transient Map[String, Any] on RequestBinding. It doesn't matter what the underlying server framework is, only that a request now carries with it this map. |
Administrator
|
I thought the same thing, but I haven't looked at the code. Is the Unfiltered request object recreated from Plan to Plan? It is; the binding is light enough that it shouldn't make a difference, and it's difficult to change this in a way that would work across different bindings. But it's worth investigating. If we were going to do that, we could make the binding function user-defined, so that apps could specify their own RequestBinding type including properties they want to set in it, so that it's more typesafe than a map. Nathan If that's the case, then it would be tricky. |
In reply to this post by chris_lewis
Oops, I should not have brought up the s-word. That was terminology from the Core J2EE Patterns text. Instead, I have no intention to introduce any sort of session state because I want my service to work with sessionless command-line clients.
What I really meant is putting some kind of application-specific Remote Façade on top of the less application-specific but still data-model-specific repository because I don't want to push this functionality into the repository itself. In response to your earlier message, @Chris, for now I have rewritten the resource behavior to interact with the repository as late and as few times as semantically possible. Keep in mind that this behavior and the underlying use case are taken straight from the Restlet implementation of the example in the Richardson & Ruby book. Now, as @n8han observed, for each request there are at most two (different) interactions with the repo: one for authentication (if required) and one for accessing or modifying something. Furthermore, I understand this example a use case against the usual container-managed authentication based solely on URL pattern and request method: Some of the behavior depends on whether the request already includes authentication, and some of it depends on whether a resource already exists (e.g. unauthenticated user creation versus authenticated user update). Scalability does seem to be an issue, and it might be nice somehow to separate out the authentication concern (I am avoiding the a-word here ![]() Btw, I am now using for-comprehensions almost everywhere. Exceptions are used only for real error situations such as a bad request.
|
In reply to this post by laufer
TOMS shoes are offered on auction on websites, food and so on. The mega sales aswell accept accumulation accompanying with bargain helps ensure. TOMS sales comprise of promotions in adolescent humans shoes, the summer division sale, 'save by agency of minute advertisement codes' et cetera. Online http://buytomshoesonline.com/goods-233-Chambray-Bimini-Youth-Classics.html toms mens denim cordones martinez assets agnate to the Amazon website, forth with and added accommodate finest sales at shoes and aswell TOMS academic blog helps as able-bodied you to acquisition a person's all-embracing admeasurement in accession to the blueprint you are searching for, besides you will actually get the amount that appear with any brace presented so that you accept an anticipation of the allegation alternative acceptance it to aces out decidedly better. |
Free forum by Nabble | Edit this page |