You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Blower, Andy" <An...@proquest.co.uk> on 2008/09/12 12:38:25 UTC
Posting a request context
I've just run into IE's URL length restrictions. I have a component that sends up to 100 id's via an Ajax call to the server so that an action can be taken with those id's. The request URL my Ajax call uses is generated by createActionLink() and contains the context of up to 100 id's. I am already stripping the activation context off (?t:ac=blah..) this url because it's not needed for the Ajax call.
The event handler that processes this Ajax request looks like this: StreamResponse onAction(EventContext context)
To get around IE's (curse MS) url length restrictions I want to post my id's, but looking at the T5 ComponentEventDispatcher class, there's no mechanism for obtaining the context from the posted data rather than the request path. This seems surprising to me, am I missing something here or is there a good reason why T5 can't accept context from post data?
It looks to me like I need to get the post data from the request object and parse it myself - is that my only option?
Thanks,
Andy.
RE: Posting a request context
Posted by "Blower, Andy" <An...@proquest.co.uk>.
Thanks Howard, I'm all sorted out now and using JSON with posting back the ids.
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: 15 September 2008 00:34
> To: Tapestry users
> Subject: Re: Posting a request context
>
> One of my goals in Tapestry is that it should give you lots of support
> for normal operations, and get out of the way for application specific
> operations.
>
> In your case, passing this data around can be most easily accomplished
> by building your own XHR request and filling in the query parameters
> however you want. Perhaps you want to build up a single big JSON
> object with all the data the server needs? It's reasonably
> straight-forward; Tapestry (via ComponentRequest.createEventLink() )
> can create a URL and the query parameters are yours to define and use
> as you will. The event handler method, in the page or component, can
> inject the Request object, obtain (and parse) the query parameters,
> and do What Needs Doing.
>
> It sounds like the problem is that you need to pass a collection of
> application ids in the request, and they don't fit in the URL.
>
> I think you can leverage RenderSupport.addInit() to create a
> client-side callback that can have access to that list of application
> ids; they'll be represented as JSON data in the initialization
> JavaScript, rather than as HTML attribute values. And that's fine.
> We're orchestrating here, trying to get all the data we need in one
> place.
>
> I'm afraid the best bet it to look in the code at components such as
> Palette and DateField to see how you can get data from the server to
> the client and back, leveraging JavaScript.
>
> I'll be in Oslo next week, London the week after that.
>
> On Sun, Sep 14, 2008 at 1:17 PM, Andy Blower
> <an...@proquest.co.uk> wrote:
> >
> > Thanks for the reply Howard. I think you may have misunderstood my
> (obviously
> > poor) explanation of what I'm doing. The id's in question are our
> content
> > id's and not related to Tapestry, but they're retrieved from an
> object
> > retrieved from another object held in the session. This is done by
> the page
> > in the onActivate method based on an identifier (no relation to the
> content
> > id's) and without duplicating the activation method from the page in
> this
> > component (making it specific to this page), the content id's cannot
> be
> > retrieved from the session object. During rendering the component is
> > provided with the object containing the content id's that the page
> > activation has found and retrieved, but when not rendering the full
> page
> > it's not.
> >
> > Is that any clearer, I can't tell. :-/ I'm not sure I understand
> what
> > you're getting at either, I'm afraid. Even if I got the component id
> of the
> > page or another component, how would I get the page activation to
> work for
> > an Ajax call?
> >
> > Anyway, can I assume that the only way of processing POSTed data in
> an event
> > handler is manually from the Request object? It doesn't bother me
> doing
> > that, it's hardly difficult, but I'm trying hard to ensure both I and
> my
> > team are doing things the Tapestry way and not falling back on our
> > request-response cycle knowledge from our Struts days. ;-)
> >
> > Thanks,
> >
> > Andy.
> >
> >
> > Howard Lewis Ship wrote:
> >>
> >> So this is just for an Ajax call, eh?
> >>
> >> So, what if you used JavaScript to inform Tapestry of the mapping of
> >> client-side id to server-side component completeId. This could be
> >> done using RenderSupport.addInit() calls. This would give you
> enough
> >> information to assemble the Ajax request, on the client, and POST
> the
> >> necessary server-side component ids.
> >>
> >> On Fri, Sep 12, 2008 at 6:29 AM, Blower, Andy
> >> <An...@proquest.co.uk> wrote:
> >>> Just to add some further thoughts to this, I looked at why I was
> >>> communicating all these id's in the Ajax request and the reason is
> that
> >>> the objects the id's are extracted from are only available at
> render time
> >>> after the page is activated using the activation context. This
> doesn't
> >>> happen for the component Ajax request which doesn't have any way of
> >>> getting the data from the session unless I duplicate the page
> activation
> >>> in this component. Not something I'm keen on doing because it makes
> the
> >>> component specific to this page. Is there an easy way of getting at
> stuff
> >>> that would usually be populated by onActivate on the page into a
> >>> component? That would give me the option of finding the id's in the
> event
> >>> hander rather than communicating the list on the Ajax request.
> >>>
> >>>> -----Original Message-----
> >>>> From: Blower, Andy
> >>>> Sent: 12 September 2008 11:38
> >>>> To: 'Tapestry users'
> >>>> Subject: Posting a request context
> >>>>
> >>>> I've just run into IE's URL length restrictions. I have a
> component
> >>>> that sends up to 100 id's via an Ajax call to the server so that
> an
> >>>> action can be taken with those id's. The request URL my Ajax call
> uses
> >>>> is generated by createActionLink() and contains the context of up
> to
> >>>> 100 id's. I am already stripping the activation context off
> >>>> (?t:ac=blah..) this url because it's not needed for the Ajax call.
> >>>>
> >>>> The event handler that processes this Ajax request looks like
> this:
> >>>> StreamResponse onAction(EventContext context)
> >>>>
> >>>> To get around IE's (curse MS) url length restrictions I want to
> post my
> >>>> id's, but looking at the T5 ComponentEventDispatcher class,
> there's no
> >>>> mechanism for obtaining the context from the posted data rather
> than
> >>>> the request path. This seems surprising to me, am I missing
> something
> >>>> here or is there a good reason why T5 can't accept context from
> post
> >>>> data?
> >>>>
> >>>> It looks to me like I need to get the post data from the request
> object
> >>>> and parse it myself - is that my only option?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Andy.
> >>>
> >>> -------------------------------------------------------------------
> --
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Howard M. Lewis Ship
> >>
> >> Creator Apache Tapestry and Apache HiveMind
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >>
> >
> > --
> > View this message in context: http://www.nabble.com/Posting-a-
> request-context-tp19453420p19483940.html
> > Sent from the Tapestry - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Posting a request context
Posted by Howard Lewis Ship <hl...@gmail.com>.
One of my goals in Tapestry is that it should give you lots of support
for normal operations, and get out of the way for application specific
operations.
In your case, passing this data around can be most easily accomplished
by building your own XHR request and filling in the query parameters
however you want. Perhaps you want to build up a single big JSON
object with all the data the server needs? It's reasonably
straight-forward; Tapestry (via ComponentRequest.createEventLink() )
can create a URL and the query parameters are yours to define and use
as you will. The event handler method, in the page or component, can
inject the Request object, obtain (and parse) the query parameters,
and do What Needs Doing.
It sounds like the problem is that you need to pass a collection of
application ids in the request, and they don't fit in the URL.
I think you can leverage RenderSupport.addInit() to create a
client-side callback that can have access to that list of application
ids; they'll be represented as JSON data in the initialization
JavaScript, rather than as HTML attribute values. And that's fine.
We're orchestrating here, trying to get all the data we need in one
place.
I'm afraid the best bet it to look in the code at components such as
Palette and DateField to see how you can get data from the server to
the client and back, leveraging JavaScript.
I'll be in Oslo next week, London the week after that.
On Sun, Sep 14, 2008 at 1:17 PM, Andy Blower <an...@proquest.co.uk> wrote:
>
> Thanks for the reply Howard. I think you may have misunderstood my (obviously
> poor) explanation of what I'm doing. The id's in question are our content
> id's and not related to Tapestry, but they're retrieved from an object
> retrieved from another object held in the session. This is done by the page
> in the onActivate method based on an identifier (no relation to the content
> id's) and without duplicating the activation method from the page in this
> component (making it specific to this page), the content id's cannot be
> retrieved from the session object. During rendering the component is
> provided with the object containing the content id's that the page
> activation has found and retrieved, but when not rendering the full page
> it's not.
>
> Is that any clearer, I can't tell. :-/ I'm not sure I understand what
> you're getting at either, I'm afraid. Even if I got the component id of the
> page or another component, how would I get the page activation to work for
> an Ajax call?
>
> Anyway, can I assume that the only way of processing POSTed data in an event
> handler is manually from the Request object? It doesn't bother me doing
> that, it's hardly difficult, but I'm trying hard to ensure both I and my
> team are doing things the Tapestry way and not falling back on our
> request-response cycle knowledge from our Struts days. ;-)
>
> Thanks,
>
> Andy.
>
>
> Howard Lewis Ship wrote:
>>
>> So this is just for an Ajax call, eh?
>>
>> So, what if you used JavaScript to inform Tapestry of the mapping of
>> client-side id to server-side component completeId. This could be
>> done using RenderSupport.addInit() calls. This would give you enough
>> information to assemble the Ajax request, on the client, and POST the
>> necessary server-side component ids.
>>
>> On Fri, Sep 12, 2008 at 6:29 AM, Blower, Andy
>> <An...@proquest.co.uk> wrote:
>>> Just to add some further thoughts to this, I looked at why I was
>>> communicating all these id's in the Ajax request and the reason is that
>>> the objects the id's are extracted from are only available at render time
>>> after the page is activated using the activation context. This doesn't
>>> happen for the component Ajax request which doesn't have any way of
>>> getting the data from the session unless I duplicate the page activation
>>> in this component. Not something I'm keen on doing because it makes the
>>> component specific to this page. Is there an easy way of getting at stuff
>>> that would usually be populated by onActivate on the page into a
>>> component? That would give me the option of finding the id's in the event
>>> hander rather than communicating the list on the Ajax request.
>>>
>>>> -----Original Message-----
>>>> From: Blower, Andy
>>>> Sent: 12 September 2008 11:38
>>>> To: 'Tapestry users'
>>>> Subject: Posting a request context
>>>>
>>>> I've just run into IE's URL length restrictions. I have a component
>>>> that sends up to 100 id's via an Ajax call to the server so that an
>>>> action can be taken with those id's. The request URL my Ajax call uses
>>>> is generated by createActionLink() and contains the context of up to
>>>> 100 id's. I am already stripping the activation context off
>>>> (?t:ac=blah..) this url because it's not needed for the Ajax call.
>>>>
>>>> The event handler that processes this Ajax request looks like this:
>>>> StreamResponse onAction(EventContext context)
>>>>
>>>> To get around IE's (curse MS) url length restrictions I want to post my
>>>> id's, but looking at the T5 ComponentEventDispatcher class, there's no
>>>> mechanism for obtaining the context from the posted data rather than
>>>> the request path. This seems surprising to me, am I missing something
>>>> here or is there a good reason why T5 can't accept context from post
>>>> data?
>>>>
>>>> It looks to me like I need to get the post data from the request object
>>>> and parse it myself - is that my only option?
>>>>
>>>> Thanks,
>>>>
>>>> Andy.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Posting-a-request-context-tp19453420p19483940.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Posting a request context
Posted by Andy Blower <an...@proquest.co.uk>.
Thanks for the reply Howard. I think you may have misunderstood my (obviously
poor) explanation of what I'm doing. The id's in question are our content
id's and not related to Tapestry, but they're retrieved from an object
retrieved from another object held in the session. This is done by the page
in the onActivate method based on an identifier (no relation to the content
id's) and without duplicating the activation method from the page in this
component (making it specific to this page), the content id's cannot be
retrieved from the session object. During rendering the component is
provided with the object containing the content id's that the page
activation has found and retrieved, but when not rendering the full page
it's not.
Is that any clearer, I can't tell. :-/ I'm not sure I understand what
you're getting at either, I'm afraid. Even if I got the component id of the
page or another component, how would I get the page activation to work for
an Ajax call?
Anyway, can I assume that the only way of processing POSTed data in an event
handler is manually from the Request object? It doesn't bother me doing
that, it's hardly difficult, but I'm trying hard to ensure both I and my
team are doing things the Tapestry way and not falling back on our
request-response cycle knowledge from our Struts days. ;-)
Thanks,
Andy.
Howard Lewis Ship wrote:
>
> So this is just for an Ajax call, eh?
>
> So, what if you used JavaScript to inform Tapestry of the mapping of
> client-side id to server-side component completeId. This could be
> done using RenderSupport.addInit() calls. This would give you enough
> information to assemble the Ajax request, on the client, and POST the
> necessary server-side component ids.
>
> On Fri, Sep 12, 2008 at 6:29 AM, Blower, Andy
> <An...@proquest.co.uk> wrote:
>> Just to add some further thoughts to this, I looked at why I was
>> communicating all these id's in the Ajax request and the reason is that
>> the objects the id's are extracted from are only available at render time
>> after the page is activated using the activation context. This doesn't
>> happen for the component Ajax request which doesn't have any way of
>> getting the data from the session unless I duplicate the page activation
>> in this component. Not something I'm keen on doing because it makes the
>> component specific to this page. Is there an easy way of getting at stuff
>> that would usually be populated by onActivate on the page into a
>> component? That would give me the option of finding the id's in the event
>> hander rather than communicating the list on the Ajax request.
>>
>>> -----Original Message-----
>>> From: Blower, Andy
>>> Sent: 12 September 2008 11:38
>>> To: 'Tapestry users'
>>> Subject: Posting a request context
>>>
>>> I've just run into IE's URL length restrictions. I have a component
>>> that sends up to 100 id's via an Ajax call to the server so that an
>>> action can be taken with those id's. The request URL my Ajax call uses
>>> is generated by createActionLink() and contains the context of up to
>>> 100 id's. I am already stripping the activation context off
>>> (?t:ac=blah..) this url because it's not needed for the Ajax call.
>>>
>>> The event handler that processes this Ajax request looks like this:
>>> StreamResponse onAction(EventContext context)
>>>
>>> To get around IE's (curse MS) url length restrictions I want to post my
>>> id's, but looking at the T5 ComponentEventDispatcher class, there's no
>>> mechanism for obtaining the context from the posted data rather than
>>> the request path. This seems surprising to me, am I missing something
>>> here or is there a good reason why T5 can't accept context from post
>>> data?
>>>
>>> It looks to me like I need to get the post data from the request object
>>> and parse it myself - is that my only option?
>>>
>>> Thanks,
>>>
>>> Andy.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Posting-a-request-context-tp19453420p19483940.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Posting a request context
Posted by Howard Lewis Ship <hl...@gmail.com>.
So this is just for an Ajax call, eh?
So, what if you used JavaScript to inform Tapestry of the mapping of
client-side id to server-side component completeId. This could be
done using RenderSupport.addInit() calls. This would give you enough
information to assemble the Ajax request, on the client, and POST the
necessary server-side component ids.
On Fri, Sep 12, 2008 at 6:29 AM, Blower, Andy
<An...@proquest.co.uk> wrote:
> Just to add some further thoughts to this, I looked at why I was communicating all these id's in the Ajax request and the reason is that the objects the id's are extracted from are only available at render time after the page is activated using the activation context. This doesn't happen for the component Ajax request which doesn't have any way of getting the data from the session unless I duplicate the page activation in this component. Not something I'm keen on doing because it makes the component specific to this page. Is there an easy way of getting at stuff that would usually be populated by onActivate on the page into a component? That would give me the option of finding the id's in the event hander rather than communicating the list on the Ajax request.
>
>> -----Original Message-----
>> From: Blower, Andy
>> Sent: 12 September 2008 11:38
>> To: 'Tapestry users'
>> Subject: Posting a request context
>>
>> I've just run into IE's URL length restrictions. I have a component
>> that sends up to 100 id's via an Ajax call to the server so that an
>> action can be taken with those id's. The request URL my Ajax call uses
>> is generated by createActionLink() and contains the context of up to
>> 100 id's. I am already stripping the activation context off
>> (?t:ac=blah..) this url because it's not needed for the Ajax call.
>>
>> The event handler that processes this Ajax request looks like this:
>> StreamResponse onAction(EventContext context)
>>
>> To get around IE's (curse MS) url length restrictions I want to post my
>> id's, but looking at the T5 ComponentEventDispatcher class, there's no
>> mechanism for obtaining the context from the posted data rather than
>> the request path. This seems surprising to me, am I missing something
>> here or is there a good reason why T5 can't accept context from post
>> data?
>>
>> It looks to me like I need to get the post data from the request object
>> and parse it myself - is that my only option?
>>
>> Thanks,
>>
>> Andy.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Posting a request context
Posted by "Blower, Andy" <An...@proquest.co.uk>.
Just to add some further thoughts to this, I looked at why I was communicating all these id's in the Ajax request and the reason is that the objects the id's are extracted from are only available at render time after the page is activated using the activation context. This doesn't happen for the component Ajax request which doesn't have any way of getting the data from the session unless I duplicate the page activation in this component. Not something I'm keen on doing because it makes the component specific to this page. Is there an easy way of getting at stuff that would usually be populated by onActivate on the page into a component? That would give me the option of finding the id's in the event hander rather than communicating the list on the Ajax request.
> -----Original Message-----
> From: Blower, Andy
> Sent: 12 September 2008 11:38
> To: 'Tapestry users'
> Subject: Posting a request context
>
> I've just run into IE's URL length restrictions. I have a component
> that sends up to 100 id's via an Ajax call to the server so that an
> action can be taken with those id's. The request URL my Ajax call uses
> is generated by createActionLink() and contains the context of up to
> 100 id's. I am already stripping the activation context off
> (?t:ac=blah..) this url because it's not needed for the Ajax call.
>
> The event handler that processes this Ajax request looks like this:
> StreamResponse onAction(EventContext context)
>
> To get around IE's (curse MS) url length restrictions I want to post my
> id's, but looking at the T5 ComponentEventDispatcher class, there's no
> mechanism for obtaining the context from the posted data rather than
> the request path. This seems surprising to me, am I missing something
> here or is there a good reason why T5 can't accept context from post
> data?
>
> It looks to me like I need to get the post data from the request object
> and parse it myself - is that my only option?
>
> Thanks,
>
> Andy.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org