it is almost like that, but only almost.
in the deleteListener, try to only "mark" the item to delete, and delete
it only on the form listener.
when you delete it on the submit listener which is inside a foreach, the
list is altered during iteration.
when item #4 (say) renders, it removes itself from the list.
now previously there were 5 items. now there are only four. tapestry
expects another iteration, but it won't because... the list has *now*
only 4 etc.
you could also use the For from t-deli, or just upgrade to 4.0 which is
anyway recommended...
Cheers,
Ron
Inge Solvoll wrote:
Hi, thanks for answering!
I know how the request cycle works in tapestry. My problem occurs when I
want a listener to remove an item from a list, or when I want a listener to
add a radio button to the page, for example. The rewinding works fine, but
when the page renders after the rewind, the ordering and count of the
components on the page has changed, and the StaleLink appears.
1. Press the "delete" button on one item in a list of items (submits the
form)
2. Rewind starts
3. Reach the delete() listener in the page class
4. The delete() listener removes the selected item from the "items"
collection property of the page
5. Render starts
6. StaleLinkException (some component found when another one was expected).
I totally understand why this happens, but I don't understand how to avoid
it. A "throw new PageRedirectException(this)" from the listener during
rewind obviously solves the problem easily, but I don't want that, I don't
want to have to persist a lot of page state server side, which is pretty
much a necessity when using redirects during requests.
Another possible solution is to perform the actual deletion of the item
during render, and just prepare for the operation in the listener. But then
we move towards uglier code, and that's not the reason why I chose tapestry
for this project... :)
Inge
On 12/12/05, Ron Piterman <[EMAIL PROTECTED]> wrote:
do the work in a listener that is called *after* the list is rendered,
and you have no problem.
The redirect has nothing to do with it - on submit, the page is rendered
twice, first it rewinds, collecting all submit values, and then it
renders normally, for the response sake, unless you activate another
page during rewind, which then will be rendered instead of the form's
page.
Cheers,
Ron
Inge Solvoll wrote:
I have some cases where I need a new design pattern to avoid
StaleLinkException.
1. Render a list.
2. Check a couple of items to be deleted.
3. Submit form.
4. Delete the checked items from the db on rewind
5. Do a cycle.activate(this)
6. The page renders, and a StaleLinkException occurs, because the
component
count on the page has changed due to deletion of the items.
This pattern used here is, as far as I can see, the pattern recommended
by
Tapestry. But it doesn't work when you have to remove or add components
between page rewind and render in the same request. I don't see any
other
solution than redirecting, which can be a good enogh solution for some
cases, but not for others.
Our application is having more problems with back and refresh after
porting
to tapestry, and we need to find a strategy for this.
Are there any good pointers to articles on this, apart from the articles
recommending a redirect after post, to avoid browser back-button
problems?
Inge
On 12/11/05, Ron Piterman <[EMAIL PROTECTED]> wrote:
The For component in 4.0 is deprecating the ForEach component. It is one
of few components that were added. Also the If is deprecating the
Conditional. Both components have much better Form functionality, to
help and prevent just what you are facing.
In Addition, Submit has two listeners now - one of them, called 'action'
is deferred to just before the form listener is executed, and helps also
to solve rewind issues.
Also Form validation and values convertion is much better handled in 4.0
.
so - its not only annotations. In fact, annotations, thow hip, are the
most unspectacular feature (imo) in 4.0.
I wouldn"t start an application in 3.0 now - 4.0 is already for some
time now satet of the art, and is going to go final, maybe already
before new year...
Cheers,
Ron
Vincent wrote:
Hi Ron,
I know 4.0 add some new features in it (such as annontaion), but not
components!
Quote ->
This component has been deprecated; Tapestry 4.0 adds the For
component which replaces Foreach and ListEdit components.
<-
Next time I first need to check the 4.0 document before.
best regards,
Vincent
On 12/11/05, Ron Piterman <[EMAIL PROTECTED]> wrote:
Just another thing - if you can, use 4.0, where its much easier to
avoid
such exception with deferred listeners, and the migration of the
T-Deli
For into the tapestry framwork component library. (called action).
Cheers,
Ron
Vincent wrote:
Hi all,
I use foreach component in the table and IActionLink to submit the
click item in the table row(there is more than one submit method in
one form), but I found always got stale link exception.
I tried use set stateful to false to avoid that exception in the form
component, also tried set stateful to false in ActionLink , but
seems
neither works.
Then I thought may be it is possible to catch that exception my
submit
method? Here is the following code, but it seems never went into the
catch before got following exception.
<pre>
You have clicked on a stale link.
Rewind of form Home/$Form expected allocated id #2 to be '$Submit',
but was '$AnySubmit$0' (requested by component Home/$AnySubmit).
This is most likely the result of using your browser's back button,
but can also be an application error.
You may continue by returning to the application's home page.
</pre>
<code>
try {
System.out.println("You have just clicked the
row
submit button");
} catch (StaleLinkException e) {
System.out.println("catched stale link
exception");
}
</code>
So I want your opition how to avoid such annoying exception.
best regards,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
