Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of andrew.r.jaquith@gmail.com
 designates 209.85.221.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:x-mailer:mime-version:subject:date
         :references;
        b=iE0oNc3ohrluvFo1j5dSOFZyAISSpKn70B3NpMKklqT2Nc6wIA0vgoC16j+EAxGzUR
         pxE/6H4jMSAHxms9s1i1e5PIxbp24rvWcafVjAxvfieCPNqv9E5Bq/KLR/oqblNdxrGN
         vx/z3vU7YxvVXds4/pcM85WrnPar8ZfEUUqK8=
Message-Id: <3EAB38F5-7FC8-4562-A714-CCD8ABCF2E71@gmail.com>
From: Andrew Jaquith <andrew.r.jaquith@gmail.com>
To: JSPWiki developers <jspwiki-dev@incubator.apache.org>
In-Reply-To: <2F18BE28-5E09-4728-A9D9-3FB80281587B@ecyrd.com>
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 5H11)
Subject: Re: ajax in v3.x -
Date: Mon, 15 Jun 2009 17:00:03 -0400
References: <15cc92000906140719h3432a0e1i3d1264cbfc714a51@mail.gmail.com>
 <99C98E98-082F-4998-806A-14ABBE8F011A@gmail.com>
 <A509FFCF-3B3D-4ACE-A20A-6C889BA3EAE9@ecyrd.com>
 <FC08BAE8-7F6A-4A80-A19E-ED74B82D156B@gmail.com>
 <2F18BE28-5E09-4728-A9D9-3FB80281587B@ecyrd.com>

You'll notice I made it clear that the example did NOT specify  
forwarding to a WEB-INF destination. Other that that I think we agree  
on HOW a ForwardResolution-based custom template option might work...  
regardless of option number.  ;)

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

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