An alternative to this situation is to pull the list, store it in the visit
and base the page off the list in the visit (so it will be the unchanged
list next click)...of course then the data is slightly stale.
Concurrency is a drag. : )
-C
|--------+---------------------------------------------->
| | [EMAIL PROTECTED] |
| | Sent by: |
| | [EMAIL PROTECTED]|
| | eforge.net |
| | |
| | |
| | 05/03/2002 02:56 PM |
| | |
|--------+---------------------------------------------->
>-----------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED] (Tapestry Developer),
[EMAIL PROTECTED] |
| cc:
|
| Subject: Re: [Tapestry-developer] When to use the ListEdit
|
>-----------------------------------------------------------------------------------------------------------|
Tapestry does some things that other frameworks simply
can't do. You can dynamically build a form in Tapestry
from bits and pieces ... using Conditionals to enable
some parts of the form, use components containing form
components, even grab form components from a Block on
another page using InsertBlock. Lots of power there ...
but at a price.
When you submit a form, Tapestry has to "rewind". In a
simple system like Struts, request parameter names are
simply mapped directly to JavaBean properties of a "form
bean" (and any extra parameters dropped in the bit
bucket).
Tapestry is much more dynamic, with properties being
drawn from all sorts of developer-specified sources when
the page containing the form is renderred. When the
form is submitted, the *same components* pull request
parameters, convert them, and apply the values to
developer-specified properties.
When using looping (Foreach or ListEdit) it gets even
more complicated, since a single Tapestry component must
process a variable number of request parameters.
Tapestry accomplishs this with the "rewind" phase, where
it goes through the motions of rendering the original
page, including loops, conditionals, components, Blocks,
etc., etc. By precisely duplicating the steps it takes
to render the page, it can process the form submission.
A problem occurs due to unstable data. Let's use an
example.
You have a page that allows you to edit a list of items
from a database. There's a page like this in the Vlib
that allows you to edit a bunch of users all in one form.
Well, you have a form around a looping component.
When the page renders, it pulls all the users (let's say
there's five of them) and loops through them. A
TextField renders five times, creating HTML textfields
with names "inputName", "inputName0", "inputName1", etc.
When the form is submitted, Tapestry gets the five
users, loops through them, and is succesfully able to
match each parameter to a user. All is good.
What happens if another web user adds a sixth user
between the time the form is renderred and the time it
is submitted?
Crash and burn. There is no "inputName6". Tapestry
detects this (it keeps a count of the total number of
elements written into the HTML) and throws a
StaleLinkException.
So, how do you handle this case?
You use a ListEdit. It takes a bit of work in the
specification and some additional support code in the
Java class.
What a ListEdit does is record the looping information
right into the form, as hidden fields.
The ListEdit records the number of items to loop, and
the value of each item. In the previous example, it
would record that there were five items, and we'd
configure it to record the primary key of each item.
During the rewind, it would loop over the five items and
restore the primary key for each one. A side-effect of
the accessor method is to setup the user that matches
the primary key for editting.
(Looking over the code just now, I couldn't help
thinking that a listener would be useful instead of
relying on side-effects from the accessor method).
The ListEdit allows the form to be independant of the
underlying storage, since the information critical to
the loop, the number of elements and their values, is
stored in the form.
Yes its complicated and I hope to make it a little
easier, but it gives you a way to handle this difficult
situtation.
--
[EMAIL PROTECTED]
http://tapestry.sf.net
> Hi list,
> I've browsed throughout the developer
> guide and the API javadoc. Write some
> codes, and read the result HTML codes
> very carefully. Still I cannot figure out
> the situation when we should use the
> ListEdit component. Would someone
> please give me a light?
>
> dright
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We
supply
> the hardware. You get the recognition. Email Us:
[EMAIL PROTECTED]
> _______________________________________________
> Tapestry-developer mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/tapestry-developer
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
