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 Mon, 15 Jun 2009 20:03:33 GMT

No, it's not solution 3. In solution 3, we always return a JSON object  
(that is, JavascriptResolution).  Only in the cases where we wish to  
allow the template writer to change the output to suit his template  
would we use a JSP template.  And in that case, it does not make sense  
to put them under WEB-INF because then you will end up with template  
files all over the place (because you can't put images or scripts  
under WEB-INF, unless you build your own infra to handle that, and  
that's just dumb).

/Janne

On 15 Jun 2009, at 16:23, Andrew Jaquith wrote:

> 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