> - events in components with parameters and/or persistent state when > displayed in a loop > > Tapestry does a lot of magic behind the curtains to assure everything > works as expected inside components. This is great. However, once > components are used in a loop, the events suddenly have the same url for > each of the components in the loop. When your event handler needs to > have access to component parameters or persistent state, it all goes > wrong. Yes this can be handled by passing a context to the event, but > this ends up in forcing you to maintain your own persistence > mechanism... It would be nice if some kind of support could be given for > this as part of the framework.
It strikes me that this expresses a need for better / more documentation. It can be challenging to work with a grid of entities to edit within a form, for example. > > - complex navigation and persistent state > > I have a complex crud application. You can select linked records on > seperate pages. The page state contains how to fill in the value and how > to go back to the previous page. This works fine in the general case. > However, when the domain model contains loops (eg table A referring > table B which refers to table A again), then this can go wrong. Let's > say the user starts from page "X" and wants to set a link to "A". After > setting the return page in page "selectA", the user (from that page) > clicks on a link to page "selectB" and from there to (another) > "selectA" page. When moving back, the user goes nicely back to > "selectB", "selectA" and then "selectB" again (should be "X"). This is > caused by only being able to have persistent state for one "selectA" > page, and not being able to indicate that there are two different > instances. You can solve this by using an activation context, but this > is aching to implementing your own persistence mechanism again. > Here again some framework support would be very useful. > This is pretty domain specific. I've done something similar with a pseudo-breadcrumb implementation, where if the destination is already in the breadcrumb trail, the trail gets trimmed back to the destination rather than adding another level. I'm not sure how the framework could do that in a generic way. > > Anybody has ideas how solutions to these problems could be included in > the framework? > > Thanks, > Joachim > -- > Joachim Van der Auwera > PROGS bvba, progs.be > > > --------------------------------------------------------------------- > 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
