Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of janne.jalkanen@ecyrd.com
 designates 193.64.5.122 as permitted sender)
Message-Id: <A509FFCF-3B3D-4ACE-A20A-6C889BA3EAE9@ecyrd.com>
From: Janne Jalkanen <janne.jalkanen@ecyrd.com>
To: jspwiki-dev@incubator.apache.org
In-Reply-To: <99C98E98-082F-4998-806A-14ABBE8F011A@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: ajax in v3.x -
Date: Mon, 15 Jun 2009 11:17:51 +0300
References: <15cc92000906140719h3432a0e1i3d1264cbfc714a51@mail.gmail.com>
 <99C98E98-082F-4998-806A-14ABBE8F011A@gmail.com>


There's an advantage for using JSPs if the response needs to be  
templated.  I'm not saying we need it at this moment, but sometimes  
plain XHTML is not good enough, since the template writer might need  
to rewrite it for his needs.  In which case we don't want to force  
them to rewrite the ActionBean.  In general, returning non- 
templateable XHTML could be considered bad, since it forces a  
particular content structure, which might not go well with your  
template ideas.

So I wouldn't dismiss it so readily. We need to figure out in which  
cases (if any) it actually is useful to template the response.   
Reference:

http://stripesframework.org/display/stripes/AJAX+even+easier


/Janne

On 15 Jun 2009, at 06:03, Andrew Jaquith wrote:

> Dirk-- some quick comments before I go off-grid for a few weeks:
>
> I want to get away from using JSPs as part of AJAX response  
> processing. Instead, it would be cleaner to use the response  
> (Resolution) returned by Stripes without routing responses through  
> JSPs. This could be done in one of two ways. The event handler  
> method could return:
>
> 1) a StreamingResolution that contains the XHTML. The event method  
> would generate the XHTML. All the client does is insert it into the  
> DOM.
>
> 2) a JavaScriptResolution that contains the JSON objects, which the  
> client would eval, create elements for, and insert into the DOM.
>
> (2) is a little more complex on the client side, but probably less  
> taxing for the server. This would be a good way to do ajaxSearch.
>
> As for your other comments: the live preview feels like it should be  
> a function of editing, and thus EditActionBean. But your instinct  
> was basically right -- it should be a core funtion, not a template- 
> specific thing.
>
> Andrew
>
> On Jun 14, 2009, at 10:19, Dirk Frederickx  
> <dirk.frederickx@gmail.com> 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