[jira] [Created] (TAP5-2408) upload component doesn't render class=form-control
Paul Stanton created TAP5-2408: -- Summary: upload component doesn't render class=form-control Key: TAP5-2408 URL: https://issues.apache.org/jira/browse/TAP5-2408 Project: Tapestry 5 Issue Type: Bug Components: tapestry-upload Affects Versions: 5.4 Reporter: Paul Stanton Priority: Minor the markup: t:upload t:id=file / renders: input id=file name=file type=file however, in keeping with other tapestry components it should add the bootstrap css class: class=form-control -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-1861) Wrap javascript call rendering apis for interoperability and convenience
[
https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14180953#comment-14180953
]
Paul Stanton commented on TAP5-1861:
has there been any improvements to this behaviour in t5.4?
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
Assignee: Howard M. Lewis Ship
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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-1845) datefield/datepicker uses deprecated CSS System Colors which are problematic.
[
https://issues.apache.org/jira/browse/TAP5-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14117783#comment-14117783
]
Paul Stanton commented on TAP5-1845:
sorry, we are still on 5.3.7 and i am having trouble finding the source code of
the DatePicker css in the Github tree. As I recall the old css used to
reference WindowText or WindowFrame or one of the other CSS system colours
(deprecated, not well supported) as per documentation here
http://www.w3.org/TR/css3-color/#css-system
hope that's helpful.
datefield/datepicker uses deprecated CSS System Colors which are problematic.
-
Key: TAP5-1845
URL: https://issues.apache.org/jira/browse/TAP5-1845
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.3
Reporter: Paul Stanton
Labels: css, datefield
The css for the datepicker (used by datefield) makes use of a feature of CCS
2.0 which has since been deprecated and has limited support.
A side affect of this is that, unless the css is overridden, (eg .datePicker
td .topLabel {color: black;} ) the text for the month selection is invisible
(white on white) by default.
http://www.w3.org/TR/css3-color/#css-system
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2021) create compatible client side method of encoding context parameters
[ https://issues.apache.org/jira/browse/TAP5-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046848#comment-14046848 ] Paul Stanton commented on TAP5-2021: that would make the event parameter wiring non-interchangeable if used by multiple methods of invocation - not to mention ugly... anyway, it is a simple script which i have written/tested and will just have to carry around to each tapestry project i work on. create compatible client side method of encoding context parameters --- Key: TAP5-2021 URL: https://issues.apache.org/jira/browse/TAP5-2021 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3 Reporter: Paul Stanton Assignee: Howard M. Lewis Ship Labels: urlencoder Currently there is no (provided) way to replicate the tapestry propriety URL encoding. See org.apache.tapestry5.internal.services.URLEncoderImpl.encode(String) This can be limiting for advanced users wiring up custom components which may create requests via javascript. I personally have come up against this a number of times. I propose that tapestry.js include a function which does the equivalent of URLEncoder.encode, or even better, ComponentResources.createEventLink etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2080) Default BaseURLSource does not handle all scenarios
[
https://issues.apache.org/jira/browse/TAP5-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806602#comment-13806602
]
Paul Stanton commented on TAP5-2080:
would love to see this re-opened because it is not an uncommon requirement.
Default BaseURLSource does not handle all scenarios
---
Key: TAP5-2080
URL: https://issues.apache.org/jira/browse/TAP5-2080
Project: Tapestry 5
Issue Type: Bug
Affects Versions: 5.3.6
Reporter: Thomas Hackel
Assignee: Howard M. Lewis Ship
Two Scenario:
1. User(Internet)-SSL-Proxy:443-Tomcat:8080
2. User(Intranet)-Tomcat:8080
The BaseURLSourceImpl DOES NOT use the Scheme of the request, it just uses
the secured flag to change the scheme. Which is not required/useful in the
scenario above.
The BaseURLSource creates links like http://foo:443/bar; instead of
https://foo/bar;.
This problem was already mentioned in TAP5-167 which was silently closed.
Overwriting the BaseURLSource, as described in
http://tapestry.apache.org/https.html is also not possible because you would
need a Request object which can't be injected because it causes some service
cycle problem. The Request object is required to physically map 443 to
https, because the Tap5 Request object also lacks the Request Scheme...
{code}
public static void contributeServiceOverride(
MappedConfigurationClass?, Object configuration,
@Inject Request request) {
BaseURLSource source = new ProxyEnabledBaseURLSource(request);
configuration.add(BaseURLSource.class, source);
}
{code}
Causes:
{code}
java.lang.IllegalStateException: Construction of service 'ServiceOverride'
has failed due to recursion: the service depends on itself in some way.
Please check
org.apache.tapestry5.ioc.internal.services.ServiceOverrideImpl(Map) (at
ServiceOverrideImpl.java:31) via
org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder) (at
TapestryIOCModule.java:49) for references to another service that is itself
dependent on service 'ServiceOverride'.
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1861) Wrap javascript call rendering apis for interoperability and convenience
[
https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720180#comment-13720180
]
Paul Stanton commented on TAP5-1861:
Hi Howard,
I've made some discoveries which make the implementation posted here out of
date; i'm sure you are aware of the following:
1. if in the render or event handling phase of a normal request,
JavaScriptSupport must be used over AjaxResponseRenderer
2. if in the event handling phase of an ajax request AjaxResponseRenderer must
be used over JavaScriptSupport
however this was news to me:
3. if in the 'render phase' of an ajax request, JavaScriptSupport must be used
over AjaxResponseRenderer
.. and in this third case, the 'isXHR' test is not sufficient; the only way to
determine this case is to 'peek' for JavaScriptSupport.
therefore, my current implementation of the previously posted utility looks
like this:
public void addScript(final InitializationPriority priority, final
String format, final Object... args)
{
if (!request.isXHR()
|| env.peek(JavaScriptSupport.class) != null)
{
jsSupport.addScript(priority, format, args);
return;
}
ajaxResponseRenderer.addCallback(new JavaScriptCallback()
{
@Override
public void run(JavaScriptSupport javascriptSupport)
{
javascriptSupport.addScript(priority, format,
args);
}
});
}
I hope this helps design whatever solution you come up with.
Regards, Paul.
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
Assignee: Howard M. Lewis Ship
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1405) XHR requests should be easily callable from javascript and not rely on a zone
[
https://issues.apache.org/jira/browse/TAP5-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720185#comment-13720185
]
Paul Stanton commented on TAP5-1405:
does it handle encoding context parameters?
XHR requests should be easily callable from javascript and not rely on a zone
-
Key: TAP5-1405
URL: https://issues.apache.org/jira/browse/TAP5-1405
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.2
Reporter: Paul Stanton
Assignee: Howard M. Lewis Ship
Fix For: 5.4
I quite often needed to initialise an XHR request-response from javascript. I
think it would be a very useful feature for tapestry to expose to it's users.
The ideal solution would
1. not require a zone for wiring (see #TAP5-1404)
2. encode context parameters as per server side
EG
I ended up writing a function to facilitate this. It handles:
1. the zone wiring
2. context parameters (unfortunately does not properly conform to encoding
rules as per server side generated params)
3. query strings (sometimes useful)
4. url based session ids (for when cookies are disabled)
note that the url is usually generated at the server side via
ComponentResources.createEventLink.
function multiZoneUpdate(url, params, zoneId)
{
// wire up zone, use dummy if none supplied
if (typeof(zoneId) == undefined)
zoneId = dummyZone;
var zoneObject = Tapestry.findZoneManagerForZone(zoneId);
if (!zoneObject)
throw unknown zone: + zoneId;
// context params must be an array
if (!(params instanceof Array))
params = [params];
// include query string if supplied
var qs = ;
var qsInd = url.indexOf(?);
if (qsInd != -1)
{
qs = url.substring(qsInd);
url = url.substring(0, qsInd);
}
// include jsessionid if exists
var jsId = ;
var jsInd = url.indexOf(;);
if (jsInd != -1)
{
jsId = url.substring(jsInd);
url = url.substring(0, jsInd);
}
// build url
if (params != null)
for (var p = 0; p params.length; p++)
url += / + params[p];
// request
zoneObject.updateFromURL(url + jsId + qs);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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
[
https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13640084#comment-13640084
]
Paul Stanton commented on TAP5-1861:
Howard, is it your view that this is no longer an issue and that
JavascriptSupport.addScript should be used instead of
AjaxResponseRenderer.addCallback in both XHR and non-XHR requests?
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1870) javascript added while in the render phase of a component from an ajax request is never executed
[
https://issues.apache.org/jira/browse/TAP5-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13640131#comment-13640131
]
Paul Stanton commented on TAP5-1870:
I've figured out that
JavaScriptSupport.addScript
a) works if called from setupRender/afterRender whether XHR or not
b) does not work when called from XHR event handlers
AjaxResponseRenderer.addCallback
a) works for XHR event handlers
b) does not work if called from setupRender/afterRender in an XHR request
Therefore, in the case of the setupRender/afterRender in an XHR request is
tricky .. One must detect that this is the context of the call.
javascript added while in the render phase of a component from an ajax
request is never executed
Key: TAP5-1870
URL: https://issues.apache.org/jira/browse/TAP5-1870
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.3.2, 5.3.4
Reporter: Paul Stanton
Labels: ajax, javascript, zone
When a zone update occurs, the 'setupRender' is called for each component
contained by that zone.
If a script is added to ajaxResponseRenderer within the 'setupRender' method
it is never executed on the page.
eg:
public class MyPage
{
void onSomeEvent()
{
ajaxResponseRenderer.addRender(myZone); // myZone contains a
MyComponent in the tml
}
}
public class MyComponent
{
void setupRender()
{
if (request.isXHR())
ajaxResponseRenderer.addCallback(new JavaScriptCallback() {
public void run(JavaScriptSupport javascriptSupport) {
javascriptSupport.addScript(alert('here'););}});
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2081) datefield: cannot blank out date value via text input
[
https://issues.apache.org/jira/browse/TAP5-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13596852#comment-13596852
]
Paul Stanton commented on TAP5-2081:
Copying the similar implementation from elsewhere in the datefield.js script,
adding the following to the selectDate function (just before calling
sendServerRequest) resolves the issue.
// If the field is blank, don't bother going to the server to parse!
if (value == ) {
resultHandler.call(this, {formatted:, value:});
return;
}
datefield: cannot blank out date value via text input
-
Key: TAP5-2081
URL: https://issues.apache.org/jira/browse/TAP5-2081
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.3.6
Reporter: Paul Stanton
Labels: datefield
If you select a date via the calendar, and then delete the value in the text
field an exception is thrown since the server site method onParse does not
accept a blank parameter.
This should instead avoid going to the server for a parse, and set the
current value to null.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2081) datefield: cannot blank out date value via text input
Paul Stanton created TAP5-2081: -- Summary: datefield: cannot blank out date value via text input Key: TAP5-2081 URL: https://issues.apache.org/jira/browse/TAP5-2081 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.6 Reporter: Paul Stanton If you select a date via the calendar, and then delete the value in the text field an exception is thrown since the server site method onParse does not accept a blank parameter. This should instead avoid going to the server for a parse, and set the current value to null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TAP5-2021) create compatible client side method of encoding context parameters
[
https://issues.apache.org/jira/browse/TAP5-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13485285#comment-13485285
]
Paul Stanton edited comment on TAP5-2021 at 10/31/12 6:09 AM:
--
here is a javascript version of URLEncoderImpl.encode
/**
* see
org.apache.tapestry5.internal.services.URLEncoderImpl.encode(String)
* correct as at tapestry 5.3.5
*/
function tapestryUrlEncodeParameter(input)
{
var safe = abcdefghijklmnopqrstuvwxyz
+ ABCDEFGHIJKLMNOPQRSTUVWXYZ
+ 01234567890-_.:;
if (input === null)
return $N;
if (input === )
return $B;
var length = input.length;
var output = ;
for (var i = 0; i length; i++)
{
var ch = input.charAt(i);
if (ch === '$')
{
output += $$;
continue;
}
if (safe.indexOf(ch) != -1)
{
output += ch;
continue;
}
var chHex = ch.charCodeAt(0).toString(16);
while (chHex.length 4)
chHex = 0 + chHex;
output += $ + chHex;
}
return output;
}
was (Author: paul.stanton):
here is a javascript version of URLEncoderImpl.encode
/**
* see
org.apache.tapestry5.internal.services.URLEncoderImpl.encode(String)
* correct as at tapestry 5.3.5
*/
function tapestryUrlEncodeParameter(input)
{
var safe = abcdefghijklmnopqrstuvwxyz
+ ABCDEFGHIJKLMNOPQRSTUVWXYZ
+ 01234567890-_.:;
if (input === null)
return $N;
if (input === )
return $B;
var length = input.length;
var output = ;
for (var i = 0; i length; i++)
{
var ch = input.charAt(i);
if (ch == '$')
{
output.append($$);
continue;
}
if (safe.indexOf(ch) != -1)
{
output += ch;
continue;
}
var chHex = ch.charCodeAt(0).toString(16);
while (chHex.length 4)
chHex = 0 + chHex;
output += $ + chHex;
}
return output;
}
create compatible client side method of encoding context parameters
---
Key: TAP5-2021
URL: https://issues.apache.org/jira/browse/TAP5-2021
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3
Reporter: Paul Stanton
Labels: urlencoder
Currently there is no (provided) way to replicate the tapestry propriety URL
encoding.
See org.apache.tapestry5.internal.services.URLEncoderImpl.encode(String)
This can be limiting for advanced users wiring up custom components which may
create requests via javascript.
I personally have come up against this a number of times.
I propose that tapestry.js include a function which does the equivalent of
URLEncoder.encode, or even better, ComponentResources.createEventLink etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TAP5-2021) create compatible client side method of encoding context parameters
[
https://issues.apache.org/jira/browse/TAP5-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13485285#comment-13485285
]
Paul Stanton edited comment on TAP5-2021 at 10/30/12 4:04 AM:
--
here is a javascript version of URLEncoderImpl.encode
/**
* see
org.apache.tapestry5.internal.services.URLEncoderImpl.encode(String)
* correct as at tapestry 5.3.5
*/
function tapestryUrlEncodeParameter(input)
{
var safe = abcdefghijklmnopqrstuvwxyz
+ ABCDEFGHIJKLMNOPQRSTUVWXYZ
+ 01234567890-_.:;
if (input === null)
return $N;
if (input === )
return $B;
var length = input.length;
var output = ;
for (var i = 0; i length; i++)
{
var ch = input.charAt(i);
if (ch == '$')
{
output.append($$);
continue;
}
if (safe.indexOf(ch) != -1)
{
output += ch;
continue;
}
var chHex = ch.charCodeAt(0).toString(16);
while (chHex.length 4)
chHex = 0 + chHex;
output += $ + chHex;
}
return output;
}
was (Author: paul.stanton):
here is a javascript version of URLEncoderImpl.encode
/**
* see
org.apache.tapestry5.internal.services.URLEncoderImpl.encode(String)
* correct as at tapestry 5.3.5
*/
function tapestryUrlEncodeParameter(input)
{
var safe = abcdefghijklmnopqrstuvwxyz
+ ABCDEFGHIJKLMNOPQRSTUVWXYZ
+ 01234567890-_.:;
if (input === null)
return $N;
if (input === )
return $B;
var length = input.length;
var output = ;
for (var i = 0; i length; i++)
{
var ch = input.charAt(i);
if (ch == '$')
{
output.append($$);
continue;
}
if (safe.indexOf(ch) != -1)
{
output += ch;
continue;
}
var chAsInt = ch.charCodeAt(0);
var chAsHexInt = parseInt(chAsInt.toString(16));
output += $ + chAsHexInt.toPaddedString(4);
}
return output;
}
create compatible client side method of encoding context parameters
---
Key: TAP5-2021
URL: https://issues.apache.org/jira/browse/TAP5-2021
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3
Reporter: Paul Stanton
Labels: urlencoder
Currently there is no (provided) way to replicate the tapestry propriety URL
encoding.
See org.apache.tapestry5.internal.services.URLEncoderImpl.encode(String)
This can be limiting for advanced users wiring up custom components which may
create requests via javascript.
I personally have come up against this a number of times.
I propose that tapestry.js include a function which does the equivalent of
URLEncoder.encode, or even better, ComponentResources.createEventLink etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2021) create compatible client side method of encoding context parameters
Paul Stanton created TAP5-2021: -- Summary: create compatible client side method of encoding context parameters Key: TAP5-2021 URL: https://issues.apache.org/jira/browse/TAP5-2021 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3 Reporter: Paul Stanton Currently there is no (provided) way to replicate the tapestry propriety URL encoding. See org.apache.tapestry5.internal.services.URLEncoderImpl.encode(String) This can be limiting for advanced users wiring up custom components which may create requests via javascript. I personally have come up against this a number of times. I propose that tapestry.js include a function which does the equivalent of URLEncoder.encode, or even better, ComponentResources.createEventLink etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1870) javascript added while in the render phase of a component from an ajax request is never executed
[
https://issues.apache.org/jira/browse/TAP5-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Stanton updated TAP5-1870:
---
Affects Version/s: 5.3.4
javascript added while in the render phase of a component from an ajax
request is never executed
Key: TAP5-1870
URL: https://issues.apache.org/jira/browse/TAP5-1870
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.3.2, 5.3.4
Reporter: Paul Stanton
Labels: ajax, javascript, zone
When a zone update occurs, the 'setupRender' is called for each component
contained by that zone.
If a script is added to ajaxResponseRenderer within the 'setupRender' method
it is never executed on the page.
eg:
public class MyPage
{
void onSomeEvent()
{
ajaxResponseRenderer.addRender(myZone); // myZone contains a
MyComponent in the tml
}
}
public class MyComponent
{
void setupRender()
{
if (request.isXHR())
ajaxResponseRenderer.addCallback(new JavaScriptCallback() {
public void run(JavaScriptSupport javascriptSupport) {
javascriptSupport.addScript(alert('here'););}});
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2000) empty element causes 'unbalanced elements' exception
Paul Stanton created TAP5-2000: -- Summary: empty element causes 'unbalanced elements' exception Key: TAP5-2000 URL: https://issues.apache.org/jira/browse/TAP5-2000 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.3 Reporter: Paul Stanton consider the following TML markup: col t:type=if t:test=myTest/col If 'myTest' is true, I want to render an empty col element, if it is false render nothing. TRUE: [col/col] FALSE: [] however the above markup causes this exception: Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException: Component MyPage:mycomponent.if_4 has rendered unbalanced elements; either it has started an element with MarkupWriter.element() and not followed up with MarkupWriter.end(), or it has invoked MarkupWriter.end() without first invoking MarkupWriter.element(). [at classpath:com/me/components/MyComponent.tml, line 26] at org.apache.tapestry5.internal.structure.ComponentPageElementImpl$PostRenderCleanupPhase.render(ComponentPageElementImpl.java:441) at org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:72) ... 81 more To work around, include any character (space) within the element: col t:type=if t:test=myTest /col which renders: TRUE: [col /col] FALSE: [] I also imagine you could do: t:if test=myTestcol/col/t:if -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-841) DateField selects wrong date if client is in a different timezone than the server
[ https://issues.apache.org/jira/browse/TAP5-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411875#comment-13411875 ] Paul Stanton commented on TAP5-841: --- here's a major bug that we have a solution for, can this make 5.3.4? DateField selects wrong date if client is in a different timezone than the server - Key: TAP5-841 URL: https://issues.apache.org/jira/browse/TAP5-841 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: David Rees Assignee: Robert Zeigler Attachments: T5.3-DateField-Patch.txt This affects 5.0.18 and 5.1.0.5 in my testing. Situation is that if the server is running in a different timezone than the client, the DateField chooser will select the wrong date on the calendar. For example, if the server is running in Pacific/Auckland and the client is running in America/Los_Angeles, Auckland is a day ahead of Los Angeles for most of the time and the bug is easy to reproduce. Right now it is 3:40PM Sep 8, 2009 America/Los_Angeles and 10:40AM Sep 9, 2009 Pacific/Auckland. If the date on the server to be displayed by the DateField is Sep 9, 2009, when you select the date chooser, Sep 8, 2009 is selected in the JavaScript calendar dialog. I found this message which seems to indicate that Howard thought it might be an issue - looks like he was correct: http://www.nabble.com/Re%3A-Tapestry-5.0.15-DateField-localization-problem--patch-included--p20033325.html -- 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-1548) Property expressions fails when using a supertype that implements an interface with a matching method
[
https://issues.apache.org/jira/browse/TAP5-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409138#comment-13409138
]
Paul Stanton commented on TAP5-1548:
this just stung me, took a little while to figure out that adding the setter to
the interface would resolve the issue.
please fix!
Property expressions fails when using a supertype that implements an
interface with a matching method
-
Key: TAP5-1548
URL: https://issues.apache.org/jira/browse/TAP5-1548
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.2
Reporter: Robert Zeigler
Attachments: generics.bug1demo.tgz
Given:
public interface Baz {
String getBar();
}
public class AbstractFoo implements Baz {
private String bar;
public String getBar() { return bar; }
public void setBar(String bar) { this.bar =bar; }
}
public class Foo extends AbstractFoo {}
public class AComponent {
@Parameter
@Property
private AbstractFoo foo;
}
.tml:
t:formt:textfield value=foo.bar//t:form
The update of the textfield will fail with Failure writing parameter 'value'
of component Index:layout.acomponent.textfield: Expression 'foo.bar' for
class org.apache.tapestry5.generics1.components.AComponent is read-only.
Note that if you:
a) Specify Foo directly, it works
b) Remove the getFoo from interface Baz, it works
c) add setFoo to the interface Baz, it works.
I would expect Tapestry to find the property from the base class first. In
fact, it used to, in T5.1.0.4 at least, because I found this issue upgrading
a project from 5.1.0.4 to 5.2.5 and a component that used to work broke. In
that case, the component was using generic types (public class AComponentT
extends AbstractFoo), but the problem shows up with or without the generics.
I can accept that if I specify the type of the property as Baz, I will get
the above exception even if I pass in a Foo or AbstractFoo. But using
the (read-only) property from the Baz interface when I explicitly declare the
property type to be AbstractFoo is unacceptable and a regression from
previous behavior.
--
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-1880) GZip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13259963#comment-13259963 ] Paul Stanton commented on TAP5-1880: it was not happening in 5.2, we were hit when we upgraded. GZip compression should be disabled if the request is over http 1.0 --- Key: TAP5-1880 URL: https://issues.apache.org/jira/browse/TAP5-1880 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.2 Reporter: Paul Stanton Assignee: Howard M. Lewis Ship Labels: gzip, ie Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of HTTP 1.1) and in this scenario, GZIP compression is still applied to the response and the clients do not interpret the response correctly. This may either be caused by the client incorrectly setting 'accept-encoding' or incorrectly reading the 'encoding' headers at either end, however since it only occurs over http 1.0 it should just be disabled for all http 1.0 requests. -- 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] [Issue Comment Edited] (TAP5-1880) GZip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13259963#comment-13259963 ] Paul Stanton edited comment on TAP5-1880 at 4/23/12 9:19 PM: - i can't say for sure about 5.2 it was not happening in 5.1, we were hit when we upgraded from 5.1 to 5.3. was (Author: paul.stanton): it was not happening in 5.2, we were hit when we upgraded. GZip compression should be disabled if the request is over http 1.0 --- Key: TAP5-1880 URL: https://issues.apache.org/jira/browse/TAP5-1880 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.2 Reporter: Paul Stanton Assignee: Howard M. Lewis Ship Labels: gzip, ie Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of HTTP 1.1) and in this scenario, GZIP compression is still applied to the response and the clients do not interpret the response correctly. This may either be caused by the client incorrectly setting 'accept-encoding' or incorrectly reading the 'encoding' headers at either end, however since it only occurs over http 1.0 it should just be disabled for all http 1.0 requests. -- 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] [Reopened] (TAP5-1180) LinkSubmit does nothing
[
https://issues.apache.org/jira/browse/TAP5-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Stanton reopened TAP5-1180:
I have re-tested this under tapestry 5.1.0.5 and it is broken. the example
above shows the problem in action for me.
LinkSubmit does nothing
---
Key: TAP5-1180
URL: https://issues.apache.org/jira/browse/TAP5-1180
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Paul Stanton
After stepping through the javascript, I believe it's because the onsubmit
event handler for the form is javascript:Tapestry.waitForPage(event); who's
first line is if (Tapestry.pageLoaded) return;.
This is the equivalent of if (Tapestry.pageLoaded) return false; when
evaluated to a boolean as it is in the LinkSubmit onClick handler:
if (onsubmit == undefined || onsubmit.call(window.document, event))
{
this.createHidden();
this.form.submit();
}
.. and therefore this.form.submit(); is never called.
Obviously this is a bug, I'm pretty sure the resolution would be to change
Tapestry.waitForPage so that it returns true if the page is loaded and false
otherwise, ie:
waitForPage : function(event)
{
if (Tapestry.pageLoaded) return true;
...
return false;
}
This will allow 'waitForPage' to be evaluated to a boolean as it is in
LinkSubmit.onClick, however there may be a better solution.
EG:
MyPage.tml:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:t=http://tapestry.apache.org/schema/tapestry_5_1_0.xsd;
xmlns:p=tapestry:parameter
t:form t:id=myForm
t:linksubmit t:id=myLinklink/t:linksubmit
t:submit t:id=mySubmit /
/t:form
/html
MyPage.java
public Class MyPage
{
public void onSuccessFromMyForm()
{
LOG.debug(onSuccessFromMyForm);
}
public void onSelectedFromMyLink()
{
LOG.debug(onSelectedFromMyLink);
}
public void onSelectedFromMySubmit()
{
LOG.debug(onSelectedFromMySubmit);
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-841) DateField selects wrong date if client is in a different timezone than the server
[ https://issues.apache.org/jira/browse/TAP5-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13066753#comment-13066753 ] Paul Stanton commented on TAP5-841: --- tapx is NOT a solution to a tapestry BUG. DateField selects wrong date if client is in a different timezone than the server - Key: TAP5-841 URL: https://issues.apache.org/jira/browse/TAP5-841 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: David Rees This affects 5.0.18 and 5.1.0.5 in my testing. Situation is that if the server is running in a different timezone than the client, the DateField chooser will select the wrong date on the calendar. For example, if the server is running in Pacific/Auckland and the client is running in America/Los_Angeles, Auckland is a day ahead of Los Angeles for most of the time and the bug is easy to reproduce. Right now it is 3:40PM Sep 8, 2009 America/Los_Angeles and 10:40AM Sep 9, 2009 Pacific/Auckland. If the date on the server to be displayed by the DateField is Sep 9, 2009, when you select the date chooser, Sep 8, 2009 is selected in the JavaScript calendar dialog. I found this message which seems to indicate that Howard thought it might be an issue - looks like he was correct: http://www.nabble.com/Re%3A-Tapestry-5.0.15-DateField-localization-problem--patch-included--p20033325.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-841) DateField selects wrong date if client is in a different timezone than the server
[ https://issues.apache.org/jira/browse/TAP5-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13066755#comment-13066755 ] Paul Stanton commented on TAP5-841: --- my current solution to this bug is to convert the date selection into a string (-MM-dd) for transportation, avoiding any issues with timezone offsets. And Chris is right, the synchonization of the DF is concerning. Is there a separate Jira for this? I am going to patch my version (my patch jar is growing!!!) so that the DF parameter is cloned before use and synchronized when used. DateField selects wrong date if client is in a different timezone than the server - Key: TAP5-841 URL: https://issues.apache.org/jira/browse/TAP5-841 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: David Rees This affects 5.0.18 and 5.1.0.5 in my testing. Situation is that if the server is running in a different timezone than the client, the DateField chooser will select the wrong date on the calendar. For example, if the server is running in Pacific/Auckland and the client is running in America/Los_Angeles, Auckland is a day ahead of Los Angeles for most of the time and the bug is easy to reproduce. Right now it is 3:40PM Sep 8, 2009 America/Los_Angeles and 10:40AM Sep 9, 2009 Pacific/Auckland. If the date on the server to be displayed by the DateField is Sep 9, 2009, when you select the date chooser, Sep 8, 2009 is selected in the JavaScript calendar dialog. I found this message which seems to indicate that Howard thought it might be an issue - looks like he was correct: http://www.nabble.com/Re%3A-Tapestry-5.0.15-DateField-localization-problem--patch-included--p20033325.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1575) DateField is not multi-timezone safe
[ https://issues.apache.org/jira/browse/TAP5-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Stanton closed TAP5-1575. -- Resolution: Duplicate dup of TAP5-841 DateField is not multi-timezone safe Key: TAP5-1575 URL: https://issues.apache.org/jira/browse/TAP5-1575 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Paul Stanton Priority: Critical Labels: DateField, TimeZone If the client is in a different timezone to the server, selecting a date will set the wrong value in the input field in most cases. The cause is the use of 'milliseconds since epoch'. The following demonstrates part of the problem: TimeZone serverTz = TimeZone.getTimeZone(GMT+1000); TimeZone clientTz = TimeZone.getTimeZone(GMT-1500); // simulates client to server communication method used by DateField TimeZone.setDefault(serverTz); SimpleDateFormat serverDf = new SimpleDateFormat(-MM-dd HH:mm:ss); SimpleDateFormat clientDf = (SimpleDateFormat) serverDf.clone(); clientDf.setTimeZone(clientTz); String dateSelection = 2011-07-01 00:00:00; Date clientDate = clientDf.parse(dateSelection); Date serverDate = new Date(clientDate.getTime()); System.out.println(2011-07-01 00:00:00 = + serverDf.format(serverDate) + ?); So if a user selected July 7 2011, the field would display July 2 2011 if the timezones were as above. My solution was to remove the usage of both the java and javascript `Date.getTime` and `new Date(time)` functions. Instead, I serialise to -MM-dd and format/parse this on the server using the same tz as the format parameter. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1409) datefield - cannot select same day in different month
[ https://issues.apache.org/jira/browse/TAP5-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13040531#comment-13040531 ] Paul Stanton commented on TAP5-1409: thanks for working on the patch antal, the only remaining minor issue is that the selected date in other months is still highlighted. your patch is good, cheers, p. datefield - cannot select same day in different month - Key: TAP5-1409 URL: https://issues.apache.org/jira/browse/TAP5-1409 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.2.4 Reporter: Paul Stanton Attachments: datepicker.js say your date format is m/d/ and the initial value is 1/1/2011 and you want to change it to 2/1/2011.. that is not possible. changing month, the selected 'day' is still selected and therefore not selectable. use case: initial date is 1/1/2011 1. open date picker 2. change month to feb 3. try to click on 1st of feb - nothing happens. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TAP5-1452) messages property lookup for enum values is inconsistent, and incorrect
messages property lookup for enum values is inconsistent, and incorrect
---
Key: TAP5-1452
URL: https://issues.apache.org/jira/browse/TAP5-1452
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.7, 5.2.4
Reporter: Paul Stanton
Priority: Minor
I work on a project which has a few different entities each with their own
specific ranges of potential values for 'Category'. The way this project has
achieved this is to inline Enums within the entity class. Unfortunately, the
classes all define an enum named Category, ie:
public class EntityOne
{
enum Category {...};
private Category category;
}
public class EntityTwo
{
enum Category {...};
private Category category;
}
The EnumSelectModel uses TapestryInternalUtils.getLabelForEnum(Messages
messages, String prefix, Enum value) where prefix is enumClass.getSimpleName()
This makes it impossible to differentiate inline enums in different classes
with the same name since EntityOne.Category and EntityTwo.Category would both
have the prefix Category.
After doing some further digging I also found that there was another way to
resolve a message for an enum value:
TapestryInternalUtils.getLabelForEnum(Messages messages, Enum value) which is
used by PropertyDisplayBlocks. This method is slightly better since it would
look for EntityOne$Category instead of just Category, however I think it would
be better still to use the fully qualified name.
I think it is important to
a) be consistent
b) allow for all cases
Here is my solution:
1. scrap TapestryInternalUtils.getLabelForEnum(Messages messages, String
prefix, Enum value) and move the cascading logic into
TapestryInternalUtils.getLabelForEnum(Messages messages, Enum value), update
EnumSelectModel to use TapestryInternalUtils.getLabelForEnum(Messages messages,
Enum value).
2. change the cascading lookup logic to
a) test for [value.getClass().getName() + . + value.name()]
b) test for [lastTerm(value.getClass().getName()) + . + value.name()]
c) test for [value.getClass().getSimpleName() + . + value.name()]
d) test for [value.name()]
The code:
public static String getLabelForEnum(Messages messages, Enum value)
{
String key1 = value.getClass().getName() + . + value.name();
if (messages.contains(key1))
return messages.get(key1);
String key2 = lastTerm(value.getClass().getName()) + . + value.name();
if (messages.contains(key2))
return messages.get(key2);
String key3 = value.getClass().getSimpleName() + . + value.name();
if (messages.contains(key3))
return messages.get(key3);
String key4 = value.name();
if (messages.contains(key4))
return messages.get(key4);
return toUserPresentable(value.name().toLowerCase());
}
EnumSelectModel and PropertyDisplayBlocks could use this without issue and be
fully backwards compatible with previously defined message properties.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TAP5-1452) messages property lookup for enum values is inconsistent, and incorrect
[
https://issues.apache.org/jira/browse/TAP5-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999852#comment-12999852
]
Paul Stanton commented on TAP5-1452:
Also, it's probably a good idea to return or null if value parameter is null.
messages property lookup for enum values is inconsistent, and incorrect
---
Key: TAP5-1452
URL: https://issues.apache.org/jira/browse/TAP5-1452
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.2.4, 5.1.0.7
Reporter: Paul Stanton
Priority: Minor
I work on a project which has a few different entities each with their own
specific ranges of potential values for 'Category'. The way this project has
achieved this is to inline Enums within the entity class. Unfortunately, the
classes all define an enum named Category, ie:
public class EntityOne
{
enum Category {...};
private Category category;
}
public class EntityTwo
{
enum Category {...};
private Category category;
}
The EnumSelectModel uses TapestryInternalUtils.getLabelForEnum(Messages
messages, String prefix, Enum value) where prefix is enumClass.getSimpleName()
This makes it impossible to differentiate inline enums in different classes
with the same name since EntityOne.Category and EntityTwo.Category would both
have the prefix Category.
After doing some further digging I also found that there was another way to
resolve a message for an enum value:
TapestryInternalUtils.getLabelForEnum(Messages messages, Enum value) which is
used by PropertyDisplayBlocks. This method is slightly better since it would
look for EntityOne$Category instead of just Category, however I think it
would be better still to use the fully qualified name.
I think it is important to
a) be consistent
b) allow for all cases
Here is my solution:
1. scrap TapestryInternalUtils.getLabelForEnum(Messages messages, String
prefix, Enum value) and move the cascading logic into
TapestryInternalUtils.getLabelForEnum(Messages messages, Enum value), update
EnumSelectModel to use TapestryInternalUtils.getLabelForEnum(Messages
messages, Enum value).
2. change the cascading lookup logic to
a) test for [value.getClass().getName() + . + value.name()]
b) test for [lastTerm(value.getClass().getName()) + . + value.name()]
c) test for [value.getClass().getSimpleName() + . + value.name()]
d) test for [value.name()]
The code:
public static String getLabelForEnum(Messages messages, Enum value)
{
String key1 = value.getClass().getName() + . + value.name();
if (messages.contains(key1))
return messages.get(key1);
String key2 = lastTerm(value.getClass().getName()) + . +
value.name();
if (messages.contains(key2))
return messages.get(key2);
String key3 = value.getClass().getSimpleName() + . + value.name();
if (messages.contains(key3))
return messages.get(key3);
String key4 = value.name();
if (messages.contains(key4))
return messages.get(key4);
return toUserPresentable(value.name().toLowerCase());
}
EnumSelectModel and PropertyDisplayBlocks could use this without issue and be
fully backwards compatible with previously defined message properties.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TAP5-1408) datefield popup does not have option to cancel
[ https://issues.apache.org/jira/browse/TAP5-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979536#action_12979536 ] Paul Stanton commented on TAP5-1408: my patch for TAP5-1409 partially resolves this as it allows the user to close the popup by selecting the current value. i think this, combined with changing the calendar icon (that launches the popup) to something that describes a close action (like an 'x') would completely resolve this issue. datefield popup does not have option to cancel -- Key: TAP5-1408 URL: https://issues.apache.org/jira/browse/TAP5-1408 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.2.4 Reporter: Paul Stanton using the datefield component, if a user changes their mind there seems to be no way for them to close the popup without changing the value in some way. once the icon has been clicked, there's no option to close the popup explicitly and selecting the current value is disabled so the user has to select another date to close the popup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1409) datefield - cannot select same day in different month
[ https://issues.apache.org/jira/browse/TAP5-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979535#action_12979535 ] Paul Stanton commented on TAP5-1409: a workaround/patch is to remove the lines 345-348 in datepicker.js: if (this._selectedDate.getDate() != oDate.getDate() || this._selectedDate.getMonth() != oDate.getMonth() || this._selectedDate.getFullYear() != oDate.getFullYear() || this._none) however this does not solve the fact that the date is highlighted on all months, ie if you start with 1/1, then 2/1 and 3/1 and 4/1 etc will also be highlighted (css class selected). this patch also partially resolves TAP5-1408 as you can now close the popup by selecting the current date. datefield - cannot select same day in different month - Key: TAP5-1409 URL: https://issues.apache.org/jira/browse/TAP5-1409 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.2.4 Reporter: Paul Stanton say your date format is m/d/ and the initial value is 1/1/2011 and you want to change it to 2/1/2011.. that is not possible. changing month, the selected 'day' is still selected and therefore not selectable. use case: initial date is 1/1/2011 1. open date picker 2. change month to feb 3. try to click on 1st of feb - nothing happens. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1408) datefield popup does not have option to cancel
datefield popup does not have option to cancel -- Key: TAP5-1408 URL: https://issues.apache.org/jira/browse/TAP5-1408 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.2.4 Reporter: Paul Stanton using the datefield component, if a user changes their mind there seems to be no way for them to close the popup without changing the value in some way. once the icon has been clicked, there's no option to close the popup explicitly and selecting the current value is disabled so the user has to select another date to close the popup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1409) datefield - cannot select same day in different month
datefield - cannot select same day in different month - Key: TAP5-1409 URL: https://issues.apache.org/jira/browse/TAP5-1409 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.2.4 Reporter: Paul Stanton say your date format is m/d/ and the initial value is 1/1/2011 and you want to change it to 2/1/2011.. that is not possible. changing month, the selected 'day' is still selected and therefore not selectable. use case: initial date is 1/1/2011 1. open date picker 2. change month to feb 3. try to click on 1st of feb - nothing happens. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1407) multizoneupdate should be easier to use - not a chain
[
https://issues.apache.org/jira/browse/TAP5-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Stanton updated TAP5-1407:
---
Fix Version/s: (was: 5.2.4)
multizoneupdate should be easier to use - not a chain
-
Key: TAP5-1407
URL: https://issues.apache.org/jira/browse/TAP5-1407
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Paul Stanton
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which
doesn't make much sense.
In some cases it would be much easier if you could construct a
MultiZoneUpdate object without actually contributing a zone update directive.
ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3, zone3);
mzu.add(zone3, zone3); // knocks out prev zone3 update
...
return mzu;
I have created a utility class which helps me work around this issue (and
issue #TAP5-1406), however note it relies on the dummy zone hack.:
import java.util.HashMap;
import java.util.Map.Entry;
import org.apache.tapestry5.ComponentResources;
import org.apache.tapestry5.MarkupWriter;
import org.apache.tapestry5.ajax.MultiZoneUpdate;
import org.apache.tapestry5.internal.services.PageRenderQueue;
import org.apache.tapestry5.json.JSONObject;
import org.apache.tapestry5.services.PartialMarkupRenderer;
import org.apache.tapestry5.services.PartialMarkupRendererFilter;
import org.apache.tapestry5.services.javascript.JavaScriptSupport;
public class XHRResponseHelper
{
private HashMapString, Object zoneUpdates;
private boolean scriptAdded;
public XHRResponseHelper()
{
this.zoneUpdates = new HashMapString, Object();
scriptAdded = false;
}
public void addScriptCall(final String script, PageRenderQueue
pageRenderQueue, final JavaScriptSupport javascriptSupport)
{
scriptAdded = true;
pageRenderQueue.addPartialMarkupRendererFilter(new
PartialMarkupRendererFilter()
{
public void renderMarkup(MarkupWriter writer,
JSONObject reply, PartialMarkupRenderer renderer)
{
javascriptSupport.addScript(script);
renderer.renderMarkup(writer, reply);
}
});
}
public void addZoneUpdate(String zoneId, ComponentResources
componentResources)
{
addZoneUpdate(zoneId,
componentResources.getEmbeddedComponent(zoneId));
}
public void addZoneUpdate(String zoneId, Object renderer)
{
zoneUpdates.put(zoneId, renderer);
}
public MultiZoneUpdate buildMultiZoneUpdate(ComponentResources
componentResources)
{
// work around issue -
https://issues.apache.org/jira/browse/TAP5-1406
if (zoneUpdates.isEmpty() scriptAdded)
addZoneUpdate(dummyZone, componentResources);
MultiZoneUpdate mzu = null;
for (EntryString, Object entry : zoneUpdates.entrySet())
{
if (mzu == null)
mzu = new MultiZoneUpdate(entry.getKey(),
entry.getValue());
else
mzu = mzu.add(entry.getKey(), entry.getValue());
}
return mzu; // null if zoneUpdates is empty
}
}
usage:
XHRResponseHelper response = new XHRResponseHelper();
response.addZoneUpdate(myZone, componentResources);
response.addZoneUpdate(myZone2, block);
response.addScriptCall(alert('script');, pageRenderQueue,
javascriptSupport);
return response.buildMultiZoneUpdate(componentResources);
hope that helps.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1408) datefield popup does not have option to cancel
[ https://issues.apache.org/jira/browse/TAP5-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979412#action_12979412 ] Paul Stanton commented on TAP5-1408: ah, didn't notice that .. i tried clicking within the textfield its self, clicking outside, clicking the existing value cell ... perhaps a close icon would be most intuitive for dumb users like myself. datefield popup does not have option to cancel -- Key: TAP5-1408 URL: https://issues.apache.org/jira/browse/TAP5-1408 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.2.4 Reporter: Paul Stanton using the datefield component, if a user changes their mind there seems to be no way for them to close the popup without changing the value in some way. once the icon has been clicked, there's no option to close the popup explicitly and selecting the current value is disabled so the user has to select another date to close the popup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1407) multizoneupdate should be easier to use - not a chain
[
https://issues.apache.org/jira/browse/TAP5-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978935#action_12978935
]
Paul Stanton commented on TAP5-1407:
good, that is kind of what i'm suggesting too.
if it were a service, would it be an environmental? if so, wouldn't it fall
into the trap of being bound to one 'component layer'?
in one 'xhr-response' i often need to create zone updates for zones at
different levels ie (note the method
'addSomeZoneUpdatesUsingYourOwnComponentResources'):
public class MyPage
{
...
@InjectComponent
private MyComponent myComponent;
private MultiZoneUpdate onMyEvent()
{
XHRResponseHelper response = new XHRResponseHelper();
response.addZoneUpdate(myZone, componentResources);
myComponent.addSomeZoneUpdatesUsingYourOwnComponentResources(response);
response.addScriptCall(alert('script');, pageRenderQueue, javascriptSupport);
return response.buildMultiZoneUpdate(componentResources);
}
this is why i have the environmentals as parameters for my helper class .. so
that the response can be contributed to from multiple 'environments' ie
components.
multizoneupdate should be easier to use - not a chain
-
Key: TAP5-1407
URL: https://issues.apache.org/jira/browse/TAP5-1407
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Paul Stanton
Fix For: 5.2.4
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which
doesn't make much sense.
In some cases it would be much easier if you could construct a
MultiZoneUpdate object without actually contributing a zone update directive.
ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3, zone3);
mzu.add(zone3, zone3); // knocks out prev zone3 update
...
return mzu;
I have created a utility class which helps me work around this issue (and
issue #TAP5-1406), however note it relies on the dummy zone hack.:
import java.util.HashMap;
import java.util.Map.Entry;
import org.apache.tapestry5.ComponentResources;
import org.apache.tapestry5.MarkupWriter;
import org.apache.tapestry5.ajax.MultiZoneUpdate;
import org.apache.tapestry5.internal.services.PageRenderQueue;
import org.apache.tapestry5.json.JSONObject;
import org.apache.tapestry5.services.PartialMarkupRenderer;
import org.apache.tapestry5.services.PartialMarkupRendererFilter;
import org.apache.tapestry5.services.javascript.JavaScriptSupport;
public class XHRResponseHelper
{
private HashMapString, Object zoneUpdates;
private boolean scriptAdded;
public XHRResponseHelper()
{
this.zoneUpdates = new HashMapString, Object();
scriptAdded = false;
}
public void addScriptCall(final String script, PageRenderQueue
pageRenderQueue, final JavaScriptSupport javascriptSupport)
{
scriptAdded = true;
pageRenderQueue.addPartialMarkupRendererFilter(new
PartialMarkupRendererFilter()
{
public void renderMarkup(MarkupWriter writer,
JSONObject reply, PartialMarkupRenderer renderer)
{
javascriptSupport.addScript(script);
renderer.renderMarkup(writer, reply);
}
});
}
public void addZoneUpdate(String zoneId, ComponentResources
componentResources)
{
addZoneUpdate(zoneId,
componentResources.getEmbeddedComponent(zoneId));
}
public void addZoneUpdate(String zoneId, Object renderer)
{
zoneUpdates.put(zoneId, renderer);
}
public MultiZoneUpdate buildMultiZoneUpdate(ComponentResources
componentResources)
{
// work around issue -
https://issues.apache.org/jira/browse/TAP5-1406
if (zoneUpdates.isEmpty() scriptAdded)
addZoneUpdate(dummyZone, componentResources);
MultiZoneUpdate mzu = null;
for (EntryString, Object entry : zoneUpdates.entrySet())
{
if (mzu == null)
mzu = new MultiZoneUpdate(entry.getKey(),
[jira] Updated: (TAP5-1407) multizoneupdate should be easier to use - not a chain
[
https://issues.apache.org/jira/browse/TAP5-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Stanton updated TAP5-1407:
---
Description:
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which doesn't
make much sense.
In some cases it would be much easier if you could construct a MultiZoneUpdate
object without actually contributing a zone update directive. ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3, zone3);
mzu.add(zone3, zone3); // knocks out prev zone3 update
...
return mzu;
I have created a utility class which helps me work around this issue (and issue
#TAP5-1406), however note it relies on the dummy zone hack.:
import java.util.HashMap;
import java.util.Map.Entry;
import org.apache.tapestry5.ComponentResources;
import org.apache.tapestry5.MarkupWriter;
import org.apache.tapestry5.ajax.MultiZoneUpdate;
import org.apache.tapestry5.internal.services.PageRenderQueue;
import org.apache.tapestry5.json.JSONObject;
import org.apache.tapestry5.services.PartialMarkupRenderer;
import org.apache.tapestry5.services.PartialMarkupRendererFilter;
import org.apache.tapestry5.services.javascript.JavaScriptSupport;
public class XHRResponseHelper
{
private HashMapString, Object zoneUpdates;
private boolean scriptAdded;
public XHRResponseHelper()
{
this.zoneUpdates = new HashMapString, Object();
scriptAdded = false;
}
public void addScriptCall(final String script, PageRenderQueue
pageRenderQueue, final JavaScriptSupport javascriptSupport)
{
scriptAdded = true;
pageRenderQueue.addPartialMarkupRendererFilter(new
PartialMarkupRendererFilter()
{
public void renderMarkup(MarkupWriter writer,
JSONObject reply, PartialMarkupRenderer renderer)
{
javascriptSupport.addScript(script);
renderer.renderMarkup(writer, reply);
}
});
}
public void addZoneUpdate(String zoneId, ComponentResources
componentResources)
{
addZoneUpdate(zoneId,
componentResources.getEmbeddedComponent(zoneId));
}
public void addZoneUpdate(String zoneId, Object renderer)
{
zoneUpdates.put(zoneId, renderer);
}
public MultiZoneUpdate buildMultiZoneUpdate(ComponentResources
componentResources)
{
// work around issue -
https://issues.apache.org/jira/browse/TAP5-1406
if (zoneUpdates.isEmpty() scriptAdded)
addZoneUpdate(dummyZone, componentResources);
MultiZoneUpdate mzu = null;
for (EntryString, Object entry : zoneUpdates.entrySet())
{
if (mzu == null)
mzu = new MultiZoneUpdate(entry.getKey(),
entry.getValue());
else
mzu = mzu.add(entry.getKey(), entry.getValue());
}
return mzu; // null if zoneUpdates is empty
}
}
usage:
XHRResponseHelper response = new XHRResponseHelper();
response.addZoneUpdate(myZone, componentResources);
response.addZoneUpdate(myZone2, block);
response.addScriptCall(alert('script');, pageRenderQueue, javascriptSupport);
return response.buildMultiZoneUpdate(componentResources);
hope that helps.
was:
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which doesn't
make much sense.
In some cases it would be much easier if you could construct a MultiZoneUpdate
object without actually contributing a zone update directive. ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
[jira] Created: (TAP5-1404) add 'xhr' parameter to components which perform navigation - make zone parameter optional
add 'xhr' parameter to components which perform navigation - make zone parameter optional - Key: TAP5-1404 URL: https://issues.apache.org/jira/browse/TAP5-1404 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.2.4 Reporter: Paul Stanton To specify that you want to perform an XHR request (EventLink, ActionLink, Form etc), you need to supply the zone parameter. The existence of this parameter is a flag that tells the component to use XHR. In some cases this may be useful (although I'm yet to find one). This strikes me as bad design since there is not necessarily a known One-to-One relationship between the event and the zone(s) updated. If you return a Zone or MultiZoneUpdate from your event handler, the actual zone you supply the requesting component is irrelevant. Since all of my XHR event handlers return a MultiZoneUpdate, I ended up creating a dummy zone on every page and component and supplying that to every zone parameter. The dummy zone was always hidden and never actually updated. This hack made it easier to code and maintain my pages because without it i would need to search for an arbitrary zone on each page when creating callbacks. The solution would be to add a 'xhr' parameter to the components (EventLink, Form etc) and for the zone parameter to be an optional if xhr is true. You could even hard set xhr=true if zone!=null for backwards compatibility. This would require Tapestry to lose the dependency on zones to create contextual XHR requests which I think is the limiting design decision plaguing this area of tapestry. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1406) xhr - javascriptSupport.addScript should work without any zone updates
xhr - javascriptSupport.addScript should work without any zone updates
--
Key: TAP5-1406
URL: https://issues.apache.org/jira/browse/TAP5-1406
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Paul Stanton
If you have an xhr event handler which returns null, but does add a script to
the render, the script should still be executed.
currently I have to make sure that I perform at least one zone update when
returning a MultiZoneUpdate, ie if I were to return null the script would not
be executed on the client.
This forces me to rely on a dummy zone hack for cases when all i want to do is
call a script.
eg
private MultiZoneUpdate onSomething()
{
pageRenderQueue.addPartialMarkupRendererFilter(new
PartialMarkupRendererFilter()
{
public void renderMarkup(MarkupWriter writer,
JSONObject reply, PartialMarkupRenderer renderer)
{
javascriptSupport.addScript(alert('here'););
renderer.renderMarkup(writer, reply);
}
});
return null;
}
^ the alert would not show
private MultiZoneUpdate onSomething()
{
pageRenderQueue.addPartialMarkupRendererFilter(new
PartialMarkupRendererFilter()
{
public void renderMarkup(MarkupWriter writer,
JSONObject reply, PartialMarkupRenderer renderer)
{
javascriptSupport.addScript(alert('here'););
renderer.renderMarkup(writer, reply);
}
});
return new MultiZoneUpdate(dummyZone, dummyZone);
}
^ the alert would show provided dummyZone exists.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1407) multizoneupdate should be easier to use - not a chain
multizoneupdate should be easier to use - not a chain - Key: TAP5-1407 URL: https://issues.apache.org/jira/browse/TAP5-1407 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.4 Reporter: Paul Stanton Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); mzu.add(zone2, zone2); mzu.add(zone3, zone3); ... return mzu; This becomes hard to use when event handlers call common methods which contribute zone updates. Also, it is possible to request multiple updates for the one zone which doesn't make much sense. In some cases it would be much easier if you could construct a MultiZoneUpdate object without actually contributing a zone update directive. ie: MultiZoneUpdate mzu = new MultiZoneUpdate(); mzu.add(zone2, zone1); mzu.add(zone2, zone2); mzu.add(zone3, zone3); ... return mzu; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1407) multizoneupdate should be easier to use - not a chain
[
https://issues.apache.org/jira/browse/TAP5-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Stanton updated TAP5-1407:
---
Description:
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which doesn't
make much sense.
In some cases it would be much easier if you could construct a MultiZoneUpdate
object without actually contributing a zone update directive. ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3, zone3);
mzu.add(zone3, zone3); // knocks out prev zone3 update
...
return mzu;
in my utility class, i create a map of updates and construct the
MultiZoneUpdate chain at the end.
was:
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1);
mzu = mzu.add(zone2, zone2);
mzu = mzu.add(zone3, zone3);
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which doesn't
make much sense.
In some cases it would be much easier if you could construct a MultiZoneUpdate
object without actually contributing a zone update directive. ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3, zone3);
...
return mzu;
multizoneupdate should be easier to use - not a chain
-
Key: TAP5-1407
URL: https://issues.apache.org/jira/browse/TAP5-1407
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Paul Stanton
Fix For: 5.2.4
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which
doesn't make much sense.
In some cases it would be much easier if you could construct a
MultiZoneUpdate object without actually contributing a zone update directive.
ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3, zone3);
mzu.add(zone3, zone3); // knocks out prev zone3 update
...
return mzu;
in my utility class, i create a map of updates and construct the
MultiZoneUpdate chain at the end.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1407) multizoneupdate should be easier to use - not a chain
[
https://issues.apache.org/jira/browse/TAP5-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Stanton updated TAP5-1407:
---
Description:
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which doesn't
make much sense.
In some cases it would be much easier if you could construct a MultiZoneUpdate
object without actually contributing a zone update directive. ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3, zone3);
mzu.add(zone3, zone3); // knocks out prev zone3 update
...
return mzu;
I have created a utility class which helps me work around this issue (and issue
#TAP5-1406), however note it relies on the dummy zone hack.:
import java.util.HashMap;
import java.util.Map.Entry;
import org.apache.tapestry5.ComponentResources;
import org.apache.tapestry5.MarkupWriter;
import org.apache.tapestry5.ajax.MultiZoneUpdate;
import org.apache.tapestry5.internal.services.PageRenderQueue;
import org.apache.tapestry5.json.JSONObject;
import org.apache.tapestry5.services.PartialMarkupRenderer;
import org.apache.tapestry5.services.PartialMarkupRendererFilter;
import org.apache.tapestry5.services.javascript.JavaScriptSupport;
public class XHRResponseHelper
{
private HashMapString, Object zoneUpdates;
private boolean scriptAdded;
public XHRResponseHelper()
{
this.zoneUpdates = new HashMapString, Object();
scriptAdded = false;
}
public void addScriptCall(final String script, PageRenderQueue
pageRenderQueue, final JavaScriptSupport javascriptSupport)
{
pageRenderQueue.addPartialMarkupRendererFilter(new
PartialMarkupRendererFilter()
{
public void renderMarkup(MarkupWriter writer,
JSONObject reply, PartialMarkupRenderer renderer)
{
javascriptSupport.addScript(script);
renderer.renderMarkup(writer, reply);
}
});
}
public void addZoneUpdate(String zoneId, ComponentResources
componentResources)
{
addZoneUpdate(zoneId,
componentResources.getEmbeddedComponent(zoneId));
}
public void addZoneUpdate(String zoneId, Object renderer)
{
zoneUpdates.put(zoneId, renderer);
}
public MultiZoneUpdate buildMultiZoneUpdate(ComponentResources
componentResources)
{
// work around issue -
https://issues.apache.org/jira/browse/TAP5-1406
if (zoneUpdates.isEmpty() scriptAdded)
addZoneUpdate(dummyZone, componentResources);
MultiZoneUpdate mzu = null;
for (EntryString, Object entry : zoneUpdates.entrySet())
{
if (mzu == null)
mzu = new MultiZoneUpdate(entry.getKey(),
entry.getValue());
else
mzu.add(entry.getKey(), entry.getValue());
}
return mzu; // null if zoneUpdates is empty
}
}
usage:
XHRResponseHelper response = new XHRResponseHelper();
response.addZoneUpdate(myZone, componentResources);
response.addZoneUpdate(myZone2, block);
response.addScriptCall(alert('script');, pageRenderQueue, javascriptSupport);
return response.buildMultiZoneUpdate(componentResources);
hope that helps.
was:
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which doesn't
make much sense.
In some cases it would be much easier if you could construct a MultiZoneUpdate
object without actually contributing a zone update directive. ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3, zone3);
mzu.add(zone3, zone3); //
[jira] Updated: (TAP5-1407) multizoneupdate should be easier to use - not a chain
[
https://issues.apache.org/jira/browse/TAP5-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Stanton updated TAP5-1407:
---
Description:
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which doesn't
make much sense.
In some cases it would be much easier if you could construct a MultiZoneUpdate
object without actually contributing a zone update directive. ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3, zone3);
mzu.add(zone3, zone3); // knocks out prev zone3 update
...
return mzu;
I have created a utility class which helps me work around this issue (and issue
#TAP5-1406), however note it relies on the dummy zone hack.:
import java.util.HashMap;
import java.util.Map.Entry;
import org.apache.tapestry5.ComponentResources;
import org.apache.tapestry5.MarkupWriter;
import org.apache.tapestry5.ajax.MultiZoneUpdate;
import org.apache.tapestry5.internal.services.PageRenderQueue;
import org.apache.tapestry5.json.JSONObject;
import org.apache.tapestry5.services.PartialMarkupRenderer;
import org.apache.tapestry5.services.PartialMarkupRendererFilter;
import org.apache.tapestry5.services.javascript.JavaScriptSupport;
public class XHRResponseHelper
{
private HashMapString, Object zoneUpdates;
private boolean scriptAdded;
public XHRResponseHelper()
{
this.zoneUpdates = new HashMapString, Object();
scriptAdded = false;
}
public void addScriptCall(final String script, PageRenderQueue
pageRenderQueue, final JavaScriptSupport javascriptSupport)
{
scriptAdded = true;
pageRenderQueue.addPartialMarkupRendererFilter(new
PartialMarkupRendererFilter()
{
public void renderMarkup(MarkupWriter writer,
JSONObject reply, PartialMarkupRenderer renderer)
{
javascriptSupport.addScript(script);
renderer.renderMarkup(writer, reply);
}
});
}
public void addZoneUpdate(String zoneId, ComponentResources
componentResources)
{
addZoneUpdate(zoneId,
componentResources.getEmbeddedComponent(zoneId));
}
public void addZoneUpdate(String zoneId, Object renderer)
{
zoneUpdates.put(zoneId, renderer);
}
public MultiZoneUpdate buildMultiZoneUpdate(ComponentResources
componentResources)
{
// work around issue -
https://issues.apache.org/jira/browse/TAP5-1406
if (zoneUpdates.isEmpty() scriptAdded)
addZoneUpdate(dummyZone, componentResources);
MultiZoneUpdate mzu = null;
for (EntryString, Object entry : zoneUpdates.entrySet())
{
if (mzu == null)
mzu = new MultiZoneUpdate(entry.getKey(),
entry.getValue());
else
mzu.add(entry.getKey(), entry.getValue());
}
return mzu; // null if zoneUpdates is empty
}
}
usage:
XHRResponseHelper response = new XHRResponseHelper();
response.addZoneUpdate(myZone, componentResources);
response.addZoneUpdate(myZone2, block);
response.addScriptCall(alert('script');, pageRenderQueue, javascriptSupport);
return response.buildMultiZoneUpdate(componentResources);
hope that helps.
was:
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}
usage:
MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;
This becomes hard to use when event handlers call common methods which
contribute zone updates.
Also, it is possible to request multiple updates for the one zone which doesn't
make much sense.
In some cases it would be much easier if you could construct a MultiZoneUpdate
object without actually contributing a zone update directive. ie:
MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3,
[jira] Commented: (TAP5-1263) private methods in class heirarchy override each other with @SetupRender annotation
[
https://issues.apache.org/jira/browse/TAP5-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12977399#action_12977399
]
Paul Stanton commented on TAP5-1263:
is this fixed now? chris your last comment kind of suggests it is...
private methods in class heirarchy override each other with @SetupRender
annotation
---
Key: TAP5-1263
URL: https://issues.apache.org/jira/browse/TAP5-1263
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Paul Stanton
Assignee: Christophe Cordenier
I've found a strange issue with the @SetupRender annotation when used in a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same signature
for a private method and not effect each other, so I would expect this to be
the case when both of these private methods are annotated with @SetupRender.
Therefore the output for case 1 and case 2 (below) should be the same and
print both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow overwrites the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1365) allow Translators to be registered by name and used as Formatters
allow Translators to be registered by name and used as Formatters - Key: TAP5-1365 URL: https://issues.apache.org/jira/browse/TAP5-1365 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.2.4 Reporter: Paul Stanton It's my understanding that a regression between version 5.1 and 5.2 meant that it is no longer possible to register translators by name (without some extra plumbing) via the 'translate' binding prefix. Instead you can override the default Translator for a particular type meaning you can have one translator per type. This means that the 'translate' binding prefix is perhaps redundant, since the translator could be selected by value type. I might be incorrect in my understanding but either way, I'd appreciate the discussion on the benefits of my suggested approach. What I suggest is at least a partial return to the old model whereby you could register a translator by name and for example have a 'date-long' translator and a 'date-short' translator co-exist, or a 'decimal-2dp' and a 'decimal-3dp' translator. you would then select the appropriate translator via the parameter binding t:textfield value=myDecimal translator=translate:decimal-2dp / Secondly, since Translators are capable of converting objects to text, there should be no reason why they couldn't be re-used as formatters, so you could also use t:output value=myDate format=translate:date-long / The inclusion of both of these features would allow a developer to create one set of Translators which are responsible for all object-to-text and text-to-object conversions throughout an application, thereby avoiding repetitive coding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1359) add 'registryAboutToShutdown' handler
add 'registryAboutToShutdown' handler - Key: TAP5-1359 URL: https://issues.apache.org/jira/browse/TAP5-1359 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-ioc Affects Versions: 5.2.4 Reporter: Paul Stanton It is impossible to inject a service into a handler of 'RegistryShutdownListener .registryDidShutdown' since the registry is already shutdown at this point. this makes it difficult to perform some more intricate termination logic when multiple services need to collude. I propose the inclusion of a new interface 'RegistryAboutToShutdownListener' with the method 'registryAboutToShutDown'. In the case of a tapestry application, it would need to be called after Http requests have been disallowed, but before the registry because unusable. There may need to be some ordered configuration to control service dependencies as they shut down, and I expect some other considerations I haven't thought of -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1359) add 'registryAboutToShutdown' handler
[ https://issues.apache.org/jira/browse/TAP5-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Stanton updated TAP5-1359: --- Description: It is impossible to inject a service into a handler of 'RegistryShutdownListener .registryDidShutdown' since the registry is already shutdown at this point. this makes it difficult to perform some more intricate termination logic when multiple services need to collude. I propose the inclusion of a new interface 'RegistryAboutToShutdownListener' with the method 'registryAboutToShutDown'. In the case of a tapestry application, it would need to be called after Http requests have been disallowed, but before the registry becomes unusable. There may need to be some ordered configuration to control service dependencies as they shut down, and I expect some other considerations I haven't thought of was: It is impossible to inject a service into a handler of 'RegistryShutdownListener .registryDidShutdown' since the registry is already shutdown at this point. this makes it difficult to perform some more intricate termination logic when multiple services need to collude. I propose the inclusion of a new interface 'RegistryAboutToShutdownListener' with the method 'registryAboutToShutDown'. In the case of a tapestry application, it would need to be called after Http requests have been disallowed, but before the registry because unusable. There may need to be some ordered configuration to control service dependencies as they shut down, and I expect some other considerations I haven't thought of for an example of when it would be useful see http://www.mail-archive.com/us...@tapestry.apache.org/msg48540.html add 'registryAboutToShutdown' handler - Key: TAP5-1359 URL: https://issues.apache.org/jira/browse/TAP5-1359 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-ioc Affects Versions: 5.2.4 Reporter: Paul Stanton It is impossible to inject a service into a handler of 'RegistryShutdownListener .registryDidShutdown' since the registry is already shutdown at this point. this makes it difficult to perform some more intricate termination logic when multiple services need to collude. I propose the inclusion of a new interface 'RegistryAboutToShutdownListener' with the method 'registryAboutToShutDown'. In the case of a tapestry application, it would need to be called after Http requests have been disallowed, but before the registry becomes unusable. There may need to be some ordered configuration to control service dependencies as they shut down, and I expect some other considerations I haven't thought of -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1359) add 'registryAboutToShutdown' handler
[ https://issues.apache.org/jira/browse/TAP5-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964956#action_12964956 ] Paul Stanton commented on TAP5-1359: sounds good, i have a workaround for my current case. cheers, p. add 'registryAboutToShutdown' handler - Key: TAP5-1359 URL: https://issues.apache.org/jira/browse/TAP5-1359 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-ioc Affects Versions: 5.2.4 Reporter: Paul Stanton It is impossible to inject a service into a handler of 'RegistryShutdownListener .registryDidShutdown' since the registry is already shutdown at this point. this makes it difficult to perform some more intricate termination logic when multiple services need to collude. I propose the inclusion of a new interface 'RegistryAboutToShutdownListener' with the method 'registryAboutToShutDown'. In the case of a tapestry application, it would need to be called after Http requests have been disallowed, but before the registry becomes unusable. There may need to be some ordered configuration to control service dependencies as they shut down, and I expect some other considerations I haven't thought of -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-746) Zone should include an option to periodically update itself
[ https://issues.apache.org/jira/browse/TAP5-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932645#action_12932645 ] Paul Stanton commented on TAP5-746: --- i agree, this should not be added directly to the zone component. there are other considerations, like which event last updated the zone? was it part of a multizoneupdate? if you hand control to the zone to decide where to ask for an update, it is likely to get it wrong. often, a zone in my applications could be updated by many different events within the same page. Zone should include an option to periodically update itself --- Key: TAP5-746 URL: https://issues.apache.org/jira/browse/TAP5-746 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Howard M. Lewis Ship By default, it should re-render its own body, unless some other renderable result is return by event handlers for the update event it will trigger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-48) Let Tapestry - Hibernate connect to multiple databases
[ https://issues.apache.org/jira/browse/TAP5-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12909082#action_12909082 ] Paul Stanton commented on TAP5-48: -- @Pierce Wetter can you give a couple of hints on how to do this with JPA? does tapestry-hibernate already look at persistence.xml for configuration? if not how can i configure it so that it does? or are you talking hypothetically if tapestry-hibernate was modified to be compatible? Let Tapestry - Hibernate connect to multiple databases -- Key: TAP5-48 URL: https://issues.apache.org/jira/browse/TAP5-48 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-hibernate Affects Versions: 5.0.15 Environment: All Reporter: Ville Virtanen Tapestry - Hibernate integration should include mechanism to connect to multiple databases via named sessions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1263) private methods in class heirarchy override each other with @SetupRender annotation
private methods in class heirarchy override each other with @SetupRender
annotation
---
Key: TAP5-1263
URL: https://issues.apache.org/jira/browse/TAP5-1263
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Paul Stanton
I've found a strange issue with the @SetupRender annotation when used in a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same signature for
a private method and not effect each other, so I would expect this to be the
case when both of these private methods are annotated with @SetupRender.
Therefore the output for case 1 and case 2 (below) should be the same and print
both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow overwrites the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1181) submit component does not set id attribute to t:id value
[ https://issues.apache.org/jira/browse/TAP5-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12877621#action_12877621 ] Paul Stanton commented on TAP5-1181: add the Hidden component to this... submit component does not set id attribute to t:id value Key: TAP5-1181 URL: https://issues.apache.org/jira/browse/TAP5-1181 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Paul Stanton Priority: Minor other form components (for example TextField) will set the value of the 'name' and 'id' attributes to the value of the 't:id' attribute, however the 'submit' component does not. input t:type=submit t:id=mySubmit value=submit / renders to: input value=submit name=mySubmit type=submit/input expected: input value=submit name=mySubmit id=mySubmit type=submit/input -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1175) single quote escapted to apos; causes issues in ie8
[
https://issues.apache.org/jira/browse/TAP5-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12877190#action_12877190
]
Paul Stanton commented on TAP5-1175:
thanks igor, sorry i didn't find this bug before. i've patched my app and am
awaiting the 5.1.06 release!
single quote escapted to apos; causes issues in ie8
Key: TAP5-1175
URL: https://issues.apache.org/jira/browse/TAP5-1175
Project: Tapestry 5
Issue Type: Bug
Affects Versions: 5.1
Environment: ie8 browser
Reporter: Paul Stanton
Assignee: Igor Drobiazko
Original Estimate: 0.02h
Remaining Estimate: 0.02h
Tapestry escapes single quotes in attribute values using apos; which causes
issues in ie8. the correct technique to avoid the ie8 issue is to use the hex
number in the ascii reference.
for example the content of the zone
t:zone ...
a href= onclick=alert('hi'); return false;hi/a
/t:zone
will be encoded into the following string within the JSON in the XHR response:
a href='' onclick='alert(apos;hiapos;); return false;'hi/a
This will cause a syntax error in ie8.
PATCH:
Tapestry 5.1.0.5,
org.apache.tapestry5.dom.AbstractMarkupModel
line 136
builder.append(apos;);
change to
builder.append(#39;);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1181) submit component does not set id attribute to t:id value
submit component does not set id attribute to t:id value Key: TAP5-1181 URL: https://issues.apache.org/jira/browse/TAP5-1181 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Paul Stanton Priority: Minor other form components (for example TextField) will set the value of the 'name' and 'id' attributes to the value of the 't:id' attribute, however the 'submit' component does not. input t:type=submit t:id=mySubmit value=submit / renders to: input value=submit name=mySubmit type=submit/input expected: input value=submit name=mySubmit id=mySubmit type=submit/input -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1180) LinkSubmit does nothing
[
https://issues.apache.org/jira/browse/TAP5-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Stanton updated TAP5-1180:
---
looks like the same as TAP5-930 however he did not describe it properly.
LinkSubmit does nothing
---
Key: TAP5-1180
URL: https://issues.apache.org/jira/browse/TAP5-1180
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Paul Stanton
After stepping through the javascript, I believe it's because the onsubmit
event handler for the form is javascript:Tapestry.waitForPage(event); who's
first line is if (Tapestry.pageLoaded) return;.
This is the equivalent of if (Tapestry.pageLoaded) return false; when
evaluated to a boolean as it is in the LinkSubmit onClick handler:
if (onsubmit == undefined || onsubmit.call(window.document, event))
{
this.createHidden();
this.form.submit();
}
.. and therefore this.form.submit(); is never called.
Obviously this is a bug, I'm pretty sure the resolution would be to change
Tapestry.waitForPage so that it returns true if the page is loaded and false
otherwise, ie:
waitForPage : function(event)
{
if (Tapestry.pageLoaded) return true;
...
return false;
}
This will allow 'waitForPage' to be evaluated to a boolean as it is in
LinkSubmit.onClick, however there may be a better solution.
EG:
MyPage.tml:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:t=http://tapestry.apache.org/schema/tapestry_5_1_0.xsd;
xmlns:p=tapestry:parameter
t:form t:id=myForm
t:linksubmit t:id=myLinklink/t:linksubmit
t:submit t:id=mySubmit /
/t:form
/html
MyPage.java
public Class MyPage
{
public void onSuccessFromMyForm()
{
LOG.debug(onSuccessFromMyForm);
}
public void onSelectedFromMyLink()
{
LOG.debug(onSelectedFromMyLink);
}
public void onSelectedFromMySubmit()
{
LOG.debug(onSelectedFromMySubmit);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1180) LinkSubmit does nothing
[
https://issues.apache.org/jira/browse/TAP5-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12876540#action_12876540
]
Paul Stanton commented on TAP5-1180:
i've tested my above idea re returning true from waitForPage and it didn't work.
it seems that 'onsubmit.call(window.document, event)' returns 'undefined'
regardless of what the function returns.
therefore my workaround is to comment out the whole if statement in
LinkSubmit.onClick:
// if (onsubmit == undefined || onsubmit.call(window.document, event))
{
this.createHidden();
this.form.submit();
}
Having done this, linksubmit works again, however obviously it doesn't handle a
premature click properly.
Hope that helps you find the proper solution.
p.
LinkSubmit does nothing
---
Key: TAP5-1180
URL: https://issues.apache.org/jira/browse/TAP5-1180
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Paul Stanton
After stepping through the javascript, I believe it's because the onsubmit
event handler for the form is javascript:Tapestry.waitForPage(event); who's
first line is if (Tapestry.pageLoaded) return;.
This is the equivalent of if (Tapestry.pageLoaded) return false; when
evaluated to a boolean as it is in the LinkSubmit onClick handler:
if (onsubmit == undefined || onsubmit.call(window.document, event))
{
this.createHidden();
this.form.submit();
}
.. and therefore this.form.submit(); is never called.
Obviously this is a bug, I'm pretty sure the resolution would be to change
Tapestry.waitForPage so that it returns true if the page is loaded and false
otherwise, ie:
waitForPage : function(event)
{
if (Tapestry.pageLoaded) return true;
...
return false;
}
This will allow 'waitForPage' to be evaluated to a boolean as it is in
LinkSubmit.onClick, however there may be a better solution.
EG:
MyPage.tml:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:t=http://tapestry.apache.org/schema/tapestry_5_1_0.xsd;
xmlns:p=tapestry:parameter
t:form t:id=myForm
t:linksubmit t:id=myLinklink/t:linksubmit
t:submit t:id=mySubmit /
/t:form
/html
MyPage.java
public Class MyPage
{
public void onSuccessFromMyForm()
{
LOG.debug(onSuccessFromMyForm);
}
public void onSelectedFromMyLink()
{
LOG.debug(onSelectedFromMyLink);
}
public void onSelectedFromMySubmit()
{
LOG.debug(onSelectedFromMySubmit);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
