incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject Re: ajax in v3.x -
Date Mon, 15 Jun 2009 13:23:19 GMT
Yep, using a ForwardResolution in combination with a JSP is the basic  
idea. It is solution #3. I didn't mention it because it would have  
made me re-open the debate about where to put content JSPs. In  
particular, I'd like to put there kinds of JSPs (AJAX response JSPs)  
in WEB-INF.

Assuming we don't do that just yet, here's what the code might look  
like:

@HandlesEvent("ajaxSearch")
public Resolution ajaxSearch()
{
...code goes here...
     Map<String,String> map = templateManager.getTemplateMap();
(I can't remember the exact method name, but I just added it...)
     return new ForwardResolution(map.get("/ajax/SearchResponse");
}

The map resolves the path of the template-specific JSP, while the  
ForwardResolution passes through the current ActionBean's state.

Andrew

On Jun 15, 2009, at 4:17, Janne Jalkanen <janne.jalkanen@ecyrd.com>  
wrote:

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

Mime
View raw message