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 <dmitry.gu...@gmail.com>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 <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
> > >
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
