[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] [Commented] (TAP5-2325) Minification cache warming
[ https://issues.apache.org/jira/browse/TAP5-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13977998#comment-13977998 ] Dragan Sahpaski commented on TAP5-2325: --- Nice!. I've been wanting this for some time now. Minification cache warming -- Key: TAP5-2325 URL: https://issues.apache.org/jira/browse/TAP5-2325 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.4 Reporter: Jochen Kemnade It should be possible to configure that certain resources that should be minified during the application startup, the rationale being that it can take some time to minify large assets and that can lead to timeouts in requirejs when the resource is requested for the first time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TAP5-2325) Minification cache warming
[ https://issues.apache.org/jira/browse/TAP5-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13977998#comment-13977998 ] Dragan Sahpaski edited comment on TAP5-2325 at 4/23/14 8:57 AM: Nice! I've been wanting this for some time now. was (Author: dragan.sahpaski): Nice!. I've been wanting this for some time now. Minification cache warming -- Key: TAP5-2325 URL: https://issues.apache.org/jira/browse/TAP5-2325 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.4 Reporter: Jochen Kemnade It should be possible to configure that certain resources that should be minified during the application startup, the rationale being that it can take some time to minify large assets and that can lead to timeouts in requirejs when the resource is requested for the first time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2201) Serious issue with assets and checksums - different for same file
[ https://issues.apache.org/jira/browse/TAP5-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970555#comment-13970555 ] Dragan Sahpaski commented on TAP5-2201: --- Thanks. Serious issue with assets and checksums - different for same file - Key: TAP5-2201 URL: https://issues.apache.org/jira/browse/TAP5-2201 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Magnus Kvalheim Assignee: Howard M. Lewis Ship Labels: 5.4.22 Attachments: bootstrap.server2.css, bootstrap.server3.css, server2.png, server3.png Hi everybody. Today we've launched a website based on 5.4. We're very exited about the upcoming release(5.4) and I'll post separately about our experiences (mostly great). Post release we've identified a potential serious issue related to assets and their checksums. What we see is that a handful of the assets generate different hashes for the same file. =Example: bootstrap.css= Server 1: /asset.gz/meta/92ffb14a/tapestry5/bootstrap_3_0_0/css/bootstrap.css Server 2: /asset.gz/meta/5787e482/tapestry5/bootstrap_3_0_0/css/bootstrap.css Server 3: /asset.gz/meta/f5e7c535/tapestry5/bootstrap_3_0_0/css/bootstrap.css Server 3 - restart: /asset.gz/meta/219ee41e/tapestry5/bootstrap_3_0_0/css/bootstrap.css We also see the same behaviour for the non gzip version of bootstrap.css. It is not only for /meta/ =JCarouselWrapper.css= /asset/app/f59da774/mixins/ui/JCarouselWrapper.css /asset/app/6ddc92ee/mixins/ui/JCarouselWrapper.css As you can see - we're load balanced with app served from several nodes. Normally I'd serve these through CloudFront on a cookieless domain (with tapestry as origin), but it's not possible as load balanced assets could hit 'wrong' server and get the 404 instead. So for now they are served through website domain with sticky sessions - and pray that it don't cause us problems... :) All are served with same web container: Apache Tomcat/7.0.39 JDK 1.7.0_11 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947725#comment-13947725 ] Dragan Sahpaski commented on TAP5-2300: --- Excellent. Thanks for fixing it. JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947728#comment-13947728 ] Dragan Sahpaski commented on TAP5-2300: --- JIRA didn't resolve the issue probably because a FIXED or FIXES was absent from the commit message. Ready to be resolved now? JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[
https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947254#comment-13947254
]
Dragan Sahpaski commented on TAP5-2300:
---
Yes I have lost the right code somehow making it.
It should be
private void storeInitializerCall(InitializationPriority priority, String
functionName, Object... parameters)
and expand the JSONArrays like this
public void addInitializerCall(String functionName, JSONArray parameter)
{
storeInitializerCall(InitializationPriority.NORMAL, functionName,
parameter.toList().toArray());
}
public void addInitializerCall(InitializationPriority priority, String
functionName, JSONArray parameter)
{
storeInitializerCall(priority, functionName,
parameter.toList().toArray());
}
Anyway you got the idea. If you don't think it's the right approach there are
alternatives (doing it in javascript).
Tell me if you want the correct version of the patch.
JavaScriptSupport.addInitializerCall is not backwards compatible
Key: TAP5-2300
URL: https://issues.apache.org/jira/browse/TAP5-2300
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Dragan Sahpaski
Assignee: Kalle Korhonen
Attachments: TAP5-2300.patch
In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray
parameter) and void addInitializerCall(InitializationPriority priority,
String functionName, JSONArray parameter) are not backwards compatible with
tapestry 5.3.
Example:
javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b));
results with: Invoking t5/core/init(Test1, [a,b]), and it should result
with: Invoking t5/core/init(Test1, a, b) according to the behavior in
tapestry 5.3 also documented in the javadoc
http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority,
java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter -
array of parameters to pass to the client-side function.
The problem is with the way the code has been rewritten to use requirejs.
Here's the bug
https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201
parameter should be expanded when it's of type JSONArray.
I'm attaching a patch with fixes for 2 failing test methods (after applying
the patch) in JavaScriptSupportImplTest which are also wrong according to the
behavior in 5.3.
Please review.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Sahpaski updated TAP5-2300: -- Attachment: (was: TAP5-2300.patch) JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Sahpaski updated TAP5-2300: -- Attachment: TAP5-2300.patch JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947282#comment-13947282 ] Dragan Sahpaski commented on TAP5-2300: --- Attaching a patch that works. JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947291#comment-13947291 ] Dragan Sahpaski commented on TAP5-2300: --- Yes init is called with JSONArray(function, param1, param2, ...) like it should but know we have JSONArray(function, JSONArray(param1, param2, ...)) JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Assignee: Kalle Korhonen Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2302) Tapestry should ignore hashCode, equals and toString in module classes
[
https://issues.apache.org/jira/browse/TAP5-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937699#comment-13937699
]
Dragan Sahpaski commented on TAP5-2302:
---
What is your use case when using equals, toString and hashCode ? I'm intrigued
why would you use them in a module class.
Tapestry should ignore hashCode, equals and toString in module classes
--
Key: TAP5-2302
URL: https://issues.apache.org/jira/browse/TAP5-2302
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-ioc
Affects Versions: 5.4
Reporter: Jochen Kemnade
When {{equals}}, {{hashCode}} or {{toString}} are overridded in a module
class, Tapestry complains that those methods are unrecognized public
methods. For example, those methods will unconditionally be created by
{{gen-class}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
Dragan Sahpaski created TAP5-2300: - Summary: JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.4 Reporter: Dragan Sahpaski In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch which breaks 2 test methods in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Sahpaski updated TAP5-2300: -- Attachment: TAP5-2300.patch JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.4 Reporter: Dragan Sahpaski Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch which breaks 2 test methods in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TAP5-2300) JavaScriptSupport.addInitializerCall is not backwards compatible
[ https://issues.apache.org/jira/browse/TAP5-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Sahpaski updated TAP5-2300: -- Description: In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. was: In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch which breaks 2 test methods in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. JavaScriptSupport.addInitializerCall is not backwards compatible Key: TAP5-2300 URL: https://issues.apache.org/jira/browse/TAP5-2300 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Attachments: TAP5-2300.patch In JavaScriptSupport, void addInitializerCall(String functionName, JSONArray parameter) and void addInitializerCall(InitializationPriority priority, String functionName, JSONArray parameter) are not backwards compatible with tapestry 5.3. Example: javaScriptSupport.addInitializerCall(Test1, new JSONObject(a, b)); results with: Invoking t5/core/init(Test1, [a,b]), and it should result with: Invoking t5/core/init(Test1, a, b) according to the behavior in tapestry 5.3 also documented in the javadoc http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/javascript/JavaScriptSupport.html#addInitializerCall(org.apache.tapestry5.services.javascript.InitializationPriority, java.lang.String, org.apache.tapestry5.json.JSONArray). Quote parameter - array of parameters to pass to the client-side function. The problem is with the way the code has been rewritten to use requirejs. Here's the bug https://github.com/apache/tapestry-5/blob/549b148f9af1bdd65c1e80b81c31274cfa4f8491/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ajax/JavaScriptSupportImpl.java#L201 parameter should be expanded when it's of type JSONArray. I'm attaching a patch with fixes for 2 failing test methods (after applying the patch) in JavaScriptSupportImplTest which are also wrong according to the behavior in 5.3. Please review. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TAP5-2299) Update the gradle wrapper version from 1.3 to the latest
Dragan Sahpaski created TAP5-2299: - Summary: Update the gradle wrapper version from 1.3 to the latest Key: TAP5-2299 URL: https://issues.apache.org/jira/browse/TAP5-2299 Project: Tapestry 5 Issue Type: Task Affects Versions: 5.4 Reporter: Dragan Sahpaski Priority: Trivial As per the discussion here: http://tapestry.markmail.org/search/?q=list%3Aorg.apache.tapestry.dev#query:list%3Aorg.apache.tapestry.dev%20from%3A%22Ulrich%20St%C3%A4rk%22+page:1+mid:sxgr3eoo32aaoaf2+state:results the main build.gradle file is not compatible with gradle version 1.3. Please update to latest which currently is 1.11. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2201) Serious issue with assets and checksums - different for same file
[
https://issues.apache.org/jira/browse/TAP5-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859425#comment-13859425
]
Dragan Sahpaski commented on TAP5-2201:
---
Howard, In commit 83847d0 you didn't include image/svg+xml which is also a font
extension and currently we're facing issues in cases where the svg file is
gzipped.
For example glyphicons-halflings-regular is also served as svg (besides eot,
woff and tiff).
Excerpt from bootstrap.css where glyphicons-halflings-regular.svg is gzipped
and the other 3 formats are not:
@font-face{font-family:'Glyphicons
Halflings';src:url(/assets/meta/a81af715/tapestry5/bootstrap/fonts/glyphicons-halflings-regular.eot);src:url(/assets/meta/a81af715/tapestry5/bootstrap/fonts/glyphicons-halflings-regular.eot?#iefix)
format('embedded-opentype'),url(/assets/meta/b0153c27/tapestry5/bootstrap/fonts/glyphicons-halflings-regular.woff)
format('woff'),url(/assets/meta/534013db/tapestry5/bootstrap/fonts/glyphicons-halflings-regular.ttf)
format('truetype'),url(/assets/meta/zd792dbe6/tapestry5/bootstrap/fonts/glyphicons-halflings-regular.svg#glyphicons-halflingsregular)
format('svg')}
Could you please add the following line to
AssetsModule.disableCompressionForImageTypes(MappedConfigurationString,
Boolean configuration)
configuration.add(image/svg+xml, false);
Serious issue with assets and checksums - different for same file
-
Key: TAP5-2201
URL: https://issues.apache.org/jira/browse/TAP5-2201
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Magnus Kvalheim
Labels: 5.4.22
Attachments: bootstrap.server2.css, bootstrap.server3.css,
server2.png, server3.png
Hi everybody.
Today we've launched a website based on 5.4. We're very exited about the
upcoming release(5.4) and I'll post separately about our experiences (mostly
great).
Post release we've identified a potential serious issue related to assets and
their checksums.
What we see is that a handful of the assets generate different hashes for the
same file.
=Example: bootstrap.css=
Server 1:
/asset.gz/meta/92ffb14a/tapestry5/bootstrap_3_0_0/css/bootstrap.css
Server 2:
/asset.gz/meta/5787e482/tapestry5/bootstrap_3_0_0/css/bootstrap.css
Server 3:
/asset.gz/meta/f5e7c535/tapestry5/bootstrap_3_0_0/css/bootstrap.css
Server 3 - restart:
/asset.gz/meta/219ee41e/tapestry5/bootstrap_3_0_0/css/bootstrap.css
We also see the same behaviour for the non gzip version of bootstrap.css.
It is not only for /meta/
=JCarouselWrapper.css=
/asset/app/f59da774/mixins/ui/JCarouselWrapper.css
/asset/app/6ddc92ee/mixins/ui/JCarouselWrapper.css
As you can see - we're load balanced with app served from several nodes.
Normally I'd serve these through CloudFront on a cookieless domain (with
tapestry as origin), but it's not possible as load balanced assets could hit
'wrong' server and get the 404 instead.
So for now they are served through website domain with sticky sessions - and
pray that it don't cause us problems... :)
All are served with same web container:
Apache Tomcat/7.0.39
JDK 1.7.0_11
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TAP5-2267) Contributing ExceptionHandlerAssistant instances to RequestExceptionHandler is broken
Dragan Sahpaski created TAP5-2267: - Summary: Contributing ExceptionHandlerAssistant instances to RequestExceptionHandler is broken Key: TAP5-2267 URL: https://issues.apache.org/jira/browse/TAP5-2267 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Priority: Minor DefaultRequestExceptionHandler fails with ClassCastException when an instance of ExceptionHandlerAssistant is contributed to RequestExceptionHandler. This had been broken accidentally in commit cb3d4c853f47cccf9193c33cfd085d6ca27c8706 when implementing contributions of assistant classes that are autobuilt. Although DefaultRequestExceptionHandlerTest covers contributions of ExceptionHandlerAssistant instances, it didn't fail because of an oversight in the test. The patch resolves the bug (trivially) and improves existing tests in DefaultRequestExceptionHandlerTest which now fail without patching DefaultRequestExceptionHandler. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TAP5-2267) Contributing ExceptionHandlerAssistant instances to RequestExceptionHandler is broken
[ https://issues.apache.org/jira/browse/TAP5-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Sahpaski updated TAP5-2267: -- Attachment: TAP5-2267.patch Contributing ExceptionHandlerAssistant instances to RequestExceptionHandler is broken - Key: TAP5-2267 URL: https://issues.apache.org/jira/browse/TAP5-2267 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Dragan Sahpaski Priority: Minor Attachments: TAP5-2267.patch DefaultRequestExceptionHandler fails with ClassCastException when an instance of ExceptionHandlerAssistant is contributed to RequestExceptionHandler. This had been broken accidentally in commit cb3d4c853f47cccf9193c33cfd085d6ca27c8706 when implementing contributions of assistant classes that are autobuilt. Although DefaultRequestExceptionHandlerTest covers contributions of ExceptionHandlerAssistant instances, it didn't fail because of an oversight in the test. The patch resolves the bug (trivially) and improves existing tests in DefaultRequestExceptionHandlerTest which now fail without patching DefaultRequestExceptionHandler. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TAP5-2001) Race condition while loading javascript file via ajax
[ https://issues.apache.org/jira/browse/TAP5-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13455753#comment-13455753 ] Dragan Sahpaski commented on TAP5-2001: --- How did you find this? Is it with many progressive displays? Because we've been getting exceptions with many progressive displays on one page but haven't got the time to figure it out yet whats been causing them. Race condition while loading javascript file via ajax - Key: TAP5-2001 URL: https://issues.apache.org/jira/browse/TAP5-2001 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.5 Reporter: Denis Stepanov Two or more concurrent AJAX requests requires 'example.js' javascript to load: First request: Adds script tag with src 'example.js' ... waits script to load Second request: Finds script 'example.js', thinks its already loaded and continues to process request - causes error because script is not loaded yet -- 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-1729) Sometimes YUICompressor can fail with java.util.EmptyStackException
[ https://issues.apache.org/jira/browse/TAP5-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291660#comment-13291660 ] Dragan Sahpaski commented on TAP5-1729: --- Thanks that one worked just fine. Cheers Sometimes YUICompressor can fail with java.util.EmptyStackException --- Key: TAP5-1729 URL: https://issues.apache.org/jira/browse/TAP5-1729 Project: Tapestry 5 Issue Type: Bug Components: tapestry-yuicompressor Affects Versions: 5.3 Reporter: Howard M. Lewis Ship Priority: Blocker [ERROR] ioc.Registry java.util.EmptyStackException [ERROR] ioc.Registry Operations trace: [ERROR] ioc.Registry [ 1] Streaming asset stack en/core.js [ERROR] ioc.Registry [ 2] Minimizing JavaScript [ERROR] TapestryModule.RequestExceptionHandler Processing of request failed with uncaught exception: org.apache.tapestry5.ioc.internal.OperationException org.apache.tapestry5.ioc.internal.OperationException at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:121) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:88) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:47) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.run(PerThreadOperationTracker.java:76) at org.apache.tapestry5.ioc.internal.RegistryImpl.run(RegistryImpl.java:1109) at org.apache.tapestry5.internal.TapestryInternalUtils.performIO(TapestryInternalUtils.java:576) at org.apache.tapestry5.internal.yuicompressor.AbstractMinimizer.minimize(AbstractMinimizer.java:62) at org.apache.tapestry5.internal.services.assets.MasterResourceMinimizer.minimize(MasterResourceMinimizer.java:44) at $ResourceMinimizer_1250535a97d2196c.minimize(Unknown Source) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.assembleStackContent(StackAssetRequestHandler.java:175) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.assembleStackContent(StackAssetRequestHandler.java:163) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.getUncompressedResource(StackAssetRequestHandler.java:146) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.getResource(StackAssetRequestHandler.java:123) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.access$100(StackAssetRequestHandler.java:40) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler$1.perform(StackAssetRequestHandler.java:103) at org.apache.tapestry5.internal.TapestryInternalUtils$5.run(TapestryInternalUtils.java:582) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:51) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:48) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:47) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.run(PerThreadOperationTracker.java:76) at org.apache.tapestry5.ioc.internal.RegistryImpl.run(RegistryImpl.java:1109) at org.apache.tapestry5.internal.TapestryInternalUtils.performIO(TapestryInternalUtils.java:576) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.handleAssetRequest(StackAssetRequestHandler.java:96) at org.apache.tapestry5.internal.services.AssetDispatcher.dispatch(AssetDispatcher.java:109) at $Dispatcher_1250535a97d21963.dispatch(Unknown Source) at $Dispatcher_1250535a97d21967.dispatch(Unknown Source) at $Dispatcher_1250535a97d21961.dispatch(Unknown Source) at org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:302) at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26) at $RequestHandler_1250535a97d21962.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:902) at $RequestHandler_1250535a97d21962.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:892) at $RequestHandler_1250535a97d21962.service(Unknown Source) at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:90) at $RequestHandler_1250535a97d21962.service(Unknown Source) at
[jira] [Created] (TAP5-1663) The @BindParameter annotation should support inherited parameters
The @BindParameter annotation should support inherited parameters
-
Key: TAP5-1663
URL: https://issues.apache.org/jira/browse/TAP5-1663
Project: Tapestry 5
Issue Type: Improvement
Reporter: Dragan Sahpaski
Priority: Minor
Hi,
Currently the @BindParameter annotation (that binds a parameter of a mixin to a
parameter in the component the mixin is applied to),
can be applied only to formal parameters of the containing component and not to
parameters that are inherited by the containing component by embedded
components.
I think it is natural that inherited parameters are included in the search for
parameters to bind to with the @BindParameter annotation.
Here is a motivating example:
public class MyComponent{
@Component(parameters = blankOption=inherit:blankOption,
publishParameters=blankOption)
private Select select;
}
public class MyMixin{
@BindParameter
private BlankOption blankOption;
}
And we get:
org.apache.tapestry5.ioc.util.UnknownValueException
Containing component MyComponent does not contain a formal parameter matching
any of (blank), blankOption.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1606) EmbeddedMixin concept
EmbeddedMixin concept
-
Key: TAP5-1606
URL: https://issues.apache.org/jira/browse/TAP5-1606
Project: Tapestry 5
Issue Type: New Feature
Components: tapestry-core
Affects Versions: 5.3
Reporter: Dragan Sahpaski
Priority: Minor
The EmbeddedMixin concept allows applying mixins on embedded components of an
existing component.
Usage scenario:
A mixin can have embedded mixins defined with the new @EmbeddedMixin annotation.
A motivational demo can be found here
http://dragansah.com/demoapp/embeddedmixinexamples
Usage example:
t:grid t:mixins=mixinForGrid /
public class MixinForGrid
{
// apply the MixinForGridCell mixin to the rows.gridCell subcomponent
of the grid
@EmbeddedMixin(componentId=rows.gridCell)
private MixinForGridCell mixinForGridcell;
// render phases on the grid
void beginRender()
{
}
}
public class MixinForGridCell
{
// render phase on gridCell
void beginRender()
{
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1606) EmbeddedMixin concept
[
https://issues.apache.org/jira/browse/TAP5-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dragan Sahpaski updated TAP5-1606:
--
Attachment: EmbeddedMixin patch.diff
A patch implementing the EmbeddedMixin concept
EmbeddedMixin concept
-
Key: TAP5-1606
URL: https://issues.apache.org/jira/browse/TAP5-1606
Project: Tapestry 5
Issue Type: New Feature
Components: tapestry-core
Affects Versions: 5.3
Reporter: Dragan Sahpaski
Priority: Minor
Labels: mixin
Attachments: EmbeddedMixin patch.diff
The EmbeddedMixin concept allows applying mixins on embedded components of an
existing component.
Usage scenario:
A mixin can have embedded mixins defined with the new @EmbeddedMixin
annotation.
A motivational demo can be found here
http://dragansah.com/demoapp/embeddedmixinexamples
Usage example:
t:grid t:mixins=mixinForGrid /
public class MixinForGrid
{
// apply the MixinForGridCell mixin to the rows.gridCell subcomponent
of the grid
@EmbeddedMixin(componentId=rows.gridCell)
private MixinForGridCell mixinForGridcell;
// render phases on the grid
void beginRender()
{
}
}
public class MixinForGridCell
{
// render phase on gridCell
void beginRender()
{
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1607) Context menu mixin
Context menu mixin -- Key: TAP5-1607 URL: https://issues.apache.org/jira/browse/TAP5-1607 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.3 Reporter: Dragan Sahpaski Priority: Minor Issue for the work done on Google Summer of Code 2011 http://www.google-melange.com/gsoc/project/google/gsoc2011/dragansah/5001 Implements a context menu mixin which is dependent on the EmbeddedMixin concept. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1607) Context menu mixin
[ https://issues.apache.org/jira/browse/TAP5-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Sahpaski updated TAP5-1607: -- Description: Issue for the work done on Google Summer of Code 2011 http://www.google-melange.com/gsoc/project/google/gsoc2011/dragansah/5001 Implements a context menu mixin which is dependent on the EmbeddedMixin concept. A demo of the implementation of the context menu can be seen here: http://dragansah.com/demoapp/ was: Issue for the work done on Google Summer of Code 2011 http://www.google-melange.com/gsoc/project/google/gsoc2011/dragansah/5001 Implements a context menu mixin which is dependent on the EmbeddedMixin concept. Context menu mixin -- Key: TAP5-1607 URL: https://issues.apache.org/jira/browse/TAP5-1607 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.3 Reporter: Dragan Sahpaski Priority: Minor Labels: mixin Attachments: ContextMenu patch.diff Issue for the work done on Google Summer of Code 2011 http://www.google-melange.com/gsoc/project/google/gsoc2011/dragansah/5001 Implements a context menu mixin which is dependent on the EmbeddedMixin concept. A demo of the implementation of the context menu can be seen here: http://dragansah.com/demoapp/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1607) Context menu mixin
[ https://issues.apache.org/jira/browse/TAP5-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Sahpaski updated TAP5-1607: -- Attachment: ContextMenu patch.diff Context menu mixin -- Key: TAP5-1607 URL: https://issues.apache.org/jira/browse/TAP5-1607 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.3 Reporter: Dragan Sahpaski Priority: Minor Labels: mixin Attachments: ContextMenu patch.diff Issue for the work done on Google Summer of Code 2011 http://www.google-melange.com/gsoc/project/google/gsoc2011/dragansah/5001 Implements a context menu mixin which is dependent on the EmbeddedMixin concept. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1595) Provide support for Macedonian locale
[ https://issues.apache.org/jira/browse/TAP5-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Sahpaski updated TAP5-1595: -- Attachment: language-patch-macedonian.patch Provide support for Macedonian locale - Key: TAP5-1595 URL: https://issues.apache.org/jira/browse/TAP5-1595 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.2.5 Reporter: Dragan Sahpaski Priority: Minor Attachments: language-patch-macedonian.patch Please see here: http://tapestry.apache.org/community.html#Community-ContributingtranslationsforTapestrybuiltinmessages -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1595) Provide support for Macedonian locale
Provide support for Macedonian locale - Key: TAP5-1595 URL: https://issues.apache.org/jira/browse/TAP5-1595 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.2.5 Reporter: Dragan Sahpaski Priority: Minor Attachments: language-patch-macedonian.patch Please see here: http://tapestry.apache.org/community.html#Community-ContributingtranslationsforTapestrybuiltinmessages -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1595) Provide support for Macedonian locale
[ https://issues.apache.org/jira/browse/TAP5-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Sahpaski updated TAP5-1595: -- Attachment: language-patch-macedonian.patch Provide support for Macedonian locale - Key: TAP5-1595 URL: https://issues.apache.org/jira/browse/TAP5-1595 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.2.5 Reporter: Dragan Sahpaski Priority: Minor Attachments: language-patch-macedonian.patch Please see here: http://tapestry.apache.org/community.html#Community-ContributingtranslationsforTapestrybuiltinmessages -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1595) Provide support for Macedonian locale
[ https://issues.apache.org/jira/browse/TAP5-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Sahpaski updated TAP5-1595: -- Attachment: (was: language-patch-macedonian.patch) Provide support for Macedonian locale - Key: TAP5-1595 URL: https://issues.apache.org/jira/browse/TAP5-1595 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.2.5 Reporter: Dragan Sahpaski Priority: Minor Attachments: language-patch-macedonian.patch Please see here: http://tapestry.apache.org/community.html#Community-ContributingtranslationsforTapestrybuiltinmessages -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
