Re: ajax in v3.x -

[Janne Jalkanen]

I prefer 3 since it has several advantages:
1) The ability to send in data you received (otherwise you need to  
dismantle the JSON object into POST params, which can be non-trivial)
2) Dynamic items (not just what you happened to hardcode into the  
ActionBean)
3) Richer formats (you can pass arrays, hashmaps and all primitives)

A TypeConverter might also be possible, but might be difficult to  
build for all cases. Or just simply creating a  
getRequest().getBodyAsJSON() or something, bypassing Stripes' own  
binding completely.

I'm happy that we're already using 3, so we should definitely keep  
using it and NOT refactor it away. The fact that it's not stripes- 
native should not hold us back, but we should figure out how to  
incorporate JSON into Stripes better. (I find this actually a major  
flaw in Stripes; this stuff should be built-in.)

/Janne

On 15 Jun 2009, at 05:13, Andrew Jaquith wrote:

I don't quite understand how JSON client---->server works. Is it  
part of a post body? If so, the best way to handle this might be via  
a TypeConverter. An Interceptor would be decent also, but you'd have  
to remember to add annotations to either the event handler methods  
or the mutators. That's valid also.

But better than this would simply be to the (light) refactoring  
needed to reduce the need for (3). The upload progress bar might be  
one area we can't refactor easily, but then I don't understand hwo  
that particular code works yet.

I'm off my laptop for the next 2 weeks (honeymoon); otherwise I'd  
normally have better-researched anwers. ;)

Andrew

On Jun 14, 2009, at 17:57, Janne Jalkanen <janne.jalka...@ecyrd.com>  
wrote:


A pretty neat way would be to build a JSONInterceptor, which would  
detect custom annotations from methods, so that you could mark a  
method with

@JSONMethod( query=String )
@HandlesEvent("getSuggestions")
public Resolution getSuggestions()
{
 return new  
JavascriptResolution( buildArrayListForSuggestions( getQuery() ) );
}

Which would just simply extract the query parameter from the JSON  
and place it into the bean using setQuery(String).  We could still  
use jabsorb's class hinting mechanism.

/Janne

On Jun 15, 2009, at 00:20 , Dirk Frederickx wrote:

Currently we are using 1) and 3).

1)  FindContent.jsp, LivePreview and Categories
3)  Quick-Navigation popup, plain editor link suggestion popup and
attachement-upload-progress.

As far as I know, 2) is not used today.

For 3) we need to agree whether we stay with the current rpc  
bridge or
change it.

dirk

On Sun, Jun 14, 2009 at 11:10 PM, Janne Jalkanen
<janne.jalka...@ecyrd.com>wrote:


There are three cases:

1) Call with regular HTTP params (GET or POST), get back XHTML
2) Call with regular HTTP params (GET or POST), get back JSON
3) Call with JSON params (in POST), get back JSON.

Are we using case 3 anywhere?  If no, then we don't need json-rpc  
(or to be
precise, jabsorb these days) at all, since Stripes can serialize  
stuff into
a JSON object. Stripes cannot, however, parse JSON, so option 3  
requires a
JSON parsing library, such as jabsorb.

Also, this relates a bit to our external API thinking: currently,  
we
support XML-RPC, but that's a fairly old and clunky API. I would  
definitely
like to support a REST-like interface, but it needs a bit more  
thinking.
Considering that there's probably going to be quite a bit of  
overlap
between our JSON APIs, our XML-RPC APIs and our REST APIs, it  
might make
sense to collapse them into one - like just sticking to sending  
JSON back
and forth.

There is some advantage in sending also JSON down the line - the  
format is
simple and expressive, and allows you to get an object you  
received, modify
it, and return it.  So we might consider 3 as a future option.   
Or RFC 5023
with extensions.

/Janne


On Jun 14, 2009, at 17:19 , Dirk Frederickx wrote:

Andrew, e.a.,

Some notes on the use of ajax in the template jsp's and the  
related
javascript.
I'll check in some updates to the javascript with new handlers  
to support
ajax.


There are 2 cases:

1) AJAX-calls to retrieve xhtml snippets.

In v2.x this is done through some jsp-helper-pages which return
the xhtml snippets. (not full html pages)

It is currenlty used for retrieving the lucene search results  
for the
FindContent.jsp (old AJAXSearch.jsp);  the live-preview function
during editing (old AJAXPreview.jsp); and the %%category popup
to retrieve the list of referring-pages. (old AJAXCategories.jsp)

Reading the note of Andrew, we would like to move to stripes'  
event
handlers
to deliver these ajax requests. In most cases, we'd still need  
some jsp's
to finally
deliver the returned xhtml.

Notice that the returned xhtml in these
cases should only return a small snippet, and not a complete
jspwiki-page.
(with header, footer, favorites, etc...)

Client side:

/* new api */
Wiki.ajax( url (==> of the Stripes ActionBean), {
action: ==> Stripes event to be invoked
params: ==> FORM-element or javascript-object, will be converted  
to
&parm=value
update: ==> optional, DOM-element to update with xhtml snippet
onComplete: ==> callback handler on reception of the html response
});

Example:
Wiki.ajax('Search.jsp', {
action: 'ajaxSearch',
params: { query:'search-text', maxItems:20 },
update: $('dom-element'),
onComplete:function(){
alert('ajax - done');
}
});
or
Wiki.ajax('Search.jsp', {
action: 'ajaxSearch',
          params:$('searchform2'),  ==> automatically retrieve  
params
from the form
update: $('searchResult2'),
onComplete:function(){
alert('ajax - done');
}
});


Notes/Questions:

* The current ajaxSearch event invokes the full FindContent.jsp.
It rather should return the search-result xhtml snippet inside
#searchResult2.
In v2.x, the FindContent.jsp invoked/included the
AJAXSearch.jsp just to deliver that snippet of search-results.
I'd suggest to revert back to that solution, but give it a better
name:
FindContent, invokinkg FindResult.jsp


* 'live-preview' : I suggest to promote this generic function to a
top-level jsp, rather than an template jsp. We could also opt  
for an
extra AJAX-event on the existing ViewActionBean


* AJAXCategories : This jsp is actually only invoking a jspwiki- 
plugin.
Probably this would better be a JSON based ajax event.  (see  
below)
Or, we could consider to build a generic solution to invoke
asynchronous
any of the installed plugins ?


2) AJAX-calls to retrieve JSON objects
(eg. upload progress tracking, find partial page matches)

In v2.x this uses server-side the json-rpc.

We used this for retrieving a list of pagenames with partial  
match in the
quick-navigation drop-down (search.findPages), populate the  
suggestion
popup during edit (search.getSuggestions) and to retrieve the  
progress
value when upload attachements. (progressTracker.getProgress)

Client-side:

//v2.x example
Wiki.jsonrpc('search.findPages', ['Janne',20], function(result){
//do something with the result json object
});

Notes:
* We'll still need to select java json tools to read/write  
server side
the JSON objects. Unless we'll stick to json-rpc.

* The findPages and getSuggestion events (currently in
search.SearchManager)
could be added to the SearchActionBean, to keep all kinds of  
searching
together.

* The getProgress could be added to AttachmentActionBean


dirk