[jira] [Commented] (TAP5-1866) ZoneRefresh mixin should perform cleanup if the zone is destroyed
[ https://issues.apache.org/jira/browse/TAP5-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986495#comment-13986495 ] ASF subversion and git services commented on TAP5-1866: --- Commit b97d9aa36a7c4826a329ebad7ca44a4067a48de9 in tapestry-5's branch refs/heads/master from [~jkemnade] [ https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;h=b97d9aa ] TAP5-1866: stop the ZoneRefresh timer if a Zone if removed from the DOM ZoneRefresh mixin should perform cleanup if the zone is destroyed - Key: TAP5-1866 URL: https://issues.apache.org/jira/browse/TAP5-1866 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3.2, 5.4 Reporter: Dragan Sahpaski Assignee: Jochen Kemnade Priority: Minor Labels: patch, zonerefresh Attachments: TAP5-1866.patch Consider the following use case: A zone with a ZoneRefresh (located in another zone) is updated several times and then the outer zone is updated with another block. Currently, after the update, exceptions are constantly thrown by the javascript PeriodicUpdater in zone-refresh.js on the line zoneRefresh.fire(Tapestry.ZONE_REFRESH_EVENT) because the div element that's linked to the zone with Tapestry.Initializer.updateZoneOnEvent is not destroyed and the corresponding timer is also not destroyed. The ZoneRefresh mixin should cleanup after itself in scenarios like this. A patch with tests is provided. Summary: 1. [MODIFIED] zone-refresh.js - On a timer update if the zone does not exist remove the div element on which the updates are triggered and stop the timer. 2. [MODIFIED] ZoneRefreshTest.java - One test method added 3. [ADDED]ZoneRefreshDestroyingZones.tml - Demo page with one outer zone with a ZoneRefresh mixin that toggles between two inner zones each a with ZoneRefresh mixin. 4. [ADDED]ZoneRefreshDestroyingZones.java 5. [MODIFIED] Index.tml - Link to ZoneRefreshDestroyingZones added The patch does not modify any public API. This patch is also blocked by TAP5-1867 SeleniumTestCase.waitForElementToDisappear(String elementId) does not seem to work, because the patch uses SeleniumTestCase.waitForElementToDisappear(String elementId). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TAP5-1866) ZoneRefresh mixin should perform cleanup if the zone is destroyed
[
https://issues.apache.org/jira/browse/TAP5-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-1866.
Resolution: Fixed
Fix Version/s: 5.4
The test will not work in 5.4 as the ZoneReferesh mixin does not create those
{{_refresh}} elements anymore. If you have a better idea how to write a test
for 5.4, please comment.
ZoneRefresh mixin should perform cleanup if the zone is destroyed
-
Key: TAP5-1866
URL: https://issues.apache.org/jira/browse/TAP5-1866
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3.2, 5.4
Reporter: Dragan Sahpaski
Assignee: Jochen Kemnade
Priority: Minor
Labels: patch, zonerefresh
Fix For: 5.4
Attachments: TAP5-1866.patch
Consider the following use case:
A zone with a ZoneRefresh (located in another zone) is updated several times
and then the outer zone is updated with another block.
Currently, after the update, exceptions are constantly thrown by the
javascript PeriodicUpdater in zone-refresh.js on the line
zoneRefresh.fire(Tapestry.ZONE_REFRESH_EVENT) because the div element
that's linked to the zone with Tapestry.Initializer.updateZoneOnEvent is not
destroyed and the corresponding timer is also not destroyed.
The ZoneRefresh mixin should cleanup after itself in scenarios like this.
A patch with tests is provided.
Summary:
1. [MODIFIED] zone-refresh.js - On a timer update if the zone does
not exist remove the div element on which the updates are triggered and
stop the timer.
2. [MODIFIED] ZoneRefreshTest.java - One test method added
3. [ADDED]ZoneRefreshDestroyingZones.tml - Demo page with one outer zone
with a ZoneRefresh mixin that toggles between two inner zones each a with
ZoneRefresh mixin.
4. [ADDED]ZoneRefreshDestroyingZones.java
5. [MODIFIED] Index.tml - Link to ZoneRefreshDestroyingZones added
The patch does not modify any public API.
This patch is also blocked by TAP5-1867
SeleniumTestCase.waitForElementToDisappear(String elementId) does not seem
to work,
because the patch uses SeleniumTestCase.waitForElementToDisappear(String
elementId).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TAP5-1866) ZoneRefresh mixin should perform cleanup if the zone is destroyed
[ https://issues.apache.org/jira/browse/TAP5-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986500#comment-13986500 ] Dragan Sahpaski commented on TAP5-1866: --- Thanks for resolving this. ZoneRefresh mixin should perform cleanup if the zone is destroyed - Key: TAP5-1866 URL: https://issues.apache.org/jira/browse/TAP5-1866 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3.2, 5.4 Reporter: Dragan Sahpaski Assignee: Jochen Kemnade Priority: Minor Labels: patch, zonerefresh Fix For: 5.4 Attachments: TAP5-1866.patch Consider the following use case: A zone with a ZoneRefresh (located in another zone) is updated several times and then the outer zone is updated with another block. Currently, after the update, exceptions are constantly thrown by the javascript PeriodicUpdater in zone-refresh.js on the line zoneRefresh.fire(Tapestry.ZONE_REFRESH_EVENT) because the div element that's linked to the zone with Tapestry.Initializer.updateZoneOnEvent is not destroyed and the corresponding timer is also not destroyed. The ZoneRefresh mixin should cleanup after itself in scenarios like this. A patch with tests is provided. Summary: 1. [MODIFIED] zone-refresh.js - On a timer update if the zone does not exist remove the div element on which the updates are triggered and stop the timer. 2. [MODIFIED] ZoneRefreshTest.java - One test method added 3. [ADDED]ZoneRefreshDestroyingZones.tml - Demo page with one outer zone with a ZoneRefresh mixin that toggles between two inner zones each a with ZoneRefresh mixin. 4. [ADDED]ZoneRefreshDestroyingZones.java 5. [MODIFIED] Index.tml - Link to ZoneRefreshDestroyingZones added The patch does not modify any public API. This patch is also blocked by TAP5-1867 SeleniumTestCase.waitForElementToDisappear(String elementId) does not seem to work, because the patch uses SeleniumTestCase.waitForElementToDisappear(String elementId). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-1867) SeleniumTestCase.waitForElementToDisappear(String elementId) does not seem to work
[
https://issues.apache.org/jira/browse/TAP5-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986501#comment-13986501
]
Dragan Sahpaski commented on TAP5-1867:
---
You're free to close this then.
SeleniumTestCase.waitForElementToDisappear(String elementId) does not seem to
work
--
Key: TAP5-1867
URL: https://issues.apache.org/jira/browse/TAP5-1867
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-test
Affects Versions: 5.3.2, 5.4
Reporter: Dragan Sahpaski
Labels: patch
Attachments: TAP5-1867.patch
In TAP5-1492 [1] New features for SeleniumTestCase one of the added
methods to SeleniumTestCase is waitForElementToDisappear.
The commit [2] is by Howard on 31 Mar 2011.
The Prototype hide() documentation [3] briefly says Hides and returns
element.
I don't see it used in any of the tapestry projects and don't know if anyone
has used it before.
Here is the code:
protected final void waitForElementToDisappear(String elementId)
{
String condition = String.format(window.$(\%s\).hide(),
elementId);
waitForCondition(condition, PAGE_LOAD_TIMEOUT);
}
IMO this method does not what it is supposed to do.
A Patch is provided just with one minor change
protected final void waitForElementToDisappear(String elementId)
{
String condition = String.format(window.$(\%s\) == undefined,
elementId);
waitForCondition(condition, PAGE_LOAD_TIMEOUT);
}
If there is a better approach please feel free to comment.
[1] TAP5-1492 https://issues.apache.org/jira/browse/TAP5-1492
[2] Commit
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-test/src/main/java/org/apache/tapestry5/test/SeleniumTestCase.java?p2=%2Ftapestry%2Ftapestry5%2Ftrunk%2Ftapestry-test%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Ftapestry5%2Ftest%2FSeleniumTestCase.javap1=%2Ftapestry%2Ftapestry5%2Ftrunk%2Ftapestry-test%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Ftapestry5%2Ftest%2FSeleniumTestCase.javar1=1087494r2=1087493view=diffpathrev=1087494
[3] Prototype hide() function http://prototypejs.org/api/element/hide
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (TAP5-1867) SeleniumTestCase.waitForElementToDisappear(String elementId) does not seem to work
[
https://issues.apache.org/jira/browse/TAP5-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-1867.
Resolution: Won't Fix
Alright, marking this as Won't Fix because the function is deprecated in 5.4.
SeleniumTestCase.waitForElementToDisappear(String elementId) does not seem to
work
--
Key: TAP5-1867
URL: https://issues.apache.org/jira/browse/TAP5-1867
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-test
Affects Versions: 5.3.2, 5.4
Reporter: Dragan Sahpaski
Labels: patch
Attachments: TAP5-1867.patch
In TAP5-1492 [1] New features for SeleniumTestCase one of the added
methods to SeleniumTestCase is waitForElementToDisappear.
The commit [2] is by Howard on 31 Mar 2011.
The Prototype hide() documentation [3] briefly says Hides and returns
element.
I don't see it used in any of the tapestry projects and don't know if anyone
has used it before.
Here is the code:
protected final void waitForElementToDisappear(String elementId)
{
String condition = String.format(window.$(\%s\).hide(),
elementId);
waitForCondition(condition, PAGE_LOAD_TIMEOUT);
}
IMO this method does not what it is supposed to do.
A Patch is provided just with one minor change
protected final void waitForElementToDisappear(String elementId)
{
String condition = String.format(window.$(\%s\) == undefined,
elementId);
waitForCondition(condition, PAGE_LOAD_TIMEOUT);
}
If there is a better approach please feel free to comment.
[1] TAP5-1492 https://issues.apache.org/jira/browse/TAP5-1492
[2] Commit
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-test/src/main/java/org/apache/tapestry5/test/SeleniumTestCase.java?p2=%2Ftapestry%2Ftapestry5%2Ftrunk%2Ftapestry-test%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Ftapestry5%2Ftest%2FSeleniumTestCase.javap1=%2Ftapestry%2Ftapestry5%2Ftrunk%2Ftapestry-test%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Ftapestry5%2Ftest%2FSeleniumTestCase.javar1=1087494r2=1087493view=diffpathrev=1087494
[3] Prototype hide() function http://prototypejs.org/api/element/hide
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TAP5-2129) Asset urls in CSS should be expanded/rewritten
[
https://issues.apache.org/jira/browse/TAP5-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986641#comment-13986641
]
Jochen Kemnade commented on TAP5-2129:
--
Howard, could you please have another look at this? Rewriting works for all
{{asset:}} bindings, buit-in (like {{classpath}} and {{context}}) or
user-defined. It will not work for custom *binding* prefixes though if that's
what you meant. Nevertheless, I think it would be an improvement if it worked
for assets.
Asset urls in CSS should be expanded/rewritten
--
Key: TAP5-2129
URL: https://issues.apache.org/jira/browse/TAP5-2129
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.4
Reporter: Jochen Kemnade
Labels: css, patch, test
Attachments: 0001-expand-asset-urls-in-CSS.patch
Asset URLs are treated as complete urls by CSSUrlRewriter, so they are not
rewritten.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TAP5-2327) The Cookies interface should provide an option to mark cookies as httpOnly
[ https://issues.apache.org/jira/browse/TAP5-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986756#comment-13986756 ] Ulrich Stärk commented on TAP5-2327: That would mean a dependency on a Servlet 3.0 compatible container. Tapestry 5.3 is Java 5 compatible and therefore requires the dependency to stay at Servlet 2.5. We are discussing to bump the Java compatibility to Java 8 though so 5.4 might see Servlet 3.1 and this feature. Uli The Cookies interface should provide an option to mark cookies as httpOnly -- Key: TAP5-2327 URL: https://issues.apache.org/jira/browse/TAP5-2327 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.3.7 Reporter: Martin Schneider Labels: security Since Servlet 3.0 there is an option to mark cookies as httpOnly via javax.servlet.http.Cookie.setHttpOnly(boolean). There should be an option to use that in org.apache.tapestry5.services.Cookies. In 5.3.7 the default implementation does not set the httpOnly flag. -- This message was sent by Atlassian JIRA (v6.2#6252)
