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