Sorry, I did not read your first email carefully. I saw 'ListEdit' in
the responses, and my gears started turning in the wrong direction.
What you are seeing is a typical behaviour for Tapestry. Persistent
properties (and properties in general) are directly linked to your
component's bean -- for example, you could have getMessageBody() in your
Java code and Tapestry will link that to the persistent property.
In Tapestry, however, _only one component_ is used in the loop body, no
matter how many iterations that loop will perform. In other frameworks
if the loop makes 1000 iterations, you would get 1000 instances of the
component's bean. In Tapestry it is just one that is invoked 1000 times.
The direct consequence is that the properties are the same for each loop
iteration. In your case 'messageBody' would refer to the same thing over
and over, and the last 'set' will overwrite the others. Hence the
behaviour you are observing.
Here is what I would suggest:
Have your component take a parameter of type Message (for example) and
it can provide the display and editting of the value that is passed to it.
Have the container provide a list of Message objects. The list can be
passed to Foreach (or For) as a source so that they can iterate on it.
The value of each iteration is then passed as a parameter to your
component. The container can then persist the list of messages.
I hope that helps,
-mb
Scott Wadden wrote:
This is largely a synthetic problem. I've since put each component in
it's own form, which works fine. I'm still trying to figure out why
this is happening in my example app though. I'm quite fuzzy on many
Tapestry fundamentals, and although this isn't the sort of thing
that's likely to crop up very often, I'd really like to know why it
doesn't work the way I expected it to.
What I posted was just a simple app that demonstrated the problem.
Add a doctype to the jwc file, and stick in a skeleton Home.page file,
and you should have exactly what I was running when I initially
posted. There's no Java code, Conditionals, Ifs, or any other logic.
Switching to a ListEdit required adding a property to the page file,
as the value of the ListEdit must be bound to something, but I'm not
actually doing anything with it beyond that.
I can e-mail you a ready to roll (minus libs of course) web context
root for tapestry 3 or 4 that shows what I'm talking about, if you'd
like to take a look. Or I could just forget about it for now.. fixing
this isn't critical, and I expect I won't have these sorts of troubles
once I know a little bit more about Tapestry. I'm still really
curious what's going on though, if you have the time.
Thank you Jesse and Mind Bridge. I really appreciate the help.
Scott
On 8/17/05, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
Hmmmm....I'm having a hard time finding all the possible problems in
my head without seeing more of what you're doing. Can you paste your
page spec in here? And possibly the listener method on your page class
that is synchronizing your listedit list with the component?
jesse
On 8/17/05, Scott Wadden <[EMAIL PROTECTED]> wrote:
Actually, I'm getting the same behavior with the ListEdit.
This seems to work if messageBody is a parameter rather than a regular
property, and I'll do that if I need to, but in this case the
TextArea's value isn't of interest outside the component. Is there
any way to fix this without exposing the TextArea's value?
On 8/17/05, Scott Wadden <[EMAIL PROTECTED]> wrote:
You're a useful fellow Jesse :)
Now that you mention it, I specifically remember reading something
like that in Tapestry in Action. I'll try it with a ListEdit. Thanks
a lot.
On 8/17/05, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
You might try using a ListEdit component instead, I think Foreach
loops aren't safe inside forms, because they don't interact with the
hidden form input fields that keep track of which components to
expect...
jesse
On 8/17/05, Scott Wadden <[EMAIL PROTECTED]> wrote:
Hey folks. I'm really new to Tapestry, but it's definitely been a
pleasure to use thus far. I'm a fairly experienced ASP.NET developer
who's recently converted to Java, but I felt like I was stepping back
into the dark ages with Struts and JSP. I find myself missing .NET
less and less the more I use Tapestry however.
Most of the stuff I've done so far has been pretty simple. Fairly
static forms, and a couple of read only lists. However, I've recently
run into problems trying to put form fields in a component that's
contained in a Foreach loop. Basically, all the components seem to
given the state of the last component rendered.
I've created a very simple demo that illustrates my problem. It
consists of a component that contains a TextArea, and a property to
hold the TextArea's value. My page simply outputs a bunch of these
inside of a loop. First the component, TestList.jwc, with the doctype
removed:
<component-specification>
<property-specification name="messageBody" persistent="yes"/>
<component id="newComp" type="TextArea">
<binding name="value" expression="messageBody"/>
</component>
</component-specification>
Now the component's template, TestList.html:
<span jwcid="newComp" />
And finally the page template, Home.html:
<html>
<body>
<form jwcid="@Form">
<div jwcid="@Foreach" source="ognl:{1, 2, 3, 4, 5}">
<span jwcid="@TestList" />
</div>
<input type="submit" jwcid="@Submit" value="Submit form" />
</form>
</body>
</html>
I tried this in 3.03 and 4.0b4 (with the appropriate changes of
course) and get exactly the same behavior. Whatever is in the final
text area gets put into the other 4 whenever I submit the form. What
do I have to do to get my component to maintain its own state in this
sort of situation?
Thank you very much,
Scott
---------------------------------------------------------------------
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]
