Oh, I see you what you mean now, there's eventLink that triggers Select#onChange for ajax selects and it doesn't include any context in the link. Makes sense.
On Fri, Mar 14, 2014 at 1:31 PM, Chris Poulsen <[email protected]>wrote: > Dimitry, how can we get a hold of the form context in the onValueChanged > handler for Select? (zone/ajax case) > > -- > Chris > > > On Fri, Mar 14, 2014 at 10:16 AM, Dmitry Gusev <[email protected] > >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 <[email protected] > > >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 < > > > [email protected]> 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 > > > -- Dmitry Gusev AnjLab Team http://anjlab.com
