I realise what I'm saying is similar to your original suggestion ajaxResponseRenderer.setQueryParameters("filter", filterValue);
In your suggestion, the value (filterValue) is known serverside. I think we need the ability to pass a clientside value that the server may not know about. Let's think about things we might want to pass from client to server: 1. The current value of a field 2. The current location of the mouse 3. The size of the client's screen 4. A serverside value known at render time. A future proof solution would allow a component to register a javascript closure to be executed and the resultant value is sent to the server. A default/builtin closure implementation can get the current value of a clientside field. On 27 Mar 2014 09:21, "Lance Java" <lance.j...@googlemail.com> wrote: > Yes, you're right. You would need the current field values to be passed > along with the submit. @Persist cookie would work. > > Or a mechanism like the onevent mixin would work where a list of field ids > is required and passed from client to server. But as you said, you don't > like this because one component needs knowledge of the other. > > If the list of fields was passed from the containing page (or component) > I'm thinking it's ok. Perhaps each component could register it's fields > with the container so it's more transparent? > On 26 Mar 2014 00:49, "Geoff Callender" < > geoff.callender.jumpst...@gmail.com> wrote: > >> Sorry, but I've read the solution below 10 times now and it hurts my head >> every time! :-) I don't see how it gets around the problem that when E is >> AJAX-submitted, the server-side elements can find ways to prod L to refresh >> but they cannot tell L the current value of F. The server-side doesn't know >> the current value of F, unless we make the server-side stateful (no thank >> you), or we somehow include the value of F in every request. >> >> What I'm aiming for is a solution which works declaratively. You know, >> where you don't see the plumbing. Just like @ActivationRequestParameter, >> but at the component level. >> >> On 21/03/2014, at 2:35 AM, Lance Java wrote: >> >> > I'm imagining the pub sub would work like... >> > >> > public class L { >> > @Inject >> > private Publisher publisher; >> > >> > @Inject >> > private Block someBlock; >> > >> > /** >> > * Fired when the select menu changes >> > */ >> > public Object onFilterChange(Entity entity) { >> > publisher.publish("changeEntity", entity); >> > return someBlock; >> > } >> > } >> > >> > public class E { >> > @Inject >> > private AjaxResponseRenderer ajaxResponseRenderer; >> > >> > @Inject >> > private Zone someZone; >> > >> > @Property >> > private Entity entity; >> > >> > @Subscribe(topic="changeEntity") >> > void subscribeChangeEntity(Entity entity) { >> > this.entity = entity; >> > ajaxResponseRenderer.addRender(someZone; >> > } >> > } >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >>