It helps greatly, and makes perfect sense. Thank you.
I'll do what you suggested the next time I encounter this sort of thing.
On 8/17/05, Mind Bridge <[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
