You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Geoff Callender <ge...@gmail.com> on 2014/03/14 03:32:55 UTC
Discussion on all AJAX requests needing context
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
Re: Discussion on all AJAX requests needing context
Posted by Dmitry Gusev <dm...@gmail.com>.
Oh, I see you what you mean now, there's eventLink that triggers
Select#onChange for ajax selects and it doesn't include any context in the
link. Makes sense.
On Fri, Mar 14, 2014 at 1:31 PM, Chris Poulsen <ma...@nesluop.dk>wrote:
> 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.gusev@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 <duskote@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.jumpstart@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
> >
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Discussion on all AJAX requests needing context
Posted by Chris Poulsen <ma...@nesluop.dk>.
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 <dm...@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 <duskote@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.jumpstart@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
>
Re: Discussion on all AJAX requests needing context
Posted by Dmitry Gusev <dm...@gmail.com>.
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.jumpstart@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 <duskote@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.jumpstart@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Discussion on all AJAX requests needing context
Posted by Dmitry Gusev <dm...@gmail.com>.
I'm not sure about changing page context, but I'd suppose that if page
context changed - then page URL should reflect that, and you have to reload
the page -- and that is usually with HTTP 3xx redirect. You can't just
change the URL in browser's address bar without reloading entire page. One
exception to that if it's the URL's hash you want to change. In this case
I'd expected that you have some JS-model on client-side that would handle
routing and update other links somehow based on client-side model changes.
I haven't seen any real implementations of this approach w/ T5 though.
As for server-side updates of eventLinks -- this is why multi-zone response
support exists, isn't it? I use it when I don't want to bother updating
client-side elements one-by-one -- it's simpler to re-render entire zones.
Though, yes, that complicates things on the server-side. I'm using
Publisher service [1] for such updates to reduce this complexity, but it's
still not so simple to maintain.
[1] https://github.com/anjlab/anjlab-tapestry-commons/wiki/Publisher-API
On Fri, Mar 14, 2014 at 5:01 PM, Geoff Callender <
geoff.callender.jumpstart@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 <duskote@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.jumpstart@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Discussion on all AJAX requests needing context
Posted by Geoff Callender <ge...@gmail.com>.
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 <du...@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.jumpstart@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on all AJAX requests needing context
Posted by Dmitry Gusev <dm...@gmail.com>.
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 <du...@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.jumpstart@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
Re: Discussion on all AJAX requests needing context
Posted by Lance Java <la...@googlemail.com>.
> Yes, I think it should be part of tapestry core.
Unfortunately it clashes a bit with the "zone" parameter in "select". Does
anybody support making a breaking change to remove the ajax behaviour from
select if this mixin was added to core?
> As a nod to jquery you could simply call it "on" :-)
Yeah, I thought about that but didn't feel it was descriptive enough.
Re: Discussion on all AJAX requests needing context
Posted by Geoff Callender <ge...@gmail.com>.
Yes, I think it should be part of tapestry core.
As a nod to jquery you could simply call it "on" :-)
On 15/03/2014, at 6:39 PM, Lance Java wrote:
> It's probably worth mentioning my onevent mixin here.
>
> http://tapestry-stitch.uklance.cloudbees.net/oneventdemo
>
> Sorry to toot my own horn but I think it greatly simplifies many ajax
> interactions. It not only allows a context to be passed but it can also
> send a list of clientside field values in the ajax request.
>
> Currently you can only listen to one event per dom element. It would be
> nice to improve it to attach multiple listeners to multiple a single dom
> element.
>
> Does anyone else think this should be part of tapestry core?
>
> NB I think the "onevent" name is ambiguous. It could do with being renamed
> to "observe" or "listen".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on all AJAX requests needing context
Posted by Lance Java <la...@googlemail.com>.
It's probably worth mentioning my onevent mixin here.
http://tapestry-stitch.uklance.cloudbees.net/oneventdemo
Sorry to toot my own horn but I think it greatly simplifies many ajax
interactions. It not only allows a context to be passed but it can also
send a list of clientside field values in the ajax request.
Currently you can only listen to one event per dom element. It would be
nice to improve it to attach multiple listeners to multiple a single dom
element.
Does anyone else think this should be part of tapestry core?
NB I think the "onevent" name is ambiguous. It could do with being renamed
to "observe" or "listen".
Re: Discussion on all AJAX requests needing context
Posted by Geoff Callender <ge...@gmail.com>.
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 <du...@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.jumpstart@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on all AJAX requests needing context
Posted by Chris Poulsen <ma...@nesluop.dk>.
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 <du...@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.jumpstart@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
> >
>
Re: Discussion on all AJAX requests needing context
Posted by Dusko Jovanovski <du...@gmail.com>.
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.jumpstart@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
>
Re: Discussion on all AJAX requests needing context
Posted by Geoff Callender <ge...@gmail.com>.
Nice one, Thiago. https://issues.apache.org/jira/browse/TAP5-2301.
On 15/03/2014, at 4:51 AM, Thiago H de Paula Figueiredo wrote:
> On Thu, 13 Mar 2014 23:32:55 -0300, Geoff Callender <ge...@gmail.com> wrote:
>
>> To all Tapestry devs,
>
> Hi!
>
> I agree with you. That's one of the first things I want to do when I go back to work on the Month of Tapestry. Please file a JIRA. And thanks for bringing that up. ;)
>
> Cheers!
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on all AJAX requests needing context
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 13 Mar 2014 23:32:55 -0300, Geoff Callender
<ge...@gmail.com> wrote:
> To all Tapestry devs,
Hi!
I agree with you. That's one of the first things I want to do when I go
back to work on the Month of Tapestry. Please file a JIRA. And thanks for
bringing that up. ;)
Cheers!
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on all AJAX requests needing context
Posted by Geoff Callender <ge...@gmail.com>.
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.jumpstart@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on all AJAX requests needing context
Posted by Howard Lewis Ship <hl...@gmail.com>.
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.jumpstart@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