[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ https://issues.apache.org/jira/browse/COCOON-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570496#action_12570496 ] Olivier Billard commented on COCOON-1898: - Hi there, This issue is quite old, and I also have the need of patching cocoon.xconf file in a mavenized Cocoon 2.1.x application. I have several jar artefacts corresponding to different possible configurations (a base core, and customers-oriented/specific functionalities). Is there any chance this would be managed ? Thanks ! [PATCH] XPatch support for maven-cocoon-deployer-plugin --- Key: COCOON-1898 URL: https://issues.apache.org/jira/browse/COCOON-1898 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: maven-cocoon-deployer-plugin-with-xpatch-support.patch The cocoon-deployer-plugin has currently no support for XPatch, which makes it difficult to modify the web.xml when developing cocoon blocks. For example the cocoon-xmldb-impl block should add, when deployed, a servlet for xindice and a servlet mapping for the xindice servlet. This was possible in 2.1 using the XConfToolTask, but is no longer possible with the current state of the deployer-plugin. My patch adds support for patching the web.xml file using *.xweb files in the /conf directory of a block by filtering the block's jar file during deployment for conf/*.xweb files, caching the patch document temporarily and applying them (using code from the orgiginal XConfToolTask in 2.1) to the web.xml. The patch has currently no support for other files than conf/*.xweb files and does not support any property expansion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
PipelineEvents eat children
Classes extending SimpleParentProcessingNode decide which children to process and call invoke() on those children. Classes extending PipelineEventComponentProcessingNode assume all children are configuration for the parent node. Any children not understood by the component are ignored. Compare these examples: map:select map:when test=first map:transform map:parameter name=choice value=first/ /map:transform /map:when map:otherwise map:transform map:parameter name=choice value=other/ /map:transform /map:otherwise /map:select And: map:transform map:select map:when test=first map:parameter name=choice value=first/ /map:when map:otherwise map:parameter name=choice value=other/ /map:otherwise /map:select /map:transform The first example works because no ParentProcessingNodes are children of a PipelineEvent. The second transform will have the parameter choice default to the empty string because the map:select element was ignored. Differentiating the elements may make sense to Cocoon devs, but is not obvious to Cocoon users. The second example is obviously better code: shorter with decision-making closer to the effect. The differentiation only exists due to Cocoon storing the PipelineEvents for the second phase of processing. Workarounds are possible after a user learns about the limitations of certain elements -- difficult since these limitations are not mentioned on the Cocoon website. The workarounds can become very messy. Imagine three Selectors each need to set parameters for one transform. Much code would be duplicated or an extra pipeline added for each Selector. Both methods reduce maintainability, and the latter adds processing. The obvious solution is for the PipelineEvent nodes to test each child with isInvocable() [or isComponent() or isProcessingNode()?] and call child.invoke() where appropriate. This is feasible as only three PipelineEvent classes exist: GenerateNode, TransformNode, and SerializeNode. Another (better?) solution would test child nodes before passing control to the PipelineEvent nodes. This affects Cocoon-2.1 through Cocoon-2.1.11. Has this been fixed in Cocoon-2.2? Thoughts? solprovider
[jira] Assigned: (COCOON-2020) CAPTCHA input element should have autocomplete=off
[
https://issues.apache.org/jira/browse/COCOON-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo reassigned COCOON-2020:
Assignee: Antonio Gallardo
CAPTCHA input element should have autocomplete=off
---
Key: COCOON-2020
URL: https://issues.apache.org/jira/browse/COCOON-2020
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.2-dev
(Current SVN)
Reporter: Mark Lundquist
Assignee: Antonio Gallardo
Priority: Trivial
The bug summary says it all, and this isn't even enough to bother making a
patch, all it takes is the following lines added to forms-field-styling.xsl
(the diff is from my 2.1.8 vendor branch, but this fix will work in all
Cocoon versions):
forms-field-styling.xsl(working copy)
@@ -55,6 +55,9 @@
/xsl:if
!-- @id:input is what labels point to --
input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED]:input
value={fi:value} title={fi:hint} type=text
+xsl:if test=fi:captcha-image
+ xsl:attribute name=autocomplete select='off'/
+/xsl:if
xsl:apply-templates select=. mode=styling/
/input
xsl:apply-templates select=. mode=common/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2020) CAPTCHA input element should have autocomplete=off
[
https://issues.apache.org/jira/browse/COCOON-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo closed COCOON-2020.
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
2.1.12-dev (Current SVN)
Thanks for the patch. :)
CAPTCHA input element should have autocomplete=off
---
Key: COCOON-2020
URL: https://issues.apache.org/jira/browse/COCOON-2020
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.2-dev
(Current SVN)
Reporter: Mark Lundquist
Assignee: Antonio Gallardo
Priority: Trivial
Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN)
The bug summary says it all, and this isn't even enough to bother making a
patch, all it takes is the following lines added to forms-field-styling.xsl
(the diff is from my 2.1.8 vendor branch, but this fix will work in all
Cocoon versions):
forms-field-styling.xsl(working copy)
@@ -55,6 +55,9 @@
/xsl:if
!-- @id:input is what labels point to --
input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED]:input
value={fi:value} title={fi:hint} type=text
+xsl:if test=fi:captcha-image
+ xsl:attribute name=autocomplete select='off'/
+/xsl:if
xsl:apply-templates select=. mode=styling/
/input
xsl:apply-templates select=. mode=common/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
