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
<[email protected]> 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
> <[email protected]> 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
>> <[email protected]> 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
>>> <[email protected]> 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
>>>> <[email protected]> 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 <[email protected]> 
>>>>> 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
>>>>>
>>>>
>>>
>>
>

Reply via email to