Chris,
In case you haven't seen it, I explored some of the issues of Grid, filtering,
and AJAX here:
http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons
Don't know if there are any useful ideas in there for you.
Geoff
On 14/03/2014, at 8:15 PM, Chris Poulsen wrote:
> 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 <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
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
