You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Paul Stanton (Created) (JIRA)" <ji...@apache.org> on 2012/03/06 07:41:02 UTC
[jira] [Created] (TAP5-1861) Wrap javascript call rendering apis
for interoperability and convenience
Wrap javascript call rendering apis for interoperability and convenience
------------------------------------------------------------------------
Key: TAP5-1861
URL: https://issues.apache.org/jira/browse/TAP5-1861
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3.2
Reporter: Paul Stanton
Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
public class JavascriptHelperImpl implements JavascriptHelper
{
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Request request;
@Inject
private JavaScriptSupport jsSupport;
@Override
public void addScript(final String format, final Object... args)
{
if (!request.isXHR())
{
jsSupport.addScript(format, args);
return;
}
ajaxResponseRenderer.addCallback(new JavaScriptCallback()
{
@Override
public void run(JavaScriptSupport javascriptSupport)
{
javascriptSupport.addScript(format, args);
}
});
}
}
There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1861) Wrap javascript call rendering apis
for interoperability and convenience
Posted by "Paul Stanton (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223620#comment-13223620 ]
Paul Stanton commented on TAP5-1861:
------------------------------------
that would be better!
> Wrap javascript call rendering apis for interoperability and convenience
> ------------------------------------------------------------------------
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3.2
> Reporter: Paul Stanton
> Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1861) Wrap javascript call rendering apis
for interoperability and convenience
Posted by "Paul Stanton (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Stanton updated TAP5-1861:
-------------------------------
Description:
Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
public class JavascriptHelperImpl implements JavascriptHelper
{
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Request request;
@Inject
private JavaScriptSupport jsSupport;
@Override
public void addScript(final String format, final Object... args)
{
if (!request.isXHR())
{
jsSupport.addScript(format, args);
return;
}
ajaxResponseRenderer.addCallback(new JavaScriptCallback()
{
@Override
public void run(JavaScriptSupport javascriptSupport)
{
javascriptSupport.addScript(format, args);
}
});
}
}
There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
This code is free for anyone (including apache/tapestry) to use.
was:
Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
public class JavascriptHelperImpl implements JavascriptHelper
{
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Request request;
@Inject
private JavaScriptSupport jsSupport;
@Override
public void addScript(final String format, final Object... args)
{
if (!request.isXHR())
{
jsSupport.addScript(format, args);
return;
}
ajaxResponseRenderer.addCallback(new JavaScriptCallback()
{
@Override
public void run(JavaScriptSupport javascriptSupport)
{
javascriptSupport.addScript(format, args);
}
});
}
}
There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
> Wrap javascript call rendering apis for interoperability and convenience
> ------------------------------------------------------------------------
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3.2
> Reporter: Paul Stanton
> Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1861) Wrap javascript call rendering apis
for interoperability and convenience
Posted by "Paul Stanton (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223620#comment-13223620 ]
Paul Stanton commented on TAP5-1861:
------------------------------------
that would be better!
> Wrap javascript call rendering apis for interoperability and convenience
> ------------------------------------------------------------------------
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3.2
> Reporter: Paul Stanton
> Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1861) Wrap javascript call rendering apis
for interoperability and convenience
Posted by "Howard M. Lewis Ship (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223520#comment-13223520 ]
Howard M. Lewis Ship commented on TAP5-1861:
--------------------------------------------
Not a bad idea; I think the implementation is not quite ideal; basically, we could put different implementations of JavaScriptSupport into the Environment at different times to accomplish the "Right Thing" for invoking the methods in a way compatible with the overall request cycle.
> Wrap javascript call rendering apis for interoperability and convenience
> ------------------------------------------------------------------------
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3.2
> Reporter: Paul Stanton
> Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1861) Wrap javascript call rendering apis
for interoperability and convenience
Posted by "Paul Stanton (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223034#comment-13223034 ]
Paul Stanton commented on TAP5-1861:
------------------------------------
usage:
private void doSomethingOnServer()
{
...
jsHelper.addScript("MyObject.doSomethingOnClient();");
...
}
void setupRender()
{
...
doSomethingOnServer();
...
}
void onSomeAjaxEvent()
{
...
doSomethingOnServer();
...
}
> Wrap javascript call rendering apis for interoperability and convenience
> ------------------------------------------------------------------------
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3.2
> Reporter: Paul Stanton
> Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1861) Wrap javascript call rendering apis
for interoperability and convenience
Posted by "Howard M. Lewis Ship (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223520#comment-13223520 ]
Howard M. Lewis Ship commented on TAP5-1861:
--------------------------------------------
Not a bad idea; I think the implementation is not quite ideal; basically, we could put different implementations of JavaScriptSupport into the Environment at different times to accomplish the "Right Thing" for invoking the methods in a way compatible with the overall request cycle.
> Wrap javascript call rendering apis for interoperability and convenience
> ------------------------------------------------------------------------
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3.2
> Reporter: Paul Stanton
> Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1861) Wrap javascript call rendering apis
for interoperability and convenience
Posted by "Paul Stanton (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223034#comment-13223034 ]
Paul Stanton commented on TAP5-1861:
------------------------------------
usage:
private void doSomethingOnServer()
{
...
jsHelper.addScript("MyObject.doSomethingOnClient();");
...
}
void setupRender()
{
...
doSomethingOnServer();
...
}
void onSomeAjaxEvent()
{
...
doSomethingOnServer();
...
}
> Wrap javascript call rendering apis for interoperability and convenience
> ------------------------------------------------------------------------
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3.2
> Reporter: Paul Stanton
> Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1861) Wrap javascript call rendering apis
for interoperability and convenience
Posted by "Paul Stanton (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Stanton updated TAP5-1861:
-------------------------------
Description:
Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
public class JavascriptHelperImpl implements JavascriptHelper
{
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Request request;
@Inject
private JavaScriptSupport jsSupport;
@Override
public void addScript(final String format, final Object... args)
{
if (!request.isXHR())
{
jsSupport.addScript(format, args);
return;
}
ajaxResponseRenderer.addCallback(new JavaScriptCallback()
{
@Override
public void run(JavaScriptSupport javascriptSupport)
{
javascriptSupport.addScript(format, args);
}
});
}
}
There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
This code is free for anyone (including apache/tapestry) to use.
was:
Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
public class JavascriptHelperImpl implements JavascriptHelper
{
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Request request;
@Inject
private JavaScriptSupport jsSupport;
@Override
public void addScript(final String format, final Object... args)
{
if (!request.isXHR())
{
jsSupport.addScript(format, args);
return;
}
ajaxResponseRenderer.addCallback(new JavaScriptCallback()
{
@Override
public void run(JavaScriptSupport javascriptSupport)
{
javascriptSupport.addScript(format, args);
}
});
}
}
There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
> Wrap javascript call rendering apis for interoperability and convenience
> ------------------------------------------------------------------------
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3.2
> Reporter: Paul Stanton
> Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things much easier to use in tapestry 5.2+, however I still think there is room for improvement. I find I can't work without this 'helper' service I designed to standardise script call rendering between xhr and non-xhr requests. The main motivation/benefit is that a set of functionality can now be called in either (xhr/non-xhr) context and still work. It also has the benefit of building the necessary JavaScriptCallback in the xhr context. In my opinion, this makes user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira