Hi Bob, I forgot to mention that I also feel that tapestry-test is a bit
heavy weight.
This junit runner is for testing tapestry-ioc apps. Tapestry-test has
transitive dependencies on tapestry-web, selenium, jetty etc. I'm not sure
people want all that on their classpath when testing an IOC only
So it seems we're pretty much agreed that each AJAX-capable component needs a
context parameter, which its containing component can use to restore its state
(usually its parameters) before it makes any decisions.
Hi Geoff, I'm thinking this can also be done with the onevent mixin I
mentioned earlier. Since it can send a (configurable) list of clientside
field values to the serverside event, you can send all field values that
your event cares about.
If two fields (eg select menus, text fields) determine
Hi,
The over all idea is really interesting and nice, but I think it is a hard
one to implement correctly in the framework.
Having complete page state in GET requests (as context/parameters) may be
troublesome for complex pages with a lot of state (there seem to be an URL
size limit around 2000
Are you sure? How can @OnEvent solve the example I gave?
Keep in mind that L and E are separate components. E is a reusable editor that
doesn't know about L. L is a reusable filter and list that doesn't know about
E, and which kindly provides a public method to allow others to ask it to
No, there's no need for complete page state in any request. In the example I
gave, we restored the necessary state with just one query parameter: filter.
Component contexts looked after the rest.
Think of it as bringing @ActivationRequestParameter down from the page level to
the component/zone
