Re: [Tapestry-developer] Action vs. Direct services

[Dave Roberts]

Okay, thanks. Then my thinking is basically correct. I could see some value in the general case that you describe where you can't encode it and the data is basically static. For most database stuff, however, I would think that using the direct service and encoding primary keys into the links would be the norm, no?   And the final question was about statefulness: why are forms and direct/action links stateful by default? Particularly forms and direct links since you can encode the data into the direct link itself? I can understand why I might want it to be stateful (seems useful under a bunch of various conditions), but I don't quite understand why the component itself should care and in particular why that would be the default. Am I missing a big concept here, or is this something historical, etc?   -- Dave ----- Original Message ----- From: Howard M. Lewis Ship To: Dave Roberts ; [EMAIL PROTECTED] Sent: Wednesday, January 01, 2003 4:46 AM Subject: Re: [Tapestry-developer] Action vs. Direct services It is pretty rare to use the action service rather than the direct service.   In the rare, rare case that there is no way to encode state into a DirectLink (perhaps because important objects are not serializable) then you may be able to accomplish things with ActionLink.  No, I don't have a specific case.   Also, some people will prototype with ActionLink, then swing back and convert the ActionLinks to DirectLinks. ----- Original Message ----- From: Dave Roberts To: [EMAIL PROTECTED] Sent: Wednesday, January 01, 2003 1:36 AM Subject: [Tapestry-developer] Action vs. Direct services I'm still climbing the Tapestry learning curve. My latest set of questions have centered around the action and direct services. Simply, I understand the direct service very well (or at least think I do). It makes total sense to me in a mode-less, multi-user, distributed web application scenario. That is, because it encodes the state of things into the service URLs themselves, things make sense to me.   For the life of me, however, I can't understand why the action service would be a good idea. It seems totally broken to me and fraught with danger. That is, the fact that you rewind a page and assume that everything that was there when the page was first generated is still there now seems just brittle and likely to fail. For instance, imagine a scenario where a page is displaying rows out of a database, with links to operate on that data. If I use the action service, I have to assume that the DB doesn't change between the time I first rendered the page and when the user clicks a link. That seems like a bad assumption in an environment where other users could be adding, deleting, modifying, etc., at the same time, whether that happens 2 milliseconds ago or 10 minutes ago because the user went to grab a cup of java (pun intended) after fetching the page and before submitting his action.   So, given all this and the various statements in the Tapestry tutorial generally suggesting that the direct service is higher performance and generally more efficient, why would one ever use the action service?   As a side question, why do the various action and direct service components default to a stateful session? This seems the wrong default to me. I'm finding myself overriding this behavior to avoid stale session exceptions.   Thanks,   -- Dave