tapestry-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Van der Auwera <joac...@progs.be>
Subject tapestry limitations
Date Mon, 12 Jan 2009 17:14:50 GMT
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Mime
View raw message