You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Dirk Frederickx <di...@gmail.com> on 2010/03/07 22:41:13 UTC
Seperate thread on JSON and AJAX
<<<question/reply from dirk/andrew copied from separate mail thread>>>
> 4)
> JSON
> I noticed that JSON calls, used by the new Stripes.submitFormEvent, requires
> the 'evalResponse' to be set to 'true'.
> This is because the ajax bean returns a piece of executable javascript;
> rather than a passive json object.
> (this is generated via the Stripes "JavaScriptResolution" class.
>
> I'd rather prefer that the server returns a passive JSON object, to avoid JS
> injection security issues.
> In this case, it should just return a simple string: { result:"long string"
> } There is no need for more complex data passing.
> WDYT ?
I'm glad we are talking about this. I hoped we would sooner or later,
because you are our resident JavaScript guru. :)
The goal with Stripes.submitFormEvent was to cause a StripesActionBean
form event to be called, and to provide way for any errors or messages
(plus the response) to propagate back to the client. We call the
ActionBean event by submitting the form in the background (AJAX) and
supplying an event to execute. The response object has three
properties:
- the response itself (which for simplicity's sake I have been
assuming would ALWAYS be HTML)
- the "errors" string (which we generate in the same manner as the s:errors tag)
- the "messages" string (which we generate in the same manner as the
s:messages tag)
All three of these are concatenated together, wrapped in a <div>, and
injected into the div we want. That means any Stripes validation
errors or messages we get from the AJAX call are propagated back to
the browser. Neat, huh?
If you want to see this in action, by the way, just run the Installer
and try to configure the LDAP userdatabase. Because you (probably!)
don't have an LDAP server running locally, when you test the
connections you'll get an error. That error is propagated back and
displayed via Stripes.submitFormEvent.
Now, in terms of HOW that information is propagated back, I chose to
send back a JavaScript statement that could be eval'ed. This is
accomplished by the EventResolution class, which essentially wraps the
JavaScriptResolution response type, and does some nice formatting of
the errors and messages stuff. I did this because it was the simplest,
fastest way I knew how.
I don't really care how the information is propagated back to the
client. If JSON is easier, that's fine. I'd ask that if you do this,
please make appropriate changes to EventResolution and
Stripes.submitFormEvent so that we can do it everywhere.
*******
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 }
Also, note that the returned 'text/javascript' is immediately executed
at the client side.
This will generate unnecessary GLOBAL javascript vars on the client
for each ajax request.
*******
Some suggested guidance if you want to change the "message transport" to JSON:
- EventResolution, NOW, wraps a JavaScriptResolution that emits the JS
object. You will, instead, want to wrap and return a
StreamingResolution that emits an JSON-notated object.
Here's the JavaDoc for StreamingResolution:
http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/action/StreamingResolution.html
*******
In the current svn you are using the JavaScriptBuilder class; the
JavaScriptResolution class would be a slight simplification.
While the included Stripes classes provide poweful functionalities to
convert JAVA to JSON objects,
they unfortunately always package the JSON into some unnecessary
javascript enclosing.
Here is what Stripes returns:
var eventResponse;
var _sj_13986377 = {errors:null, messages:null, results:" .... "};
eventResponse = _sj_13986377;
eventResponse;
I do not understand why a simple 'buildJSON' is not part of the API of
their JavaScriptResolution class.
*******
- If possible, I'd like to preserve the default client-side behavior
of Stripes.submitFormEvent -- where if there is NO callback function
supplied, the default behavior is to concatenate the errors, messages,
and response together and inject the whole thing into the target div.
But if there IS a supplied callback function, we call that instead
(which can do whatever it wants).
*******
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 )
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.
EG, in the EdititorLayout.jsp you find following snippet:
<wiki:Tab id="preview" titleKey="preview.tab" accesskey="p"
onclick="Stripes.submitFormEvent('editform', 'preview',
'previewContent', null);">
<div class="information">
<fmt:message key="preview.info" />
</div>
<div id="previewContent"></div>
</wiki:Tab>
Instead we could better go for this:
<wiki:Tab id="preview" titleKey="preview.tab" accesskey="p"
url=" ...the preview url : Edit.jsp?preview&... " >
<div class="information">
<fmt:message key="preview.info" />
</div>
<div id="previewContent"></div>
</wiki:Tab>
During page-load, javascript would then inject onclick handers
overwriting the default behaviour of the ajaxed links.
For tabs, this could probably be build in a generic way, automatically
recognising the parent form, the enclosed target-elements, etc....
Anyway, in the current state we are in, this would not be on my priority list.
But in general, let's try to keep the amount of javascript in the jsp
pages as minimal as possible.
*******
- If it makes sense, maybe the "response" property of eventResponse
should be a JavaScript object instead of a string? If so, the default
behavior of Stripes.submitFormEvent (when there is no callback method
supplied), should safely coerce the response JS object into a String.
(That is a guess...)
******
The 'result' property of eventResponse is a string with HTML. Which is
perfectly ok.
******
dirk
Re: Seperate thread on JSON and AJAX
Posted by Andrew Jaquith <an...@gmail.com>.
Dirk -- I just picked up your changes to the AJAX/JSON code. Nice job.
As it happens, I'd been working up a fix independently. I checked some
small modifications in just now. Really, the only change is renaming
EventResolution to AjaxResolution, which I think more accurately
communicates what the class is trying to do. It also neatly matches
the AjaxEvent, which is a good thing too.
Again, nice work.
Andrew
On Sun, Mar 14, 2010 at 10:28 AM, Andrew Jaquith
<an...@gmail.com> wrote:
> Hey Dirk --
>
> This relates to the discussion we have been having about how best to
> propagate results back to the client. This issue should take care of
> itself soon. Once we switch EventResolution over to marshal objects
> using JSON (rather than via JavaScriptBuilder), this should make what
> you want possible.
>
> I can try taking a peek at this today. Your (off-list) note to me was
> very helpful -- I will try what you suggested.
>
> Andrew
>
> On Sun, Mar 14, 2010 at 9:02 AM, Dirk Frederickx
> <di...@gmail.com> wrote:
>> Andrew, Janne,
>>
>> I did some further investigation on the SearchActionBean class, in
>> particular trying to get the "quickSearch" event working. (used to
>> generate the quick-navigation search drop down)
>>
>> I was surprised that this event doesn't return a JSON object (like it
>> used to do in SearchManager class ) but now returns an HTML snippet ?
>>
>> In general, I would expect ajax-calls to return preferably
>> json-data-objects. At the client-side, this data can be injected in
>> the DOM tree.
>>
>> In case ajax-calls need to return html snippets, I suggest to always
>> pass them back via JSP's. This allows template writers to modify
>> representation to their needs.
>>
>> = = = =
>>
>> When trying to return an json object by means of the EventResolution
>> class, I ran into some problems. Can some of you java-guru-s plse
>> help me out...
>>
>> return new EventResolution( getContext(), m_results );
>>
>> The m_result apparenty doesn't get properly converted to a json
>> object. It seems that the EventResolution$Result class lose somehow
>> the type info ?
>>
>>
>>>>>>
>> dirk
>>
>>
>> On Sat, Mar 13, 2010 at 4:38 PM, Dirk Frederickx
>> <di...@gmail.com> wrote:
>>> Andrew,
>>>
>>>
>>> Why not use the org.json.JSONObject class, which is already part of
>>> the jspwiki package. (part of the jsonrpc bridge)
>>> It keeps the json processing very simple. Also the client-side
>>> processing becomes very simple.
>>> WDYT ?
>>>
>>>
>>> public EventResolution( ActionBeanContext context, Object... objects )
>>> {
>>> m_jsonobject = new JSONObject( new Result(context, objects) );
>>> }
>>>
>>> public void execute( HttpServletRequest request,
>>> HttpServletResponse response ) throws Exception
>>> {
>>> response.setContentType( "application/json" );
>>> m_jsonobject.write( response.getWriter() );
>>> response.flushBuffer();
>>> }
>>>
>>>
>>>
>>> dirk
>>>
>>>
>>> On Tue, Mar 9, 2010 at 1:13 AM, Andrew Jaquith
>>> <an...@gmail.com> wrote:
>>>> I'd normally rather "wrap" the JavaScriptResolution class than extend it.
>>>>
>>>> But taking a look at the code, extension might be the only way to do
>>>> it. Of course, we could also offer to contribute a "JSONResolution"
>>>> back to the Stripes folks to ensure that it stays current.
>>>>
>>>> Anybody want to take a whack at creating JSONResolution? I'd offer,
>>>> but I'd like to help Dirk get some other JS issues taken care of
>>>> first, and get rid of a few more unit test failures.
>>>>
>>>> Andrew
>>>>
>>>> On Mon, Mar 8, 2010 at 8:33 PM, Dirk Frederickx
>>>> <di...@gmail.com> wrote:
>>>>> Actually, the Stripes JavascriptResolution has already all the ingredients.
>>>>> In only lacks the API to build a JSON object (avoiding the client
>>>>> eval() ) as a complementary API to the cuurent build of the javascript
>>>>> snippet.
>>>>>
>>>>> Maybe we can extend the stripes implementation ?
>>>>>
>>>>>
>>>>> dirk
>>>>>
>>>>>
>>>>> On Mon, Mar 8, 2010 at 6:18 PM, Janne Jalkanen <ja...@ecyrd.com> wrote:
>>>>>>>> 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?)
>>>>>>
>>>>>> Writing a JSONResolution is really simple, BTW. Have done it for corporate purposes (so can't cut-n-paste the code, unfortunately, and partly therefore would prefer if someone else did it). The reason why Stripes does it the way it does is because this way it can marshal e.g. circular references and other goodies. So it's a very generic system that works with pretty much everything, and can be eval()ed nicely. However, doing eval() is generally discouraged (it's a potential security hole) and therefore many JS libs are already using either the native JSON parser or roll their own.
>>>>>>
>>>>>> /Janne
>>>>>
>>>>
>>>
>>
>
Re: Seperate thread on JSON and AJAX
Posted by Andrew Jaquith <an...@gmail.com>.
Hey Dirk --
This relates to the discussion we have been having about how best to
propagate results back to the client. This issue should take care of
itself soon. Once we switch EventResolution over to marshal objects
using JSON (rather than via JavaScriptBuilder), this should make what
you want possible.
I can try taking a peek at this today. Your (off-list) note to me was
very helpful -- I will try what you suggested.
Andrew
On Sun, Mar 14, 2010 at 9:02 AM, Dirk Frederickx
<di...@gmail.com> wrote:
> Andrew, Janne,
>
> I did some further investigation on the SearchActionBean class, in
> particular trying to get the "quickSearch" event working. (used to
> generate the quick-navigation search drop down)
>
> I was surprised that this event doesn't return a JSON object (like it
> used to do in SearchManager class ) but now returns an HTML snippet ?
>
> In general, I would expect ajax-calls to return preferably
> json-data-objects. At the client-side, this data can be injected in
> the DOM tree.
>
> In case ajax-calls need to return html snippets, I suggest to always
> pass them back via JSP's. This allows template writers to modify
> representation to their needs.
>
> = = = =
>
> When trying to return an json object by means of the EventResolution
> class, I ran into some problems. Can some of you java-guru-s plse
> help me out...
>
> return new EventResolution( getContext(), m_results );
>
> The m_result apparenty doesn't get properly converted to a json
> object. It seems that the EventResolution$Result class lose somehow
> the type info ?
>
>
>>>>>
> dirk
>
>
> On Sat, Mar 13, 2010 at 4:38 PM, Dirk Frederickx
> <di...@gmail.com> wrote:
>> Andrew,
>>
>>
>> Why not use the org.json.JSONObject class, which is already part of
>> the jspwiki package. (part of the jsonrpc bridge)
>> It keeps the json processing very simple. Also the client-side
>> processing becomes very simple.
>> WDYT ?
>>
>>
>> public EventResolution( ActionBeanContext context, Object... objects )
>> {
>> m_jsonobject = new JSONObject( new Result(context, objects) );
>> }
>>
>> public void execute( HttpServletRequest request,
>> HttpServletResponse response ) throws Exception
>> {
>> response.setContentType( "application/json" );
>> m_jsonobject.write( response.getWriter() );
>> response.flushBuffer();
>> }
>>
>>
>>
>> dirk
>>
>>
>> On Tue, Mar 9, 2010 at 1:13 AM, Andrew Jaquith
>> <an...@gmail.com> wrote:
>>> I'd normally rather "wrap" the JavaScriptResolution class than extend it.
>>>
>>> But taking a look at the code, extension might be the only way to do
>>> it. Of course, we could also offer to contribute a "JSONResolution"
>>> back to the Stripes folks to ensure that it stays current.
>>>
>>> Anybody want to take a whack at creating JSONResolution? I'd offer,
>>> but I'd like to help Dirk get some other JS issues taken care of
>>> first, and get rid of a few more unit test failures.
>>>
>>> Andrew
>>>
>>> On Mon, Mar 8, 2010 at 8:33 PM, Dirk Frederickx
>>> <di...@gmail.com> wrote:
>>>> Actually, the Stripes JavascriptResolution has already all the ingredients.
>>>> In only lacks the API to build a JSON object (avoiding the client
>>>> eval() ) as a complementary API to the cuurent build of the javascript
>>>> snippet.
>>>>
>>>> Maybe we can extend the stripes implementation ?
>>>>
>>>>
>>>> dirk
>>>>
>>>>
>>>> On Mon, Mar 8, 2010 at 6:18 PM, Janne Jalkanen <ja...@ecyrd.com> wrote:
>>>>>>> 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?)
>>>>>
>>>>> Writing a JSONResolution is really simple, BTW. Have done it for corporate purposes (so can't cut-n-paste the code, unfortunately, and partly therefore would prefer if someone else did it). The reason why Stripes does it the way it does is because this way it can marshal e.g. circular references and other goodies. So it's a very generic system that works with pretty much everything, and can be eval()ed nicely. However, doing eval() is generally discouraged (it's a potential security hole) and therefore many JS libs are already using either the native JSON parser or roll their own.
>>>>>
>>>>> /Janne
>>>>
>>>
>>
>
Re: Seperate thread on JSON and AJAX
Posted by Dirk Frederickx <di...@gmail.com>.
Andrew, Janne,
I did some further investigation on the SearchActionBean class, in
particular trying to get the "quickSearch" event working. (used to
generate the quick-navigation search drop down)
I was surprised that this event doesn't return a JSON object (like it
used to do in SearchManager class ) but now returns an HTML snippet ?
In general, I would expect ajax-calls to return preferably
json-data-objects. At the client-side, this data can be injected in
the DOM tree.
In case ajax-calls need to return html snippets, I suggest to always
pass them back via JSP's. This allows template writers to modify
representation to their needs.
= = = =
When trying to return an json object by means of the EventResolution
class, I ran into some problems. Can some of you java-guru-s plse
help me out...
return new EventResolution( getContext(), m_results );
The m_result apparenty doesn't get properly converted to a json
object. It seems that the EventResolution$Result class lose somehow
the type info ?
>>>>
dirk
On Sat, Mar 13, 2010 at 4:38 PM, Dirk Frederickx
<di...@gmail.com> wrote:
> Andrew,
>
>
> Why not use the org.json.JSONObject class, which is already part of
> the jspwiki package. (part of the jsonrpc bridge)
> It keeps the json processing very simple. Also the client-side
> processing becomes very simple.
> WDYT ?
>
>
> public EventResolution( ActionBeanContext context, Object... objects )
> {
> m_jsonobject = new JSONObject( new Result(context, objects) );
> }
>
> public void execute( HttpServletRequest request,
> HttpServletResponse response ) throws Exception
> {
> response.setContentType( "application/json" );
> m_jsonobject.write( response.getWriter() );
> response.flushBuffer();
> }
>
>
>
> dirk
>
>
> On Tue, Mar 9, 2010 at 1:13 AM, Andrew Jaquith
> <an...@gmail.com> wrote:
>> I'd normally rather "wrap" the JavaScriptResolution class than extend it.
>>
>> But taking a look at the code, extension might be the only way to do
>> it. Of course, we could also offer to contribute a "JSONResolution"
>> back to the Stripes folks to ensure that it stays current.
>>
>> Anybody want to take a whack at creating JSONResolution? I'd offer,
>> but I'd like to help Dirk get some other JS issues taken care of
>> first, and get rid of a few more unit test failures.
>>
>> Andrew
>>
>> On Mon, Mar 8, 2010 at 8:33 PM, Dirk Frederickx
>> <di...@gmail.com> wrote:
>>> Actually, the Stripes JavascriptResolution has already all the ingredients.
>>> In only lacks the API to build a JSON object (avoiding the client
>>> eval() ) as a complementary API to the cuurent build of the javascript
>>> snippet.
>>>
>>> Maybe we can extend the stripes implementation ?
>>>
>>>
>>> dirk
>>>
>>>
>>> On Mon, Mar 8, 2010 at 6:18 PM, Janne Jalkanen <ja...@ecyrd.com> wrote:
>>>>>> 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?)
>>>>
>>>> Writing a JSONResolution is really simple, BTW. Have done it for corporate purposes (so can't cut-n-paste the code, unfortunately, and partly therefore would prefer if someone else did it). The reason why Stripes does it the way it does is because this way it can marshal e.g. circular references and other goodies. So it's a very generic system that works with pretty much everything, and can be eval()ed nicely. However, doing eval() is generally discouraged (it's a potential security hole) and therefore many JS libs are already using either the native JSON parser or roll their own.
>>>>
>>>> /Janne
>>>
>>
>
Re: Seperate thread on JSON and AJAX
Posted by Dirk Frederickx <di...@gmail.com>.
Andrew,
Why not use the org.json.JSONObject class, which is already part of
the jspwiki package. (part of the jsonrpc bridge)
It keeps the json processing very simple. Also the client-side
processing becomes very simple.
WDYT ?
public EventResolution( ActionBeanContext context, Object... objects )
{
m_jsonobject = new JSONObject( new Result(context, objects) );
}
public void execute( HttpServletRequest request,
HttpServletResponse response ) throws Exception
{
response.setContentType( "application/json" );
m_jsonobject.write( response.getWriter() );
response.flushBuffer();
}
dirk
On Tue, Mar 9, 2010 at 1:13 AM, Andrew Jaquith
<an...@gmail.com> wrote:
> I'd normally rather "wrap" the JavaScriptResolution class than extend it.
>
> But taking a look at the code, extension might be the only way to do
> it. Of course, we could also offer to contribute a "JSONResolution"
> back to the Stripes folks to ensure that it stays current.
>
> Anybody want to take a whack at creating JSONResolution? I'd offer,
> but I'd like to help Dirk get some other JS issues taken care of
> first, and get rid of a few more unit test failures.
>
> Andrew
>
> On Mon, Mar 8, 2010 at 8:33 PM, Dirk Frederickx
> <di...@gmail.com> wrote:
>> Actually, the Stripes JavascriptResolution has already all the ingredients.
>> In only lacks the API to build a JSON object (avoiding the client
>> eval() ) as a complementary API to the cuurent build of the javascript
>> snippet.
>>
>> Maybe we can extend the stripes implementation ?
>>
>>
>> dirk
>>
>>
>> On Mon, Mar 8, 2010 at 6:18 PM, Janne Jalkanen <ja...@ecyrd.com> wrote:
>>>>> 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?)
>>>
>>> Writing a JSONResolution is really simple, BTW. Have done it for corporate purposes (so can't cut-n-paste the code, unfortunately, and partly therefore would prefer if someone else did it). The reason why Stripes does it the way it does is because this way it can marshal e.g. circular references and other goodies. So it's a very generic system that works with pretty much everything, and can be eval()ed nicely. However, doing eval() is generally discouraged (it's a potential security hole) and therefore many JS libs are already using either the native JSON parser or roll their own.
>>>
>>> /Janne
>>
>
Re: Seperate thread on JSON and AJAX
Posted by Andrew Jaquith <an...@gmail.com>.
I'd normally rather "wrap" the JavaScriptResolution class than extend it.
But taking a look at the code, extension might be the only way to do
it. Of course, we could also offer to contribute a "JSONResolution"
back to the Stripes folks to ensure that it stays current.
Anybody want to take a whack at creating JSONResolution? I'd offer,
but I'd like to help Dirk get some other JS issues taken care of
first, and get rid of a few more unit test failures.
Andrew
On Mon, Mar 8, 2010 at 8:33 PM, Dirk Frederickx
<di...@gmail.com> wrote:
> Actually, the Stripes JavascriptResolution has already all the ingredients.
> In only lacks the API to build a JSON object (avoiding the client
> eval() ) as a complementary API to the cuurent build of the javascript
> snippet.
>
> Maybe we can extend the stripes implementation ?
>
>
> dirk
>
>
> On Mon, Mar 8, 2010 at 6:18 PM, Janne Jalkanen <ja...@ecyrd.com> wrote:
>>>> 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?)
>>
>> Writing a JSONResolution is really simple, BTW. Have done it for corporate purposes (so can't cut-n-paste the code, unfortunately, and partly therefore would prefer if someone else did it). The reason why Stripes does it the way it does is because this way it can marshal e.g. circular references and other goodies. So it's a very generic system that works with pretty much everything, and can be eval()ed nicely. However, doing eval() is generally discouraged (it's a potential security hole) and therefore many JS libs are already using either the native JSON parser or roll their own.
>>
>> /Janne
>
Re: Seperate thread on JSON and AJAX
Posted by Dirk Frederickx <di...@gmail.com>.
Actually, the Stripes JavascriptResolution has already all the ingredients.
In only lacks the API to build a JSON object (avoiding the client
eval() ) as a complementary API to the cuurent build of the javascript
snippet.
Maybe we can extend the stripes implementation ?
dirk
On Mon, Mar 8, 2010 at 6:18 PM, Janne Jalkanen <ja...@ecyrd.com> wrote:
>>> 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?)
>
> Writing a JSONResolution is really simple, BTW. Have done it for corporate purposes (so can't cut-n-paste the code, unfortunately, and partly therefore would prefer if someone else did it). The reason why Stripes does it the way it does is because this way it can marshal e.g. circular references and other goodies. So it's a very generic system that works with pretty much everything, and can be eval()ed nicely. However, doing eval() is generally discouraged (it's a potential security hole) and therefore many JS libs are already using either the native JSON parser or roll their own.
>
> /Janne
Re: Seperate thread on JSON and AJAX
Posted by Janne Jalkanen <ja...@ecyrd.com>.
>> 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?)
Writing a JSONResolution is really simple, BTW. Have done it for corporate purposes (so can't cut-n-paste the code, unfortunately, and partly therefore would prefer if someone else did it). The reason why Stripes does it the way it does is because this way it can marshal e.g. circular references and other goodies. So it's a very generic system that works with pretty much everything, and can be eval()ed nicely. However, doing eval() is generally discouraged (it's a potential security hole) and therefore many JS libs are already using either the native JSON parser or roll their own.
/Janne
Re: Seperate thread on JSON and AJAX
Posted by Andrew Jaquith <an...@gmail.com>.
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