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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> http://thegodcode.net >> >> >> ---------------------------------------------------- > > -- http://thegodcode.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
