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