incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Frederickx <>
Subject Re: Seperate thread on JSON and AJAX
Date Sun, 14 Mar 2010 13:02:32 GMT
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 ?


On Sat, Mar 13, 2010 at 4:38 PM, Dirk Frederickx
<> 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
> <> 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
>> <> 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 <>
>>>>>> I do not understand why a simple 'buildJSON' is not part of the API
>>>>>> 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

View raw message