incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Frederickx <dirk.frederi...@gmail.com>
Subject Re: ajax in v3.x -
Date Sun, 14 Jun 2009 21:20:19 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message