Hi, This is a well timed discussion ;-)
I've been spending some time creating a grid version that supports filtering and not uses @Persist internally. I have been forced to create a new Select to get context support, I've decided not to create context support for the grid until it is actually needed. I do not see Select as a scaffolding component in the same category as grid, Select has a pretty narrow scope while it is most likely impossible to make a grid that provides everything that everyone need. If it is the thought that everyone should override the Select component to get context support, it would be nice if it was more trivial to extend/modify the core/Select. -- Chris On Fri, Mar 14, 2014 at 9:53 AM, 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 > > >
