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
>>>
>>
>
