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 02:13:19 GMT
I don't quite understand how JSON client---->server works. Is it part  
of a post body? If so, the best way to handle this might be via a  
TypeConverter. An Interceptor would be decent also, but you'd have to  
remember to add annotations to either the event handler methods or the  
mutators. That's valid also.

But better than this would simply be to the (light) refactoring needed  
to reduce the need for (3). The upload progress bar might be one area  
we can't refactor easily, but then I don't understand hwo that  
particular code works yet.

I'm off my laptop for the next 2 weeks (honeymoon); otherwise I'd  
normally have better-researched anwers. ;)

Andrew

On Jun 14, 2009, at 17:57, Janne Jalkanen <Janne.Jalkanen@ecyrd.com>  
wrote:

>
> A pretty neat way would be to build a JSONInterceptor, which would  
> detect custom annotations from methods, so that you could mark a  
> method with
>
> @JSONMethod( query=String )
> @HandlesEvent("getSuggestions")
> public Resolution getSuggestions()
> {
>   return new  
> JavascriptResolution( buildArrayListForSuggestions( getQuery() ) );
> }
>
> Which would just simply extract the query parameter from the JSON  
> and place it into the bean using setQuery(String).  We could still  
> use jabsorb's class hinting mechanism.
>
> /Janne
>
> On Jun 15, 2009, at 00:20 , Dirk Frederickx wrote:
>
>> 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
View raw message