Right, actually every eventLink that is inside of core component should
support context so that server-side could restore some state on request.
On Fri, Mar 14, 2014 at 5:01 PM, Geoff Callender <
geoff.callender.jumpst...@gmail.com> wrote:
> I think column sorting also needs to pass context if, for instance, you're
> using a paged, filtered, GridDataSource. Without a context it might not
> build the next page correctly.
>
> Bookmarking is a different issue, that I don't yet have a good solution
> for. For example, every EventLink has the page context baked into it when
> it's rendered. If events in other zones modify the page context, EventLinks
> outside those zones will not know the page context has changed. To address
> this, the event handlers must either refresh every component that can send
> a component event request (a zone around every EventLink?) or, for
> simplicity, refresh the whole page. If you're refreshing the whole page
> then the advantage of AJAX is kind of lost.
>
> On 14/03/2014, at 8:16 PM, Dmitry Gusev 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
