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 Sat, 27 Mar 2010 15:42:25 GMT
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
<andrew.r.jaquith@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
> <dirk.frederickx@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
>> <dirk.frederickx@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
>>> <andrew.r.jaquith@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
>>>> <dirk.frederickx@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 <janne.jalkanen@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
>>>>>
>>>>
>>>
>>
>

Mime
View raw message