An eventLink tells the application to do something. The context says what you want to do it to.
When you aren't in a loop it is easy to figure out what to do things to and you don't need a context because the thing you are doing the action to is the same for the entire rendering of the page. However, when you are in a loop the thing the action is performed on changes with each iteration. The behavior of the loop is a bit more expecte when you think about how a framework can handle a loop. There are two ways for the framework to solve this (that I'm aware of). One way is the way WebObjects does it. It keeps track of the state of all the variables at the moment each link is rendered. If you click on a link it goes back to that point in time to figure out how things were when that particular link was rendered. The second way is the way Tapestry does it. You have to tell it what object or objects are important for performing the action. These are specified in the context and then the object is passed to the event handler. If you are using Hibernate, Tapestry takes care of just using the IDs in the link and then pulling the entire object out of the database to give to the event handler when it is invoked. The downside of course is that you have to tell the component what objects are important for the action. The upside is that it requires much less memory because the application doesn't have to remember the state of ever iteration of every loop. Also the Tapestry approach means that the page doesn't have to rely on a a session. The links can still be good even after the session goes away because they contain everything necessary to still fire off the event on the proper object. As far as the documentation, the EventLink docs show how it is used in a loop: http://tapestry.apache.org/tapestry5.2-dev/tapestry-core/ref/org/apache/tapestry5/corelib/components/EventLink.html It might be a bit confusing because the context is specified in the java class in an annotation instead of in the component, but it does demonstrate how it works. Mark On Tue, Feb 22, 2011 at 2:57 AM, Erik Fäßler <erik.faess...@uni-jena.de> wrote: > Thank you all for your answers. This behaviour of the loop is actually > unexpected. I see that I'll have to stick with a more static structure or to > rewrite the components in question. For the moment, I will pospone these > things and come back to them later. > > And no, I havn't found anything about this in the docs either :) > > Best, > > Erik > > > Am 18.02.2011 19:38, schrieb Rich M: >> >> On 02/18/2011 12:59 PM, Thiago H. de Paula Figueiredo wrote: >>> >>> On Fri, 18 Feb 2011 15:45:54 -0200, Rich M <rich...@moremagic.com> wrote: >>> >>>> The challenge in your case is I don't believe you can dynamically assign >>>> a component ID. I double checked myself just now, and t:id only took a >>>> discrete ID (in 5.1.0.5), and was not happy pulling it from a property or >>>> other dynamic means. >>> >>> Static structure is not possible with dynamic component ids. I think the >>> issue here is forgetting the event instance and relying only on passing >>> information to the event handler method (in this case, using the context). >>> >> I fully agree, my answer was convoluted in attempts to reference the >> broader scope of challenges faced when dealing with the static structure of >> a component enclosed within a loop. The concept of static structure, given a >> full understanding, makes the proper use of components in a Loop clear. >> >> However, I still think for someone coming to Tapestry it is likely to >> think of loops in the Java sense where each iteration is fresh >> (loop-declared objects/variables are unique between iterations, etc). It >> would be worthwhile to clarify the implications of static structure in loops >> where users are most likely to confuse a need for dynamic behavior with >> dynamic structure based on prior experiences with loops. Perhaps I haven't >> found the right documentation page, but I can't readily find much >> explanation of static structure and its implications in the Tapestry site >> documentation on pages where I might expect it. >> >> Regards, >> Rich >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
