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
Maybe L (which contains F) just needs to use:
@Persist(cookie)
private String filterValue
Downsides might be it's not bookmarkable, and the client-side state persists
beyond the page.
On 26/03/2014, at 11:47 AM, Geoff Callender wrote:
Sorry, but I've read the solution below 10 times now and
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
If both L and E accepted a fields parameter (ListString) 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
That's an interesting concept. I like the sound of it.
On 20 Mar 2014 09:22, Nourredine K. nourredin...@gmail.com wrote:
Hi Geoff,
Maybe the very interesting Dmitri's contribution can help here.
It implements the publisher-subscriber pattern for Tapestry5
pages/components.
Hi Geoff,
How would you know on the client-side which URLs you have to update? What
if some form or a link in client-side DOM isn't a tapestry URL and
shouldn't be updated?
Or what if I generated some event URLs on the server-side and passed them
via JS initializer specification to client-side
Doesn't that mean that E is no longer independent, because it has to know how
many clientIds will arrive in each request?
One thing I like about what I'm proposing is the way it scopes the request
parameters to the component that needs them, ie. other components don't know
anything about
Hi Dmitry,
Every URL on the client-side could be updated. What we're talking about is
setting a query parameter in every URL, eg. putting filter=filterValue in every
URL, whether it needs it or not. It's harmless! That's the beauty of named
parameters.
In my example, if no AJAX was involved
Hi Nourredine,
I like Dmitry's pub-sub, especially for non-AJAX communication between
components in a page.
However, I don't think it can address my example problem in the AJAX world.
That problem is this: if E is independent of L (it is), then E won't publish
what L needs (ie. L's filter
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
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
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
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
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
14 matches
Mail list logo
