incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: ajax in v3.x -
Date Sun, 14 Jun 2009 21:57:30 GMT

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.Jalkanen@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
>>>
>>
>>


Mime
View raw message