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