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
>
>
