I'm not sure about changing page context, but I'd suppose that if page context changed - then page URL should reflect that, and you have to reload the page -- and that is usually with HTTP 3xx redirect. You can't just change the URL in browser's address bar without reloading entire page. One exception to that if it's the URL's hash you want to change. In this case I'd expected that you have some JS-model on client-side that would handle routing and update other links somehow based on client-side model changes. I haven't seen any real implementations of this approach w/ T5 though.
As for server-side updates of eventLinks -- this is why multi-zone response support exists, isn't it? I use it when I don't want to bother updating client-side elements one-by-one -- it's simpler to re-render entire zones. Though, yes, that complicates things on the server-side. I'm using Publisher service [1] for such updates to reduce this complexity, but it's still not so simple to maintain. [1] https://github.com/anjlab/anjlab-tapestry-commons/wiki/Publisher-API On Fri, Mar 14, 2014 at 5:01 PM, Geoff Callender < geoff.callender.jumpst...@gmail.com> wrote: > I think column sorting also needs to pass context if, for instance, you're > using a paged, filtered, GridDataSource. Without a context it might not > build the next page correctly. > > Bookmarking is a different issue, that I don't yet have a good solution > for. For example, every EventLink has the page context baked into it when > it's rendered. If events in other zones modify the page context, EventLinks > outside those zones will not know the page context has changed. To address > this, the event handlers must either refresh every component that can send > a component event request (a zone around every EventLink?) or, for > simplicity, refresh the whole page. If you're refreshing the whole page > then the advantage of AJAX is kind of lost. > > On 14/03/2014, at 8:16 PM, Dmitry Gusev wrote: > > > I'd agree with context for the Grid component, though the only use-case I > > see for Grid's context is for paging event links, and it'd be nice and > easy > > to support this. > > But Select component must be put into a Form, and forms have contexts, > so I > > see no problems here. > > > > I don't think one should avoid using @Persist, it's just may be not the > > best choice for some use-cases using it with session scope. > > In such cases cookie-backed scope usually works well. > > > > Also I don't see any problems with your 2nd and 3rd "workarounds". The > > question here is if you want to make the page state bookmark able, if you > > do -- you have to put this information to page's context (or page > params). > > And you should be able to reconstruct the rest required parameters for > all > > your components from page's context. > > > > > > > > > > On Fri, Mar 14, 2014 at 12:53 PM, Dusko Jovanovski <dusk...@gmail.com > >wrote: > > > >> You are absolutely right. Context for Select and Grid would be a welcome > >> addition. Even though these are only scaffolding components that are > meant > >> to be extended and modified to fit your use cases, most people use them > as > >> they are. There may be some other components that need this addition, > but > >> none come to mind at the moment. > >> > >> > >> On Fri, Mar 14, 2014 at 3:32 AM, Geoff Callender < > >> geoff.callender.jumpst...@gmail.com> wrote: > >> > >>> To all Tapestry devs, > >>> > >>> Please, I want your thoughts before I file a JIRA, just in case I have > my > >>> wires crossed. > >>> > >>> I'm thinking that Tapestry has real problems working with complex AJAX > >>> pages because there are AJAX components that don't have a context > >>> parameter. > >>> > >>> The problem I see is that a deeply nested component, C, cannot handle > an > >>> event from an AJAX sub-component unless C can reconstruct its context, > >> ie. > >>> C has to be able to restore its parameters. This has been solved in > Form > >>> and EventLink by giving them a context parameter. eg. > >>> > >>> onPrepareForSubmit(Integer contextArg1) { etc. } > >>> > >>> onMyevent(Integer contextArg1) { etc. } > >>> > >>> I routinely use this context to restore C's parameters, eg. > >>> > >>> @Parameter > >>> private Integer parameter1; > >>> > >>> onPrepareForSubmit(Integer parameter1) { > >>> this.parameter1 = parameter1; > >>> } > >>> > >>> But what about Select and Grid? Neither of them has a context. > >>> > >>> Without a context, C can't handle 2 or more AJAX Select components. > When > >>> one sends an event, C has no idea of the value of the other, nor of its > >> own > >>> parameters. A context would fix all of this. > >>> > >>> Without a context, an inplace request from a GridPager can't remind C > was > >>> currently selected or how the Grid was being filtered. The same goes > for > >>> Grid column select events. (See > >>> https://issues.apache.org/jira/browse/TAP5-2297) > >>> > >>> There are workarounds, but with a context I think we wouldn't need > them: > >>> > >>> 1. Use @Persist. Well, we all try to avoid this. > >>> > >>> 2. Include C's parameters in the page's context and make sure they're > >>> passed down through every nested component down to C. But surely that's > >> not > >>> reasonable. What if the page is concerned with a Hospital, but in it > our > >>> components drill down through a Ward to a Patient and C is concerned > with > >>> the Patient's Diagnosis. Does it really make sense to pass diagnosisId > in > >>> through the page context and down through all the in-between > components? > >>> Following this logic, we could end up with every parameter of every > >>> component in the page context. > >>> > >>> 3. Use activation request parameters, but it appears to me to be messy. > >>> @ActivationRequestParameters is only available at the page level, so > >> again > >>> we have to pass them all the way down. Even if we do this, it's a > >> nuisance > >>> to pass them all the way UP in the first place. And again we could end > up > >>> with every parameter of every component being declared in the page. > >>> > >>> 4. Perhaps C can get and set request parameters by hand, but why? > Isn't a > >>> context better? > >>> > >>> Am I seeing an issue that doesn't exist? Is there a better way? > >>> > >>> Cheers, > >>> > >>> Geoff > >>> > >> > > > > > > > > -- > > Dmitry Gusev > > > > AnjLab Team > > http://anjlab.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Dmitry Gusev AnjLab Team http://anjlab.com
