Simple CRUD example for comparison with other frameworks and toolkits

[Dustin Whitney]

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.

---

If you reply to this email, your message will be added to the discussion below:

http://databinder.3617998.n2.nabble.com/Simple-CRUD-example-for-comparison-with-other-frameworks-and-toolkits-tp6159509p6191759.html

To start a new topic under Unfiltered, email [hidden email]
To unsubscribe from Unfiltered, click here.

[n8han]

On 03/21/2011 07:07 AM, Dustin Whitney [via Databinder] wrote:

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.

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.

---

If you reply to this email, your message will be added to the discussion below:

http://databinder.3617998.n2.nabble.com/Simple-CRUD-example-for-comparison-with-other-frameworks-and-toolkits-tp6159509p6191759.html

To start a new topic under Unfiltered, email [hidden email]

---

If you reply to this email, your message will be added to the discussion below:

http://databinder.3617998.n2.nabble.com/Simple-CRUD-example-for-comparison-with-other-frameworks-and-toolkits-tp6159509p6191829.html

To start a new topic under Unfiltered, email [hidden email]
To unsubscribe from Unfiltered, click here.

[laufer]

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.

chris_lewis wrote

At least that solution would avoid the performance issue. With something like a façade to something like a session-backed cache, the hit would be less severe, but personally I would choose to avoid it all together.  

As for a "good" solution: an explicit service call works, be it an explicit dependency or something mixed in from a trait. However I feel like there is a better solution. The nice thing about a typical webapp is that authorization is safely tucked out of sight, and its results are persistent (ie a User object is on the session). I say "nice" because one needn't fiddle about with repetitious service calls.

There have been other chats about user authentication in unfiltered, and it seems the general consensus is to have a dedicated authorization trait that runs early. This frees you from validation later, but is of no help if you need a User instance. So I have two suggestions:

1) A session extractor. Auth traits could use the session and extractor without the worry of a double service hit.
2) A kind of request attribute extension to unfiltered, which would probably be analogous to servlet request attributes. Such attributes would be available for the duration of the request, and be available for access/addition to intents. I've not gotten around to exploring this extension yet, but I intend to.

These ideas need to cook a bit more. In both cases you'd have to deal with the typing issue in the extractor, and probably other things I've not thought about...

Sorry for rambling! Thanks again for starting this conversation.

-chris

[liuhuan]

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.