You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Dirk Frederickx <di...@gmail.com> on 2009/06/14 16:19:05 UTC
ajax in v3.x -
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
Re: ajax in v3.x -
Posted by Andrew Jaquith <an...@gmail.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 <ja...@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 <ja...@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
>>>
>
Re: ajax in v3.x -
Posted by Janne Jalkanen <ja...@ecyrd.com>.
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 <ja...@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
>>
Re: ajax in v3.x -
Posted by Andrew Jaquith <an...@gmail.com>.
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 <ja...@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
>> <di...@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
>
Re: ajax in v3.x -
Posted by Janne Jalkanen <ja...@ecyrd.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
> <di...@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
Re: ajax in v3.x -
Posted by Andrew Jaquith <an...@gmail.com>.
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 <di...@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
Re: ajax in v3.x -
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
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
> <Ja...@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
>>>
>>
>>
Re: ajax in v3.x -
Posted by Dirk Frederickx <di...@gmail.com>.
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
<Ja...@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
>>
>
>
Re: ajax in v3.x -
Posted by Andrew Jaquith <an...@gmail.com>.
Murray --
Check out the 3.x FileBasedActionResolver, which will allow URL
schemes to be specified in an external file, and in very flexible
ways. It's experimental and not part of the core yet. I wrote it with
the idea that it would replace the URLConstructor. (Or more precisely:
it would be used with StripesUrlConstructor, allowing Stripes-
generated URLs and those from URLCpnstructor to share the same syntax).
See if it meets your needs. It should. :)
Andrew
On Jun 14, 2009, at 18:34, Murray Altheim <mu...@altheim.com> wrote:
> Janne Jalkanen wrote:
> [...]
>> 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.
>
> I know I've not been very active on this project lately, we've had
> some
> management hitches at this end that have kept me busy on other
> projects
> and the previous development of the assertion framework is currently
> on
> hold. That said, we just launched a new internal enterprise wiki and
> I've
> still be quite actively using JSPWiki and developing associated tools,
> though currently most of that is on internal products.
>
> One project I've got mostly working is a wiki chat feature that uses
> an
> external web service for storage. The web service was actually
> developed
> for a different project but the URL scheme was suitable. There were
> three
> options available in design/configuration, to avoid browser cross-site
> security issues:
>
> 1. have the web service embedded in the wiki itself
> 2. use the wiki as a pipe to the web service (performance
> bottleneck?)
> 3. uses subdomain aliasing to have both the wiki and the web
> service at the same subdomain and port (i.e., differentiate
> at the web application level, e.g., webapps/wiki/ and webapps/
> ws/)
>
> Option 3 is what we're currently doing.
>
> In doing a lot of thinking about REST-style web services (as part of a
> different project), I'm almost at a point where I think the entire URI
> scheme for the wiki should be handled in this manner -- we could rid
> ourselves of all the various URL constructors (though I suppose we
> might
> have to deal with backwards-compatibility issues for existing wikis)
> and
> have a nice clean URL scheme.
>
> The basic scheme I've ended up with has a fixed number of path
> components,
> the last one being the action or verb. Optionally appended to this
> would
> be any query features, considered as parameters. But the basic URL
> (and
> the web service itself) would function without query parameters.
>
> For example, where 'f' is format:
>
> http://acme.com/wiki/pages/PageName/get default output
> (XHTML)
> http://acme.com/wiki/pages/PageName/get?f=text text output
> http://acme.com/wiki/pages/PageName/get?f=json JSON output
>
> An idea derived from the ARK specification, doubling up on the
> question marks returns page metadata:
>
> http://acme.com/wiki/pages/PageName/get?? return page
> metadata
>
> Whether this survives the final design is as yet unknown.
>
> The current set of actions includes:
>
> get return record (page) content
> pid return persistent identifier
> key return public key (securely ties web service to JSP)
> terms return all record (page) metadata
> term return a single metadata term (uses query parameter for
> name)
> index return index of records (pages)
> post post new record (page)
> make tinyurl-like redirect service
> put modify existing record (page)
> delete delete record (page)
> query query database for records (pages)
> admin admin functions
> ingest ingest bulk records (pages)
> help return API help
> test run unit tests, returning result
>
> The primary function of the web service project is a persistent
> identifier
> service, but we ended up using its storage features for the wiki chat
> feature. I'm not sure if this is of any interest or relevance but I
> thought to pass it along.
>
> Murray
>
> ...
> ...
> .....................................................................
> Murray Altheim <murray09 at altheim dot com>
> === = =
> http://www.altheim.com/murray/ =
> = ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk =
> = = =
>
> Boundless wind and moon - the eye within eyes,
> Inexhaustible heaven and earth - the light beyond light,
> The willow dark, the flower bright - ten thousand houses,
> Knock at any door - there's one who will respond.
> -- The Blue Cliff Record
>
Re: ajax in v3.x -
Posted by Murray Altheim <mu...@altheim.com>.
Janne Jalkanen wrote:
[...]
> 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.
I know I've not been very active on this project lately, we've had some
management hitches at this end that have kept me busy on other projects
and the previous development of the assertion framework is currently on
hold. That said, we just launched a new internal enterprise wiki and I've
still be quite actively using JSPWiki and developing associated tools,
though currently most of that is on internal products.
One project I've got mostly working is a wiki chat feature that uses an
external web service for storage. The web service was actually developed
for a different project but the URL scheme was suitable. There were three
options available in design/configuration, to avoid browser cross-site
security issues:
1. have the web service embedded in the wiki itself
2. use the wiki as a pipe to the web service (performance bottleneck?)
3. uses subdomain aliasing to have both the wiki and the web
service at the same subdomain and port (i.e., differentiate
at the web application level, e.g., webapps/wiki/ and webapps/ws/)
Option 3 is what we're currently doing.
In doing a lot of thinking about REST-style web services (as part of a
different project), I'm almost at a point where I think the entire URI
scheme for the wiki should be handled in this manner -- we could rid
ourselves of all the various URL constructors (though I suppose we might
have to deal with backwards-compatibility issues for existing wikis) and
have a nice clean URL scheme.
The basic scheme I've ended up with has a fixed number of path components,
the last one being the action or verb. Optionally appended to this would
be any query features, considered as parameters. But the basic URL (and
the web service itself) would function without query parameters.
For example, where 'f' is format:
http://acme.com/wiki/pages/PageName/get default output (XHTML)
http://acme.com/wiki/pages/PageName/get?f=text text output
http://acme.com/wiki/pages/PageName/get?f=json JSON output
An idea derived from the ARK specification, doubling up on the
question marks returns page metadata:
http://acme.com/wiki/pages/PageName/get?? return page metadata
Whether this survives the final design is as yet unknown.
The current set of actions includes:
get return record (page) content
pid return persistent identifier
key return public key (securely ties web service to JSP)
terms return all record (page) metadata
term return a single metadata term (uses query parameter for name)
index return index of records (pages)
post post new record (page)
make tinyurl-like redirect service
put modify existing record (page)
delete delete record (page)
query query database for records (pages)
admin admin functions
ingest ingest bulk records (pages)
help return API help
test run unit tests, returning result
The primary function of the web service project is a persistent identifier
service, but we ended up using its storage features for the wiki chat
feature. I'm not sure if this is of any interest or relevance but I
thought to pass it along.
Murray
...........................................................................
Murray Altheim <murray09 at altheim dot com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: ajax in v3.x -
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
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