|
The statefulness issue is addressed in 2.4.
Basically, if the app is stateful when the link is written, then it must be
stateful when the link is clicked, which works for 99% of the cases (and can be
overriden for that last 1%).
Yes, there is a bit of historical baggage in
Tapestry; when I started it, there was no direct service, just action
service.
----- Original Message -----
Sent: Wednesday, January 01, 2003 11:30
AM
Subject: Re: [Tapestry-developer] Action
vs. Direct services
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 -----
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 -----
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
|
