incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject Re: Seperate thread on JSON and AJAX
Date Sun, 07 Mar 2010 23:35:35 GMT
Replies inline.
> I do care.  Passing "text/javascript' back to the client, will trigger
> a javascript execution on the client.
> While this can be usefull for very complex client functionality, it is
> also vulnerable to xss.
>
> In this particular case, I would prefer not to return a
> 'text/javascript' message, but rather return 'application/json' as
> content-type.
> Just return the object with 3 strings, the handling is the same:
>
> { 'errors' : html-string, 'messages': html-string,  'result': html-string }

No problem, then. Again, I don't really care about how we do this, and
am open to suggestions. If JSON works better and is more secure, then
let's do that. What you've suggested looks very sensible.

> I do not understand why a simple 'buildJSON' is not part of the API of
> their JavaScriptResolution class.

Good question. But it's not, so we will have to do something, then. :)
 How hard can it be? Would it be as simple as the example you gave?
(Maybe just escape all of the single quotes in the three HTML
strings?)

> Agree. The possibility of a callback function provides lots of flexibility.
> I would also suggest to add the div-target in the callback, like this:
>
> callback( eventResponse, divTarget )

I thought about that, but didn't do it for some reason. But it makes sense.

> One more thing.
> I noticed that the call to Stripes.submitformEvent is coded inside the JSP.
> In the past, I've tried to keep the JS dependency in the HTML as
> little as  possible,
> and keep all javascript inside the *.js files.
>
> This means that the AJAX handlers are injected in the DOM-tree during
> page-load, by the javascript itself.
> It also means that if javascript is not on, the page falls back to a
> regular html links, iso of AJAX calls.

Yes. I wanted to keep the Stripes.submitFormEvent syntax simple so
that it would be easy to add as inline script. The advantage of doing
it directly in the JSP (as opposed to adding click handlers) is that
it's visually very easy to see what's supposed to happen. As a
counter-example, consider how long it took to figure out why
page-edits would "double-post". It's because there was an event
handler that was attached to the edit form -- and that wasn't at all
obvious to me or Harry.

I understand the point you are making, though, and I can see some
advantages, too. I think we should defer this particular discussion
until after Alpha, if that's ok with you.

> The 'result' property of eventResponse is a string with HTML. Which is
> perfectly ok.

Ok, cool. So with all three properties as HTML strings, this should be
pretty easy to convert from a JavaScript-style resolution to JSON.
I'll do a little experimentation with this.

Andrew

Mime
View raw message