AJAX and the bleeding edge... minor pains...

[Steven Woolley <wo...@gmail.com>]

Like pouring ajax in my wounds?

Trying to upgrade from 5.0.6, and upgrading all my ajax stuff is killing me...

The issues I've run into (I'm shoehorning things a bit, by just
returning a block from an actionevent handler and grabbing the markup
from the jsonresponse with my AJAX response handler... in part because
of a) below) are:

a) Nested zones?  I haven't been able to get them working... I have a
page where sometimes I just want to update a few minor elements,
sometimes a big grandfather element...

b) The id namespace issue, broke all my javascript $('divid') calls...
there are workarounds (one just posted today,much cleaner than mine...
thanks!) but I'd love to be able to turn this off, for some cases
where duplicate id's won't matter (or is preferred).

c) JSON is powerful, but returning a big complicated element in a json
string is hurting performance (the escaping I assume server side, and
the eval() clientside, as well as inflating the response size with all
the escaping...) ... in some cases almost doubling the roundtrip time
over my 5.0.6 solution (2 seconds vs. 4 seconds in Safari 3) and the
difference is more severe in Firefox 3 (and potentially worse in
IE?)..  I'd really love to be able to just return the raw markup
again... instead of having to wrap it in a JSON object...  if someone
knows how to do this beyond 5.0.6 PLEASE share!!!! Or if someone can
point me to something I can decorate to skip the jsonobject creation,
You'll be my hero!

I should have put c) first... since that's the one I'm struggling most with...
Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: AJAX and the bleeding edge... minor pains...

[Chris Lewis <ch...@bellsouth.net>]

Nice. I think if you were actually getting beachballed and can provide
an estimate markup size (or at least an example block to demo),
including that in a bug report would be legitimate - especially if
you've seen the raw-markup approach remedy things. I would be interested
in seeing your patch as I /might/ be able to clean it up quickly (I've
been hacking through the ajax/partial response areas in T5 recently).

Anyway, glad you found at least a temporary solution - happy hacking!

chris

Steven Woolley wrote:
> Thanks for the response Chris.  Rob Zeigler and myself dug in and
> figured out a temporary workaround... by overriding (the internal and
> subject to change) AjaxPartialResponseRenderer ... I didn't yet do the
> elegance of making the change based on the requested Content-Type, but
> that would be the logical next step.
> The ugly part of the current hack, is that JSONObject is the container
> that is passed through the whole rendering pipeline for the AJAX
> stuff, which means we're not able to avoid passing it around, but we
> just use the MarkupWriter from AjaxPartialResponseRenderer to send to
> the Printstream instead of the JSONObject...
>
> As for the JS side, I was doing that all with my own XHR code anyway,
> in a script that I include on the necessary pages/components.
>
> That evil "eval" was actually giving me the beachball on some of the
> updates of larger more complex elements... so this was a must for that...
> Thanks for you suggestions!  If you'd like me to file a JIRA I can
> probably do so (though my experience attempting to file bugs in the
> past was frustratingly painful...  what can I say, I have thin skin... )
> Steve
>
>
>
>
> On Apr 27, 2008, at 3:07:30, Chris Lewis wrote:
>
>> Hi Steven,
>>
>> Regarding c):
>>
>> I was just about to respond telling you that you can return AJAXObject
>> or an injected block (mark up), and it will work fine, and then I
>> realized that even markup is wrapped in a JSON envelope. I don't think
>> this can be changed without changing some T5 code - even if you could
>> replace the relevant handlers via module contributions (probable), you
>> still can't affect the JS that handles the responses (or maybe you can
>> by providing your own in the expected package, like overriding
>> validation messages...).
>>
>> Anyway that seems to be a legitimate issue and depending on feedback you
>> should consider adding a JIRA (or 3). In theory the problem could be
>> solved by adding/seting a header in the T5 AJAX responses, stating if it
>> is raw markup or not. tapestry.js would check for this header and then
>> behave accordingly (that is, no eval just a content update). Actually I
>> think the 'correct' way to do this would be to set a Content-Type of
>> 'application/json' for json reponses
>> (http://www.ietf.org/rfc/rfc4627.txt), or 'text/xml' for raw content.
>>
>> AJAX support has come a long way but it's still notably rough in some
>> areas (and if you watch the dev or JIRA you've noticed that). Anyway the
>> fix I suggested shouldn't take too much work, and I could probably
>> submit a patch if you can hack together a simple project that
>> demonstrates the issue. I am quite interested in T5's AJAX support and
>> really think that it could very much shield developers from dealing with
>> a lot of things, it should needs a bit more time in the oven.
>>
>> chris
>>
>> Steven Woolley wrote:
>>> Like pouring ajax in my wounds?
>>>
>>> Trying to upgrade from 5.0.6, and upgrading all my ajax stuff is
>>> killing me...
>>>
>>> The issues I've run into (I'm shoehorning things a bit, by just
>>> returning a block from an actionevent handler and grabbing the markup
>>> from the jsonresponse with my AJAX response handler... in part because
>>> of a) below) are:
>>>
>>> a) Nested zones?  I haven't been able to get them working... I have a
>>> page where sometimes I just want to update a few minor elements,
>>> sometimes a big grandfather element...
>>>
>>> b) The id namespace issue, broke all my javascript $('divid') calls...
>>> there are workarounds (one just posted today,much cleaner than mine...
>>> thanks!) but I'd love to be able to turn this off, for some cases
>>> where duplicate id's won't matter (or is preferred).
>>>
>>> c) JSON is powerful, but returning a big complicated element in a json
>>> string is hurting performance (the escaping I assume server side, and
>>> the eval() clientside, as well as inflating the response size with all
>>> the escaping...) ... in some cases almost doubling the roundtrip time
>>> over my 5.0.6 solution (2 seconds vs. 4 seconds in Safari 3) and the
>>> difference is more severe in Firefox 3 (and potentially worse in
>>> IE?)..  I'd really love to be able to just return the raw markup
>>> again... instead of having to wrap it in a JSON object...  if someone
>>> knows how to do this beyond 5.0.6 PLEASE share!!!! Or if someone can
>>> point me to something I can decorate to skip the jsonobject creation,
>>> You'll be my hero!
>>>
>>> I should have put c) first... since that's the one I'm struggling
>>> most with...
>>> Steve
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>> -- 
>> http://thegodcode.net
>>
>>
>> ----------------------------------------------------
>
>

-- 
http://thegodcode.net


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: AJAX and the bleeding edge... minor pains...

[Steven Woolley <wo...@gmail.com>]

Thanks for the response Chris.  Rob Zeigler and myself dug in and  
figured out a temporary workaround... by overriding (the internal and  
subject to change) AjaxPartialResponseRenderer ... I didn't yet do  
the elegance of making the change based on the requested Content- 
Type, but that would be the logical next step.
The ugly part of the current hack, is that JSONObject is the  
container that is passed through the whole rendering pipeline for the  
AJAX stuff, which means we're not able to avoid passing it around,  
but we just use the MarkupWriter from AjaxPartialResponseRenderer to  
send to the Printstream instead of the JSONObject...

As for the JS side, I was doing that all with my own XHR code anyway,  
in a script that I include on the necessary pages/components.

That evil "eval" was actually giving me the beachball on some of the  
updates of larger more complex elements... so this was a must for  
that...
Thanks for you suggestions!  If you'd like me to file a JIRA I can  
probably do so (though my experience attempting to file bugs in the  
past was frustratingly painful...  what can I say, I have thin skin... )
Steve




On Apr 27, 2008, at 3:07:30, Chris Lewis wrote:

> Hi Steven,
>
> Regarding c):
>
> I was just about to respond telling you that you can return AJAXObject
> or an injected block (mark up), and it will work fine, and then I
> realized that even markup is wrapped in a JSON envelope. I don't think
> this can be changed without changing some T5 code - even if you could
> replace the relevant handlers via module contributions (probable), you
> still can't affect the JS that handles the responses (or maybe you can
> by providing your own in the expected package, like overriding
> validation messages...).
>
> Anyway that seems to be a legitimate issue and depending on  
> feedback you
> should consider adding a JIRA (or 3). In theory the problem could be
> solved by adding/seting a header in the T5 AJAX responses, stating  
> if it
> is raw markup or not. tapestry.js would check for this header and then
> behave accordingly (that is, no eval just a content update).  
> Actually I
> think the 'correct' way to do this would be to set a Content-Type of
> 'application/json' for json reponses
> (http://www.ietf.org/rfc/rfc4627.txt), or 'text/xml' for raw content.
>
> AJAX support has come a long way but it's still notably rough in some
> areas (and if you watch the dev or JIRA you've noticed that).  
> Anyway the
> fix I suggested shouldn't take too much work, and I could probably
> submit a patch if you can hack together a simple project that
> demonstrates the issue. I am quite interested in T5's AJAX support and
> really think that it could very much shield developers from dealing  
> with
> a lot of things, it should needs a bit more time in the oven.
>
> chris
>
> Steven Woolley wrote:
>> Like pouring ajax in my wounds?
>>
>> Trying to upgrade from 5.0.6, and upgrading all my ajax stuff is  
>> killing me...
>>
>> The issues I've run into (I'm shoehorning things a bit, by just
>> returning a block from an actionevent handler and grabbing the markup
>> from the jsonresponse with my AJAX response handler... in part  
>> because
>> of a) below) are:
>>
>> a) Nested zones?  I haven't been able to get them working... I have a
>> page where sometimes I just want to update a few minor elements,
>> sometimes a big grandfather element...
>>
>> b) The id namespace issue, broke all my javascript $('divid')  
>> calls...
>> there are workarounds (one just posted today,much cleaner than  
>> mine...
>> thanks!) but I'd love to be able to turn this off, for some cases
>> where duplicate id's won't matter (or is preferred).
>>
>> c) JSON is powerful, but returning a big complicated element in a  
>> json
>> string is hurting performance (the escaping I assume server side, and
>> the eval() clientside, as well as inflating the response size with  
>> all
>> the escaping...) ... in some cases almost doubling the roundtrip time
>> over my 5.0.6 solution (2 seconds vs. 4 seconds in Safari 3) and the
>> difference is more severe in Firefox 3 (and potentially worse in
>> IE?)..  I'd really love to be able to just return the raw markup
>> again... instead of having to wrap it in a JSON object...  if someone
>> knows how to do this beyond 5.0.6 PLEASE share!!!! Or if someone can
>> point me to something I can decorate to skip the jsonobject creation,
>> You'll be my hero!
>>
>> I should have put c) first... since that's the one I'm struggling  
>> most with...
>> Steve
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> -- 
> http://thegodcode.net
>
>
> ----------------------------------------------------

Re: AJAX and the bleeding edge... minor pains...

[Chris Lewis <ch...@bellsouth.net>]

Hi Steven,

Regarding c):

I was just about to respond telling you that you can return AJAXObject
or an injected block (mark up), and it will work fine, and then I
realized that even markup is wrapped in a JSON envelope. I don't think
this can be changed without changing some T5 code - even if you could
replace the relevant handlers via module contributions (probable), you
still can't affect the JS that handles the responses (or maybe you can
by providing your own in the expected package, like overriding
validation messages...).

Anyway that seems to be a legitimate issue and depending on feedback you
should consider adding a JIRA (or 3). In theory the problem could be
solved by adding/seting a header in the T5 AJAX responses, stating if it
is raw markup or not. tapestry.js would check for this header and then
behave accordingly (that is, no eval just a content update). Actually I
think the 'correct' way to do this would be to set a Content-Type of
'application/json' for json reponses
(http://www.ietf.org/rfc/rfc4627.txt), or 'text/xml' for raw content.

AJAX support has come a long way but it's still notably rough in some
areas (and if you watch the dev or JIRA you've noticed that). Anyway the
fix I suggested shouldn't take too much work, and I could probably
submit a patch if you can hack together a simple project that
demonstrates the issue. I am quite interested in T5's AJAX support and
really think that it could very much shield developers from dealing with
a lot of things, it should needs a bit more time in the oven.

chris

Steven Woolley wrote:
> Like pouring ajax in my wounds?
>
> Trying to upgrade from 5.0.6, and upgrading all my ajax stuff is killing me...
>
> The issues I've run into (I'm shoehorning things a bit, by just
> returning a block from an actionevent handler and grabbing the markup
> from the jsonresponse with my AJAX response handler... in part because
> of a) below) are:
>
> a) Nested zones?  I haven't been able to get them working... I have a
> page where sometimes I just want to update a few minor elements,
> sometimes a big grandfather element...
>
> b) The id namespace issue, broke all my javascript $('divid') calls...
> there are workarounds (one just posted today,much cleaner than mine...
> thanks!) but I'd love to be able to turn this off, for some cases
> where duplicate id's won't matter (or is preferred).
>
> c) JSON is powerful, but returning a big complicated element in a json
> string is hurting performance (the escaping I assume server side, and
> the eval() clientside, as well as inflating the response size with all
> the escaping...) ... in some cases almost doubling the roundtrip time
> over my 5.0.6 solution (2 seconds vs. 4 seconds in Safari 3) and the
> difference is more severe in Firefox 3 (and potentially worse in
> IE?)..  I'd really love to be able to just return the raw markup
> again... instead of having to wrap it in a JSON object...  if someone
> knows how to do this beyond 5.0.6 PLEASE share!!!! Or if someone can
> point me to something I can decorate to skip the jsonobject creation,
> You'll be my hero!
>
> I should have put c) first... since that's the one I'm struggling most with...
> Steve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>   

-- 
http://thegodcode.net


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org