[jira] Commented: (TAP5-103) provide access to component parameters from within mixins
[ https://issues.apache.org/jira/browse/TAP5-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12726411#action_12726411 ] Alfie Kirkpatrick commented on TAP5-103: I have voted for this issue because I also think Howard's idea of somehow linking parameters together would be really elegant if achievable. But isn't there a simple workaround where we just duplicate the parameter between the mixin and the container? I have a zone parameter on my overlay mixin so if I mix it with another component that also has a zone parameter I need: t:actionlink zone=zone1 overlay.zone=zone1.../t:actionlink In my case it is a literal but if it was a property binding, wouldn't changes to the property be propogated between the component and the mixin? provide access to component parameters from within mixins - Key: TAP5-103 URL: https://issues.apache.org/jira/browse/TAP5-103 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Reporter: Kristian Marinkovic A mixin can't access the parameters of a component because the Bindings property of the InternalComponentResourcesImpl class is private and the respective interface does not provide a access method. I was trying to create a mixin that would render only the value of a form element (without the tags) when it was in a certain state. There also might be use cases where mixins are used to collect data from the components they are attached and therefore also needs access to the components parameters. see threads: http://www.nabble.com/Antwort%3A--T5--how-to-read-the-value-of-a-component-parameter-within-a-mixin-tf4487995.html http://www.nabble.com/-T5--how-to-read-the-value-of-a-component-parameter-within-a-mixin-tf4487597.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-763) Documentation for RenderSupport.addScriptLink() is invalid about where the included links go
Documentation for RenderSupport.addScriptLink() is invalid about where the included links go Key: TAP5-763 URL: https://issues.apache.org/jira/browse/TAP5-763 Project: Tapestry 5 Issue Type: Bug Components: documentation, tapestry-core Affects Versions: 5.1.0.5 Reporter: Howard M. Lewis Ship Priority: Minor It could also mention JavaScript aggregation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-745) Remove Woodstox-specific Stax implementation usage
[ https://issues.apache.org/jira/browse/TAP5-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Zeigler closed TAP5-745. --- Resolution: Won't Fix Remove Woodstox-specific Stax implementation usage -- Key: TAP5-745 URL: https://issues.apache.org/jira/browse/TAP5-745 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.1 Reporter: Christian Köberl Assignee: Robert Zeigler Priority: Critical Attachments: TAP5-745-5.1.0.5.patch Tapestry uses some special extensions to StaX (out of Woodstox) in the template parser. This leads to the problem that Tapestry will usually not run on any application server because the appservers will use their own implementation of Stax. There is a workaround but a main stream web application framework should run on JEE compatible web and application servers without tweaking. The main problem is in org.apache.tapestry5.internal.services.TemplateParserImpl.init(TemplateParserImpl.java:44). Here, XMLInputFactory2 is asked for an instance - but XMLInputFactory2 does not implement the method newInstance. This is delegated to XMLInputFactory. So, the original XMLInputFactory is used - which returns the platform implementation of Stax. Workaround: Add the system property below to Application Server (either via startup script or admin console): -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-745) Remove Woodstox-specific Stax implementation usage
[ https://issues.apache.org/jira/browse/TAP5-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12726792#action_12726792 ] Robert Zeigler commented on TAP5-745: - Complicated. :) http://jira.codehaus.org/browse/WSTX-78 (closed) talks about the spec saying that getText() on the dtd element returns the internal subset of the DTD (which is true in java 1.6 docs; 1.5 docs (via webservices) says simply: String value of the DTD). Basically, what this means is that there is no implementation-independent manner of dealing with dtd's right now. Incidentally, the maintenance release of the stax jsr mentioned in WSTX-78 has been withdrawn. There's a pending maintenance release now, but, it doesn't touch dtd's. I've now tried running the full tapestry-core test suite with the patch with: a) woodstox as the underlying parser b) stax:stax:1.2.0 as the underlying parser c) recompiling with java 1.6 and using the built-in parser a: fails due to getText() returning the empty string for the DTD b: likewise fails, but additionally fails due to not supporting external entities c: worst of all. Can't handle namespace prefixes; at least, it ignores them as the code is now (plus it would make tapestry require java 1.6, which is a nogo; this was more for my curiosity than anything else). At this point, it appears that there is no good way to deal with DTD's via the standard stax API, but properly dealing with DTD's is critically important since client interpretation of css depends on the doctype used. Thus, I'm closing this issue as won't fix and woodstox-independence will have to wait until either: 1) TAP5-713 is resolved or 2) A user who cares about woodstox independence is willing to step up and provide a patch that actually works (please: be sure to run all of the tapestry-core tests, at least, and make sure they pass before submitting! And be sure to test with java 1.5!) Remove Woodstox-specific Stax implementation usage -- Key: TAP5-745 URL: https://issues.apache.org/jira/browse/TAP5-745 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.1 Reporter: Christian Köberl Assignee: Robert Zeigler Priority: Critical Attachments: TAP5-745-5.1.0.5.patch Tapestry uses some special extensions to StaX (out of Woodstox) in the template parser. This leads to the problem that Tapestry will usually not run on any application server because the appservers will use their own implementation of Stax. There is a workaround but a main stream web application framework should run on JEE compatible web and application servers without tweaking. The main problem is in org.apache.tapestry5.internal.services.TemplateParserImpl.init(TemplateParserImpl.java:44). Here, XMLInputFactory2 is asked for an instance - but XMLInputFactory2 does not implement the method newInstance. This is delegated to XMLInputFactory. So, the original XMLInputFactory is used - which returns the platform implementation of Stax. Workaround: Add the system property below to Application Server (either via startup script or admin console): -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-745) Remove Woodstox-specific Stax implementation usage
[ https://issues.apache.org/jira/browse/TAP5-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12726795#action_12726795 ] Christian E Gruber commented on TAP5-745: - I'll be giving it a shot. Christian. Christian Edward Gruber christianedwardgru...@gmail.com http://www.geekinasuit.com/ Remove Woodstox-specific Stax implementation usage -- Key: TAP5-745 URL: https://issues.apache.org/jira/browse/TAP5-745 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.1 Reporter: Christian Köberl Assignee: Robert Zeigler Priority: Critical Attachments: TAP5-745-5.1.0.5.patch Tapestry uses some special extensions to StaX (out of Woodstox) in the template parser. This leads to the problem that Tapestry will usually not run on any application server because the appservers will use their own implementation of Stax. There is a workaround but a main stream web application framework should run on JEE compatible web and application servers without tweaking. The main problem is in org.apache.tapestry5.internal.services.TemplateParserImpl.init(TemplateParserImpl.java:44). Here, XMLInputFactory2 is asked for an instance - but XMLInputFactory2 does not implement the method newInstance. This is delegated to XMLInputFactory. So, the original XMLInputFactory is used - which returns the platform implementation of Stax. Workaround: Add the system property below to Application Server (either via startup script or admin console): -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
