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
 

Reply via email to