Re: TAP5-2273: Where would TapestryIOCJUnit4ClassRunner live?
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 app. I'm beginning to think it belongs in it's own tapestry-ioc-test module.
Discussion on AJAX requests need even more than a context?
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. http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Discussion-on-all-AJAX-requests-needing-context-tt5726132.html But what if other components on the page need to know their state, too, before they can update their zoned contents? For example, a list of persons, L, in one part of the page might need to refresh itself whenever a person is edited in component E somewhere else on the page. That's easy (with a bit of bubbling up and perhaps some calls down, or perhaps a bit of pub-sub), unless L is filtered, like this: http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons E doesn't know about L or its filter, and nor should it, so the context on the submit in E will not contain filter info. In that example I found an OK-ish solution but I'm looking for a better way. The solution I found was to make L return javascript that submits the filter form. I made use of the fact that the client knows its state. But I'd prefer not to have that extra round-trip. So here's a crazy idea... What if, when the filter is submitted, we could do something like this: ajaxResponseRenderer.setQueryParameters(filter, filterValue); and Tapestry, client-side, would set that parameter on *every* Form, EventLink, Select, etc. in the page. That way, no matter what event request comes to the server, its request will be carrying the latest filter value. In the example above, L would always be able to find out the current filter: String filterValue = request.getParameter(filter); Crazy, right? I suppose that each component that wants to use this facility would need a way to tell Tapestry its initial values. Perhaps this could be declarative. Thoughts? Cheers, Geoff - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
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 the behaviour, send both.
Re: Discussion on AJAX requests need even more than a context?
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 chars). Using POST may be an option for some things or a totally different paradigm where state is kept server side and the key to locate the state is passed around could be possible... Even though the existing solutions with the server side state clearly has their own set of issues. The discussion is very interesting though ;) -- Chris On Wed, Mar 19, 2014 at 2:42 PM, Lance Java lance.j...@googlemail.comwrote: 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 the behaviour, send both.
Re: Discussion on AJAX requests need even more than a context?
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 refresh itself. On 20/03/2014, at 12:42 AM, Lance Java wrote: 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 the behaviour, send both. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
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 level, just for AJAX. When there's no AJAX, @ActivationRequestParameter works fine: during page render every requester in the page (Form, EventLink, etc) gets the activation request parameters baked into its URLs. Every request that comes in sets the @ActivationRequestParameter. But when there is AJAX, each server-side component needs a way to return its activation request parameters and have the client-side update every URL in the page, not just the URLs in the returned zone(s). That's all I'm proposing. On 20/03/2014, at 12:59 AM, Chris Poulsen wrote: 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 chars). Using POST may be an option for some things or a totally different paradigm where state is kept server side and the key to locate the state is passed around could be possible... Even though the existing solutions with the server side state clearly has their own set of issues. The discussion is very interesting though ;) -- Chris - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
