Using the Action service is often necessary when doing polymorphic rendering via RenderBlock or Delegator, especially when the inserted block/component is located on a different page.
Using a Direct in such a case would load only the page where the link was generated, but it would not do so for the page(s) that dynamically inserted the component. Those pages are often (but not always) necessary in order to perform certain actions.
In the simpler cases Direct can still be used by passing a ComponentAddress object representing the inserting page in the direct parameters and then using it to load that page. In more complex cases this approach becomes too hairy, however, and the Action service comes to the rescue. Since it "re-renders" the page, it allows objects to be set in the cycle's parameters (similar to what Body and Form are doing), etc. and simplifies the handling of this situation significantly.
Of course, one has to be careful that the rewind is identical to the previous render, or at least handle the discrepancies. This may be a bit tricky when a database is involved. Exactly the same applies to handling forms, however. Perhaps a section needs to be added to the developer guide describing in detail the various strategies for managing this situation, since this is bound to come up often. Perhaps we need to see if some of those can be eased/automated as well...
-mb
"Howard M. Lewis Ship" <[EMAIL PROTECTED]> wrote:
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 RobertsSent: Wednesday, January 01, 2003 1:36 AMSubject: [Tapestry-developer] Action vs. Direct servicesI'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
