Dear tapestry users,
I have been using tapestry5 for quite a long time now, and am very happy
about the framework. It really makes web development a lot easier.
However, there are a couple of cases where tapestry doesn't help. In
each of these cases it seems like I have to jump trhough hoops to get
some properly working behaviour. I am wondering whether there may be
some solutions to these issues :
- 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.
- 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.
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
