tapestry limitations

[Joachim Van der Auwera <jo...@progs.be>]

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

RE: tapestry limitations

[Jonathan Barker <jo...@gmail.com>]

 
> - 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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org