If both L and E accepted a fields parameter (List<String>) you could pass in the extra field ids to each.
So you would pass L's filter clientId to E and pass E's filter clientId to L. When either L's filter or E's filter change, both filters are passed to the serverside event(s). The "group of fields" demo on tapestry-stitch shows an example of four fields rendered in a loop. When any of the four fields change all four values (and the loop context) are sent to the serverside event. It's similar to this use case except text fields instead of select. On 19 Mar 2014 22:43, "Geoff Callender" <geoff.callender.jumpst...@gmail.com> wrote: > 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 > >
