Re: Rename cocoon:rcl to cocoon:wrap-block
On Feb 16, 2008, at 11:44 AM, Torsten Curdt wrote: On 16.02.2008, at 17:12, Reinhard Poetz wrote: After having seen quite a few people wonder what 'cocoon:rcl' means, I propose to change it to some better name. The general idea is that this Maven goal creates a web application which wraps the block and makes it runable as a 'normal' web application in a web container. Additionally it enables the usage of the reloading classloader (commons-jci) which made me name it 'cocoon:rcl'. I propose to use 'cocoon:wrap-block' instead. Though it's longer I think it's closer to the actual meaning and hence less confusing. If we want to keep the name short, we could even add a shortcut 'cocoon:wb'. wrap-block ??? Hm ...I cannot really see how that is much better - sorry ;) What about cocoon:webapp-loader cocoon:reloader (shorter), or cocoon:webapp-reloader (more descriptive) Vadim
Re: Rename cocoon:rcl to cocoon:wrap-block
On Wed, 2008-02-20 at 08:16 -0500, Vadim Gritsenko wrote: On Feb 16, 2008, at 11:44 AM, Torsten Curdt wrote: On 16.02.2008, at 17:12, Reinhard Poetz wrote: After having seen quite a few people wonder what 'cocoon:rcl' means, I propose to change it to some better name. The general idea is that this Maven goal creates a web application which wraps the block and makes it runable as a 'normal' web application in a web container. Additionally it enables the usage of the reloading classloader (commons-jci) which made me name it 'cocoon:rcl'. I propose to use 'cocoon:wrap-block' instead. Though it's longer I think it's closer to the actual meaning and hence less confusing. If we want to keep the name short, we could even add a shortcut 'cocoon:wb'. wrap-block ??? Hm ...I cannot really see how that is much better - sorry ;) What about cocoon:webapp-loader cocoon:reloader (shorter), or cocoon:webapp-reloader (more descriptive) cocoon:loader salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: svn commit: r628365 - in /cocoon/trunk/tools/release-builder: ./ build.xml
On Feb 16, 2008, at 12:36 PM, [EMAIL PROTECTED] wrote: start with an Ant script that creates the distribution artifacts for Non-Maven Cocoon releases Just wondering - why not assembly plugin? Do you want to create a binary distribution from a Maven project that includes supporting scripts, configuration files, and all runtime dependencies? You need to use the Assembly Plugin to create a distribution for your project. Vadim
Re: Rename cocoon:rcl to cocoon:wrap-block
Reinhard Poetz schrieb: After having seen quite a few people wonder what 'cocoon:rcl' means, I propose to change it to some better name. The general idea is that this Maven goal creates a web application which wraps the block and makes it runable as a 'normal' web application in a web container. Additionally it enables the usage of the reloading classloader (commons-jci) which made me name it 'cocoon:rcl'. I propose to use 'cocoon:wrap-block' instead. Though it's longer I think it's closer to the actual meaning and hence less confusing. If we want to keep the name short, we could even add a shortcut 'cocoon:wb'. WDOT? Other proposals? cocoon:run My 2 cents Felix
Re: svn commit: r628365 - in /cocoon/trunk/tools/release-builder: ./ build.xml
Vadim Gritsenko wrote:
On Feb 16, 2008, at 12:36 PM, [EMAIL PROTECTED] wrote:
start with an Ant script that creates the distribution artifacts for
Non-Maven Cocoon releases
Just wondering - why not assembly plugin?
I failed to get it working the way I want it. Since I do not want to invest
endless engery, I switched to Ant.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Rename cocoon:rcl to cocoon:wrap-block
Felix Knecht wrote:
Reinhard Poetz schrieb:
After having seen quite a few people wonder what 'cocoon:rcl' means, I
propose to change it to some better name.
The general idea is that this Maven goal creates a web application
which wraps the block and makes it runable as a 'normal' web
application in a web container. Additionally it enables the usage of
the reloading classloader (commons-jci) which made me name it
'cocoon:rcl'.
I propose to use 'cocoon:wrap-block' instead. Though it's longer I
think it's closer to the actual meaning and hence less confusing. If
we want to keep the name short, we could even add a shortcut 'cocoon:wb'.
WDOT? Other proposals?
cocoon:run
Actually it doesn't run the block but only creates the environment (i.e. a web
application that wraps a block) for it.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Rename cocoon:rcl to cocoon:wrap-block
Thorsten Scherler wrote:
cocoon:loader
For me the best suggestion so far. But what do native speaker feel when they
read/enter this? Does it sound natural?
Think that you usually enter
mvn cocoon:loader jetty:run
when you want to run a block.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Rename cocoon:rcl to cocoon:wrap-block
Vadim Gritsenko wrote:
On Feb 16, 2008, at 11:44 AM, Torsten Curdt wrote:
What about cocoon:webapp-loader
cocoon:reloader (shorter), or cocoon:webapp-reloader (more descriptive)
That this goal supports the usage of a reloading classloader is just a feature
but (at least in trunk) configureable. Hence I'm not that enthusiastic about
loader or reloader.
... or am I too picky?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Rename cocoon:rcl to cocoon:wrap-block
On 20.02.2008, at 15:50, Reinhard Poetz wrote: Vadim Gritsenko wrote: On Feb 16, 2008, at 11:44 AM, Torsten Curdt wrote: What about cocoon:webapp-loader cocoon:reloader (shorter), or cocoon:webapp-reloader (more descriptive) That this goal supports the usage of a reloading classloader is just a feature but (at least in trunk) configureable. Hence I'm not that enthusiastic about loader or reloader. ... or am I too picky? No ...I was thinking the same :) ...which is why I would think 'cocoon:loader' (not reloader) would be OK. On the other hand this looks quite consistent: mvn cocoon:run jetty:run It might be technically not really correct but looks nice and straight forward. Think users might like that. cheers -- Torsten
Re: Rename cocoon:rcl to cocoon:wrap-block
Reinhard Poetz wrote: Felix Knecht wrote: Reinhard Poetz schrieb: After having seen quite a few people wonder what 'cocoon:rcl' means, I propose to change it to some better name. The general idea is that this Maven goal creates a web application which wraps the block and makes it runable as a 'normal' web application in a web container. Additionally it enables the usage of the reloading classloader (commons-jci) which made me name it 'cocoon:rcl'. I propose to use 'cocoon:wrap-block' instead. Though it's longer I think it's closer to the actual meaning and hence less confusing. If we want to keep the name short, we could even add a shortcut 'cocoon:wb'. WDOT? Other proposals? cocoon:run Actually it doesn't run the block but only creates the environment (i.e. a web application that wraps a block) for it. cocoon:package cocoon:assemble (Though package has a specific connotation in the Maven world of creating a jar/war/etc. ... does this goal do that as well?)
Re: Rename cocoon:rcl to cocoon:wrap-block
Then cocoon:prepare or (more verbose) cocoon:prepare-run does sound appropriate Jason Johnston schrieb: Reinhard Poetz wrote: Felix Knecht wrote: Reinhard Poetz schrieb: After having seen quite a few people wonder what 'cocoon:rcl' means, I propose to change it to some better name. The general idea is that this Maven goal creates a web application which wraps the block and makes it runable as a 'normal' web application in a web container. Additionally it enables the usage of the reloading classloader (commons-jci) which made me name it 'cocoon:rcl'. I propose to use 'cocoon:wrap-block' instead. Though it's longer I think it's closer to the actual meaning and hence less confusing. If we want to keep the name short, we could even add a shortcut 'cocoon:wb'. WDOT? Other proposals? cocoon:run Actually it doesn't run the block but only creates the environment (i.e. a web application that wraps a block) for it. cocoon:package cocoon:assemble (Though package has a specific connotation in the Maven world of creating a jar/war/etc. ... does this goal do that as well?)
Re: Rename cocoon:rcl to cocoon:wrap-block
On Wed, 2008-02-20 at 16:19 +0100, Torsten Curdt wrote: On 20.02.2008, at 15:50, Reinhard Poetz wrote: Vadim Gritsenko wrote: On Feb 16, 2008, at 11:44 AM, Torsten Curdt wrote: What about cocoon:webapp-loader cocoon:reloader (shorter), or cocoon:webapp-reloader (more descriptive) That this goal supports the usage of a reloading classloader is just a feature but (at least in trunk) configureable. Hence I'm not that enthusiastic about loader or reloader. ... or am I too picky? No ...I was thinking the same :) ...which is why I would think 'cocoon:loader' (not reloader) would be OK. Maybe even shorter and c-64 style: ;) mvn cocoon:load jetty:run salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
[jira] Updated: (COCOON-1529) I18nTranformer should consume and stop propagating start/endPrefixMapping of its namespace
[ https://issues.apache.org/jira/browse/COCOON-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johannes Textor updated COCOON-1529: Attachment: I18nTransformer.java.diff IMHO, there is no reason that i18n transformer should propagate its namespace, since it consumes all elements in that namespace. The remaining xmlns attribute is annoying if one serializes to XHTML, since the result is not valid. It is of course possible to fix this problem by adding an additional transformation step to each pipeline to drop the namespaces, but that costs performance and messes up the sitemap code. I looked into Joerg's AbstractSAXTransformer but I think that I18nTransformer should not be refactored to inherit from it; AbstractSAXTransformer is based on the assumption that the transformer will only use elements within a given namespace, but I18nTransformer also translates *attributes* on elements which might be in a different namespace (via i18n:attr). OTOH, AbstractSAXTransformer does a lot of things such as keeping track of all namespaces and calling extra hook methods which are not needed by I18nTransformer and would just slow it down. Attached is a simple patch (against I18nTransformer.java as of 20 Feb. 2008) which achieves the desired effect by simply dropping all prefix mappings which are in one of the i18n namespaces. WDYT? I18nTranformer should consume and stop propagating start/endPrefixMapping of its namespace -- Key: COCOON-1529 URL: https://issues.apache.org/jira/browse/COCOON-1529 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.1.8, 2.1.9, 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Juan Jose Pablos Priority: Minor Attachments: I18nTransformer.java.diff This is a strage bug. on http://localhost:/samples/i18n/simple.xml around line 183: annotation xmlns:i18n=http://apache.org/cocoon/i18n/2.1; This produces wrong xml output (extra xmlns:i18n attribute). now if you commented out the annotation element then the xmlns:i18n attribute goes to the next element: content xmlns:i18n=http://apache.org/cocoon/i18n/2.1; It looks like it goes to the parent element always. I wish that I could have more information about how to resolve this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Rename cocoon:rcl to cocoon:wrap-block
Thorsten Scherler wrote:
Maybe even shorter and c-64 style: ;)
mvn cocoon:load jetty:run
after reading all the mails again, here are my two favorits:
mvn cocoon:load jetty:run
mvn cocoon:prepare jetty:run
WDOT?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Rename cocoon:rcl to cocoon:wrap-block
Reinhard Poetz pisze: Thorsten Scherler wrote: Maybe even shorter and c-64 style: ;) mvn cocoon:load jetty:run after reading all the mails again, here are my two favorits: mvn cocoon:load jetty:run mvn cocoon:prepare jetty:run WDOT? +1 for cocoon:prepare provided it helps people... Grzegorz
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (106 issues) Subscriber: cocoon Key Summary COCOON-2168 ResourceReader produces Java Heap Overflow when reading a huge resource https://issues.apache.org/jira/browse/COCOON-2168 COCOON-2162 [PATCH] Fix for Paginator when accessing out of bounds Pagination page https://issues.apache.org/jira/browse/COCOON-2162 COCOON-2137 XSD Schemas for CForms Development https://issues.apache.org/jira/browse/COCOON-2137 COCOON-2114 fix sorting in TraversableGenerator https://issues.apache.org/jira/browse/COCOON-2114 COCOON-2109 Incorrent cleanup of expired continuations https://issues.apache.org/jira/browse/COCOON-2109 COCOON-2108 xmodule:flow-attr Does not accept document objects https://issues.apache.org/jira/browse/COCOON-2108 COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer https://issues.apache.org/jira/browse/COCOON-2104 COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow https://issues.apache.org/jira/browse/COCOON-2100 COCOON-2071 Option to turn off pooling for components (probably faster on new JVMs and simpler debugging) https://issues.apache.org/jira/browse/COCOON-2071 COCOON-2063 NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8 https://issues.apache.org/jira/browse/COCOON-2063 COCOON-2041 WebDAV Returns improper status on PUT https://issues.apache.org/jira/browse/COCOON-2041 COCOON-2040 Union widget does not work with booleanfield set as case widget https://issues.apache.org/jira/browse/COCOON-2040 COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type=checkbox https://issues.apache.org/jira/browse/COCOON-2030 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1985 AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline https://issues.apache.org/jira/browse/COCOON-1985 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the blocks protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for generator/reader already set should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early https://issues.apache.org/jira/browse/COCOON-1943 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice https://issues.apache.org/jira/browse/COCOON-1899 COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin https://issues.apache.org/jira/browse/COCOON-1898 COCOON-1893 XML-Binding: Problem creating a new element
[jira] Commented: (COCOON-1529) I18nTranformer should consume and stop propagating start/endPrefixMapping of its namespace
[ https://issues.apache.org/jira/browse/COCOON-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570795#action_12570795 ] solprovider commented on COCOON-1529: - The i18n transformer requires users to add the transform to each pipeline. In my experience, the i18n transformer is always called just before a Serializer. Resolving i18n tags should happen in two situations: 1) Translation during serialization before leaving an XMAP. Unresolved i18n elements must remain for later processing. 2) Translation before presenting the information. Unresolved i18n elements should translate to the default and be removed. The i18n namespace should be removed. The first case can be integrated into the XMLSerializer. The second case can be integrated into final Serializers such as the HTMLSerializer. Since the XMLSerializer can be used in both situations, an i18n-finalize parameter can decide if the defaults should be used and the i18n namespace be removed. An i18n-ignore parameter could be used for when performance matters and the i18n functionality is not useful, but new users would benefit from the reduced code of the default functionality. Each Serializer can have i18n-catalog parameters. These catalog parameter could be made unnecessary by having a default catalog name related to the sitemap, e.g. sitemap.xmap defaults to using sitemap_i18n_xx.xml and sitemap_i18n.xml from the same directory. Some people may argue against mixing Transformer functionality into Serializers. Serialization is a transformation possibly resulting in a non-XML data format. I18n functionality is ubiquitous and a major benefit of Cocoon. Integrating i18n into Serializers removes the need for building a comprehensive catalog for use in the final step before the final transformation/serialization; each XMAP handles its unique i18n translations and leaves unknown translations for later processing. This suggestion does not expect the removal of the i18nTransformer. Allowing the i18nTransformer to be called without serialization may prove useful and is necessary for backwards-compatibility. As a non-integrated Transformer, the i18nTransformer should distinguish between interim transforms that translate only elements from the current catalogs and final transforms that resolve every i18n element/attribute and remove the i18n namespace. I18nTranformer should consume and stop propagating start/endPrefixMapping of its namespace -- Key: COCOON-1529 URL: https://issues.apache.org/jira/browse/COCOON-1529 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.1.8, 2.1.9, 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Juan Jose Pablos Priority: Minor Attachments: I18nTransformer.java.diff This is a strage bug. on http://localhost:/samples/i18n/simple.xml around line 183: annotation xmlns:i18n=http://apache.org/cocoon/i18n/2.1; This produces wrong xml output (extra xmlns:i18n attribute). now if you commented out the annotation element then the xmlns:i18n attribute goes to the next element: content xmlns:i18n=http://apache.org/cocoon/i18n/2.1; It looks like it goes to the parent element always. I wish that I could have more information about how to resolve this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Rename cocoon:rcl to cocoon:wrap-block
On 20.02.2008 12:47, Reinhard Poetz wrote: mvn cocoon:load jetty:run after reading all the mails again, here are my two favorits: mvn cocoon:load jetty:run mvn cocoon:prepare jetty:run Considering your explanation [1] I slightly prefer cocoon:prepare. Joerg [1] http://marc.info/?l=xml-cocoon-devm=120351863516460w=4
Re: PipelineEvents eat children
On 19.02.2008 21:17, [EMAIL PROTECTED] wrote:
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
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.
Solprovider and I already discussed this on the users mailing list [1] -
though it seems he does not agree to my reasoning. My main point against
this functionality is a conceptional difference: Example 1 is about
selecting pipeline components while example 2 is about configuration.
IMO it should not be possible to conditionally inject different sets of
parameters.
The original requirement Solprovider had was to inject a different
parameter *value* based on the outcome of the resource exists
selector. My argument was that the correct approach of dynamically
evaluating a parameter value is an input module - even though he can't
reuse the existing resource exists selector in that case. Using an
input module would be without any repeating code in the sitemap:
map:transform
map:parameter name=choice value={exists:whatever}/
/map:transform
Additionally the input module would be reusable while the code in the
sitemap would be that bloated whenever this functionality is needed. So
even for maintenance reasons this approach seems to be preferable.
Also compared with Spring we are consistent. Spring does not provide any
conditionals in their configuration files. Instead they provide dynamic
evaluation of property placeholders though - just like our input modules.
That's why I'm strongly against adding this functionality to the
sitemap.
(I have held back this mail (for nearly 24 hours) so that others could
form their own view. But it seems not too many people are interested ...)
Joerg
[1] http://marc.info/?t=12030050381r=1w=4
Re: PipelineEvents eat children
On Wed, Feb 20, 2008 at 7:40 PM, Joerg Heinicke [EMAIL PROTECTED] wrote:
On 19.02.2008 21:17, [EMAIL PROTECTED] wrote:
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
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.
Solprovider and I already discussed this on the users mailing list [1] -
though it seems he does not agree to my reasoning. My main point against
this functionality is a conceptional difference: Example 1 is about
selecting pipeline components while example 2 is about configuration.
IMO it should not be possible to conditionally inject different sets of
parameters.
The original requirement Solprovider had was to inject a different
parameter *value* based on the outcome of the resource exists
selector. My argument was that the correct approach of dynamically
evaluating a parameter value is an input module - even though he can't
reuse the existing resource exists selector in that case. Using an
input module would be without any repeating code in the sitemap:
map:transform
map:parameter name=choice value={exists:whatever}/
/map:transform
Additionally the input module would be reusable while the code in the
sitemap would be that bloated whenever this functionality is needed. So
even for maintenance reasons this approach seems to be preferable.
Also compared with Spring we are consistent. Spring does not provide any
conditionals in their configuration files. Instead they provide dynamic
evaluation of property placeholders though - just like our input modules.
That's why I'm strongly against adding this functionality to the
sitemap.
(I have held back this mail (for nearly 24 hours) so that others could
form their own view. But it seems not too many people are interested ...)
Joerg
[1] http://marc.info/?t=12030050381r=1w=4
Writing a reusable InputModule that can handle:
if(resource1.exists()){ return parameter1;}
else if(resource2.exists()){return parameter2;}
else if(resource3.exists()){return parameter3; }
...
else return finalparameter;
is possible. The line in the XMAP would be (assuming only 3 files are checked):
transform
map:parameter name=name
value={exists:file://path/file1.xml,file1returnValue,file://path/file2.xml,file2returnValue,file://path3/file3.xml,file3returnValue,defaultValue}/
/transform
I can write the InputModule in a few minutes and solve my immediate
concern. Maintenance would be a nightmare.
This solution cannot use other Selectors.
This solution cannot set several parameters without reprocessing the
entire list.
This solution cannot handle setting a parameter based on multiple
conditions: if(file1.exists() and file2.exists()) return both;
This solution does not allow every Matcher and Selector to be used to
set parameters for every Generator, Transformer, and Serializer that
allows parameters.
Many new possibilities are created with the proposed solution:
The DirectoryGenerator can set the sort and other parameters based
on request parameters.
Most Transformers use parameters that could be chosen by Selectors.
The PDFSerializer can set the ownerPassword and other parameters
based on the current user or request parameters.
The fix is one short function added to
PipelineEventComponentProcessingNode and called in the line that sets
the Parameters of the three child classes. Maintenance would be easy.
I do not understand Joerg's objections:
IMO it should not be possible...
Why not? Anything is possible in Cocoon by adding Java code such as
InputModules. This is not about what is possible; this is about what
is easy and expected. Cocoon should be usable without knowing Java.
Nothing in the documentation suggests the second example from the
original post should not work. Cocoon does not even throw an error to
state the XMAP code is invalid.
My main point against this functionality is a conceptional difference.
Why should users care about the conceptual difference between
PipelineEvents and ParentProcessors? The map: elements look equal
when writing an XMAP. Why should users need to learn that some things
just don't work?
Why not make Cocoon easier and more
Re: PipelineEvents eat children
On 20.02.2008 21:04, [EMAIL PROTECTED] wrote:
Writing a reusable InputModule that can handle:
if(resource1.exists()){ return parameter1;}
else if(resource2.exists()){return parameter2;}
else if(resource3.exists()){return parameter3; }
...
else return finalparameter;
is possible. The line in the XMAP would be (assuming only 3 files are checked):
transform
map:parameter name=name
value={exists:file://path/file1.xml,file1returnValue,file://path/file2.xml,file2returnValue,file://path3/file3.xml,file3returnValue,defaultValue}/
/transform
I can write the InputModule in a few minutes and solve my immediate
concern. Maintenance would be a nightmare.
This solution cannot use other Selectors.
This solution cannot set several parameters without reprocessing the
entire list.
This solution cannot handle setting a parameter based on multiple
conditions: if(file1.exists() and file2.exists()) return both;
This solution does not allow every Matcher and Selector to be used to
set parameters for every Generator, Transformer, and Serializer that
allows parameters.
Many new possibilities are created with the proposed solution:
The DirectoryGenerator can set the sort and other parameters based
on request parameters.
Most Transformers use parameters that could be chosen by Selectors.
The PDFSerializer can set the ownerPassword and other parameters
based on the current user or request parameters.
The fix is one short function added to
PipelineEventComponentProcessingNode and called in the line that sets
the Parameters of the three child classes. Maintenance would be easy.
If your logic is that complex you should use a controller beforehands
(like flow script). The sitemap was never supposed to be a controller.
Even existing elements allowing kind of control (map:act) in the sitemap
were considered erroneous.
Nothing in the documentation suggests the second example from the
original post should not work. Cocoon does not even throw an error to
state the XMAP code is invalid.
That's another problem.
My main point against this functionality is a conceptional difference.
Why should users care about the conceptual difference between
PipelineEvents and ParentProcessors?
Implementation is not a concept, the implementation only follows the
concept or the requirements. I already metioned the actual difference in
the last mail.
Joerg
