Agreed, but I think Tapestry can go a big step towards to handling more AJAX cases without that. Howard, could you comment on this other discussion:
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Discussion-on-AJAX-requests-need-even-more-than-a-context-tt5726230.html On 26/03/2014, at 5:03 AM, Howard Lewis Ship wrote: > I would definitely agree that Tapestry has a problem dealing with complex > Ajax pages. Essentially, for Tapestry to do the right thing, it has to > have a model of what's going on in the client browser and no such model > exists. > > Passing a page context and an individual event context helps, but you start > getting into scenarios where there's a context for the Zone and a context > for the link/form inside the Zone. > > Past a certain point, it simply feels like we're trying to plug the holes > in the leaky dike. > > I think the correct way forwards is to say that Tapestry's built-in Ajax > support is great for simple to low-moderate complexity ... but if you are > doing something very dynamic, it is not the best approach. Moving complex > UI logic to the client is the right approach, and the challenge is to > figure out how to move Tapestry and it's community in that direction. > > > On Thu, Mar 13, 2014 at 7:32 PM, 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 >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org