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
