RE: XInclude in sitemap.xmap
I think you will need to paste the complete sitemap to get more insight into
your issue. Can you please specify which version of Cocoon you're using per
question.. even if repeated. I really need to know the context as some things
might work differently between versions.
I don't exactly remember why you used an input module. In C2.2 I use properties
in combination with both the cocoon-spring-configurator to
- set bean property values in the application context files
- use them directly in my sitemap using ${propertyName}
map:match pattern=exportMergedFiles/*
map:generate src=cocoon:/linkinginfo/{1}/
map:transform src=xslt/writeTopics.xslt type=saxon
map:parameter name=folderPath value=${exportFolder}/{1}/merged/
/map:transform
map:serialize type=xml/
/map:match
Robby
-Original Message-
From: Mansour Al Akeel [mailto:mansour.alak...@gmail.com]
Sent: Wednesday, November 14, 2012 6:40 AM
To: users@cocoon.apache.org
Subject: Re: XInclude in sitemap.xmap
Thank you both for helping.
Robby,
this is the message I am getting now.
05:35:08.304 [btpool0-1] DEBUG o.a.cocoon.pipeline.AbstractPipeline - Adding
component XMLSerializer(hashCode=306853147) to pipeline
[CachingPipeline(hashCode=1346781896
components=[XMLGenerator(hashCode=1918414275
internalGenerator=URLGenerator(hashCode=1966798757
source=file:/home/mansour/workspace/pipelines/repo/articles/example/index.xml)),
XIncludeTransformer(hashCode=950275600
baseUrl=file:/{global:base.repo.path}/articles/{map:id}/)])].
05:35:08.304 [btpool0-1] DEBUG o.a.cocoon.pipeline.AbstractPipeline - Going to
link the component XMLGenerator(hashCode=1918414275
internalGenerator=URLGenerator(hashCode=1966798757
source=file:/home/mansour/workspace/pipelines/repo/articles/example/index.xml))
with XIncludeTransformer(hashCode=950275600
baseUrl=file:/{global:base.repo.path}/articles/{map:id}/).
05:35:08.304 [btpool0-1] DEBUG o.a.cocoon.pipeline.AbstractPipeline - Going to
link the component XIncludeTransformer(hashCode=950275600
baseUrl=file:/{global:base.repo.path}/articles/{map:id}/) with
XMLSerializer(hashCode=306853147).
It looks like the baseUrl is not being resolved with the input modules. For
example:
baseUrl=file:/{global:base.repo.path}/articles/{map:id}/
Your efforts is highly appreciated.
Thank you.
On Tue, Nov 13, 2012 at 10:43 AM, Francesco Chicchiriccò ilgro...@apache.org
wrote:
On 13/11/2012 16:33, Robby Pelssers wrote:
Ok..
I fixed the issue:
map:match equals=aggregation/xinclude-transformer
map:generate src=aggregation/xinclude.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl value=file:///c:/tmp//
map:parameter name=test value=hello world/
/map:transform
map:serialize type=xml /
/map:match
Works now.
I committed the fix to Cocoon3 trunk.
Hi Robby,
thank you for taking care of this: just tested your fix and the build
runs fine.
For records, could you please file an issue on JIRA (COCOON3), add
your fix revision number as comment and then close it?
Thanks.
Regards.
-Original Message-
From: Robby Pelssers [mailto:robby.pelss...@nxp.com]
Sent: Tuesday, November 13, 2012 2:49 PM
To: users@cocoon.apache.org
Subject: RE: XInclude in sitemap.xmap
Ok... I found the problem.
Inside org.apache.cocoon.sitemap.node.AbstractSitemapNode the baseUrl is
overridden, although it correctly receives the baseUrl.
invocationParams = {
baseUrl=file:///c:/tmp/
cacheKey={map:0}
test=hello world
}
protected InvocationResult invoke(final String src, final String
type, final Invocation invocation) {
// set the baseUrl PROBLEMATIC PART
invocationParams.put(baseUrl, invocation.resolve());
}
But before starting making changes... this might need careful attention.
Robby
-Original Message-
From: Robby Pelssers [mailto:robby.pelss...@nxp.com]
Sent: Tuesday, November 13, 2012 2:32 PM
To: users@cocoon.apache.org
Subject: RE: XInclude in sitemap.xmap
I'm debugging your issue and so far I'm pretty bedazzled about what the hell
is going on:
map:match equals=aggregation/xinclude-transformer
map:generate src=aggregation/xinclude.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl value=file:///c:/tmp//
map:parameter name=test value=hello world/
/map:transform
map:serialize type=xml /
/map:match
While debugging I see following Configuration - MapString, Object
baseUrl=file:/C:/workspaces/apache/cocoon/cocoon3/trunk/cocoon-sample
/./src/main/resources/COB-INF/
cacheKey=aggregation/xinclude-transformer
test=hello world
Will keep you posted.. Maybe the baseUrl is somewhere overridden while
setting up the pipeline? Anyone
Re: XInclude in sitemap.xmap
I am using 3.0.0-beta-1-SNAPSHOT built from trunk. Here's my sitemap:
map:pipeline
map:match pattern=article/{id}.xml
map:generate
src={global:base.repo.path}/articles/{map:id}/index.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl
value={global:base.repo.path}/articles/{map:id}/ /
/map:transform
!-- map:transform src=sheets/html/xslthl.xsl / --
map:serialize type=xml /
/map:match
Here's part of the document:
Another Example using xinclude:
===
programlisting language=c
xi:include href=hello.c parse=text
xmlns:xi=http://www.w3.org/2001/XInclude/
/programlisting
Here's the log:
15:04:37.529 [btpool0-1] DEBUG o.a.cocoon.pipeline.CachingPipeline -
~ adding ParameterCacheKey(hashCode=516462290
parameters={encoding=UTF-8, method=xml}) for component
XMLSerializer(hashCode=834671663)
15:04:37.530 [btpool0-1] DEBUG o.a.cocoon.pipeline.CachingPipeline -
Creating CompoundCacheKey(hashCode=2115562712
key=[TimestampCacheKey(hashCode=2006330189
url=file:/home/mansour/workspace/pipelines/repo/articles/example/index.xml
timestamp=1352905028000 (2012-11-14 14:57:08.0)),
CachedCacheKey(hashCode=772251321
internalCacheKey=ObjectCacheKey(hashCode=686698957
obj=article/example.xml)
cachedCacheKey=org.apache.cocoon.pipeline.caching.InvalidCacheKey@b78a1f0d),
ParameterCacheKey(hashCode=516462290 parameters={encoding=UTF-8,
method=xml})]) for pipeline CachingPipeline(hashCode=1875503051
components=[XMLGenerator(hashCode=437776393
internalGenerator=URLGenerator(hashCode=333002925
source=file:/home/mansour/workspace/pipelines/repo/articles/example/index.xml)),
XIncludeTransformer(hashCode=1313024268
baseUrl=file:/home/mansour/workspace/pipelines/contents/src/main/resources/COB-INF/{global:base.repo.path}/articles/{map:id}/),
XMLSerializer(hashCode=834671663)])
15:04:37.530 [btpool0-1] INFO o.a.cocoon.servlet.RequestProcessor -
Going to send NOT MODIFIED response: statusCode=304, lastModified=-1
15:04:37.530 [btpool0-1] INFO o.a.cocoon.servlet.RequestProcessor -
Sitemap execution for /article/example.xml took 195.35498 ms.
The variables are matching the correct document, and it's served
correctly, but without xincludes being processed.
On Wed, Nov 14, 2012 at 6:54 AM, Robby Pelssers robby.pelss...@nxp.com wrote:
I think you will need to paste the complete sitemap to get more insight into
your issue. Can you please specify which version of Cocoon you're using per
question.. even if repeated. I really need to know the context as some things
might work differently between versions.
I don't exactly remember why you used an input module. In C2.2 I use
properties in combination with both the cocoon-spring-configurator to
- set bean property values in the application context files
- use them directly in my sitemap using ${propertyName}
map:match pattern=exportMergedFiles/*
map:generate src=cocoon:/linkinginfo/{1}/
map:transform src=xslt/writeTopics.xslt type=saxon
map:parameter name=folderPath
value=${exportFolder}/{1}/merged/
/map:transform
map:serialize type=xml/
/map:match
Robby
-Original Message-
From: Mansour Al Akeel [mailto:mansour.alak...@gmail.com]
Sent: Wednesday, November 14, 2012 6:40 AM
To: users@cocoon.apache.org
Subject: Re: XInclude in sitemap.xmap
Thank you both for helping.
Robby,
this is the message I am getting now.
05:35:08.304 [btpool0-1] DEBUG o.a.cocoon.pipeline.AbstractPipeline - Adding
component XMLSerializer(hashCode=306853147) to pipeline
[CachingPipeline(hashCode=1346781896
components=[XMLGenerator(hashCode=1918414275
internalGenerator=URLGenerator(hashCode=1966798757
source=file:/home/mansour/workspace/pipelines/repo/articles/example/index.xml)),
XIncludeTransformer(hashCode=950275600
baseUrl=file:/{global:base.repo.path}/articles/{map:id}/)])].
05:35:08.304 [btpool0-1] DEBUG o.a.cocoon.pipeline.AbstractPipeline - Going
to link the component XMLGenerator(hashCode=1918414275
internalGenerator=URLGenerator(hashCode=1966798757
source=file:/home/mansour/workspace/pipelines/repo/articles/example/index.xml))
with XIncludeTransformer(hashCode=950275600
baseUrl=file:/{global:base.repo.path}/articles/{map:id}/).
05:35:08.304 [btpool0-1] DEBUG o.a.cocoon.pipeline.AbstractPipeline - Going
to link the component XIncludeTransformer(hashCode=950275600
baseUrl=file:/{global:base.repo.path}/articles/{map:id}/) with
XMLSerializer(hashCode=306853147).
It looks like the baseUrl is not being resolved with the input modules. For
example:
baseUrl=file:/{global:base.repo.path}/articles/{map:id}/
Your efforts is highly appreciated.
Thank you.
On Tue, Nov 13, 2012 at 10:43 AM, Francesco Chicchiriccò
Re: Trouble with disable-output-escaping
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robby, On 11/13/12 1:41 PM, Robby Pelssers wrote: Allright... You should reminder this tip. It will only work if you do this in the very last transformer right before calling the serializer. Okay, since I have a number of transform operations, I'll have to do some fancy footwork. Would this work? map:match pattern=foo.html map:generate src=source.xml / map:transform src=generate-cincludes-1.xsl / map:transform src=generate-cincludes-2.xsl / map:transform type=cinclude / !-- this is the XSL I'm working with: -- map:transform src=the-transformer-in-question.xsl / In the above XSL, add an attribute (or element) to the text I want to un-escape. map:transform type=cinclude label=content / map:transform type=i18n / map:transform src=strip-namespace.xsl / Here, I could modify the strip-namespace.xsl to also find anything wrapped in the special un-escapify element (or with a similar attribute) and use disable-output-escaping=yes here? map:serialize type=xhtml / /map:match You owe me a beer ;-) Not quite yet: I haven't got this sorted, yet. I'll buy you one if you are going to attend ApacheCon NA 2013. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCjwM8ACgkQ9CaO5/Lv0PBIkwCcC6NGOvLl1Qc15mrZDMk5iuGg noQAn0MFKEzBAcXNu63J1MXHGp7Kwths =kyBO -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
RE: Trouble with disable-output-escaping
Lol... Ok... I had similar issues and one way I solved this issue is by just wrapping that content in a special custom tag. In the last XSLT I matched on that tag and used disable-output-escaping. http://robbypelssers.blogspot.nl/2009/06/escaping-html-with-xslt.html Let's see if that's worth a beer ;-) Cheers, Robby -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, November 14, 2012 5:03 PM To: users@cocoon.apache.org Subject: Re: Trouble with disable-output-escaping -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robby, On 11/13/12 1:41 PM, Robby Pelssers wrote: Allright... You should reminder this tip. It will only work if you do this in the very last transformer right before calling the serializer. Okay, since I have a number of transform operations, I'll have to do some fancy footwork. Would this work? map:match pattern=foo.html map:generate src=source.xml / map:transform src=generate-cincludes-1.xsl / map:transform src=generate-cincludes-2.xsl / map:transform type=cinclude / !-- this is the XSL I'm working with: -- map:transform src=the-transformer-in-question.xsl / In the above XSL, add an attribute (or element) to the text I want to un-escape. map:transform type=cinclude label=content / map:transform type=i18n / map:transform src=strip-namespace.xsl / Here, I could modify the strip-namespace.xsl to also find anything wrapped in the special un-escapify element (or with a similar attribute) and use disable-output-escaping=yes here? map:serialize type=xhtml / /map:match You owe me a beer ;-) Not quite yet: I haven't got this sorted, yet. I'll buy you one if you are going to attend ApacheCon NA 2013. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCjwM8ACgkQ9CaO5/Lv0PBIkwCcC6NGOvLl1Qc15mrZDMk5iuGg noQAn0MFKEzBAcXNu63J1MXHGp7Kwths =kyBO -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
RE: XInclude in sitemap.xmap
I did a little test myself and by the looks of it it's not supported.
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl
value=file:///c:/{request-param:subfolder}//
/map:transform
I hacked a bit in the cocoon-sample project and invoked this url:
http://localhost:/aggregation/xinclude-transformer?subfolder=tmp
In that case I get a nice XML exception page with following message:
messagec:\{request-param:subfolder}\xinclude\testinclude.xml (The filename,
directory name, or volume label syntax is incorrect)/message
This means... that input modules are not supported yet. Will be interesting to
see if we plan to support this in C3. But this would work in C2.2 as I've used
inputmodules quite a lot.
Robby
-Original Message-
From: Mansour Al Akeel [mailto:mansour.alak...@gmail.com]
Sent: Wednesday, November 14, 2012 4:09 PM
To: users@cocoon.apache.org
Subject: Re: XInclude in sitemap.xmap
I am using 3.0.0-beta-1-SNAPSHOT built from trunk. Here's my sitemap:
map:pipeline
map:match pattern=article/{id}.xml
map:generate
src={global:base.repo.path}/articles/{map:id}/index.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl
value={global:base.repo.path}/articles/{map:id}/ /
/map:transform
!-- map:transform src=sheets/html/xslthl.xsl / --
map:serialize type=xml /
/map:match
Here's part of the document:
Another Example using xinclude:
===
programlisting language=c
xi:include href=hello.c parse=text
xmlns:xi=http://www.w3.org/2001/XInclude/
/programlisting
Here's the log:
15:04:37.529 [btpool0-1] DEBUG o.a.cocoon.pipeline.CachingPipeline - ~ adding
ParameterCacheKey(hashCode=516462290
parameters={encoding=UTF-8, method=xml}) for component
XMLSerializer(hashCode=834671663)
15:04:37.530 [btpool0-1] DEBUG o.a.cocoon.pipeline.CachingPipeline - Creating
CompoundCacheKey(hashCode=2115562712
key=[TimestampCacheKey(hashCode=2006330189
url=file:/home/mansour/workspace/pipelines/repo/articles/example/index.xml
timestamp=1352905028000 (2012-11-14 14:57:08.0)),
CachedCacheKey(hashCode=772251321
internalCacheKey=ObjectCacheKey(hashCode=686698957
obj=article/example.xml)
cachedCacheKey=org.apache.cocoon.pipeline.caching.InvalidCacheKey@b78a1f0d),
ParameterCacheKey(hashCode=516462290 parameters={encoding=UTF-8,
method=xml})]) for pipeline CachingPipeline(hashCode=1875503051
components=[XMLGenerator(hashCode=437776393
internalGenerator=URLGenerator(hashCode=333002925
source=file:/home/mansour/workspace/pipelines/repo/articles/example/index.xml)),
XIncludeTransformer(hashCode=1313024268
baseUrl=file:/home/mansour/workspace/pipelines/contents/src/main/resources/COB-INF/{global:base.repo.path}/articles/{map:id}/),
XMLSerializer(hashCode=834671663)])
15:04:37.530 [btpool0-1] INFO o.a.cocoon.servlet.RequestProcessor - Going to
send NOT MODIFIED response: statusCode=304, lastModified=-1 15:04:37.530
[btpool0-1] INFO o.a.cocoon.servlet.RequestProcessor - Sitemap execution for
/article/example.xml took 195.35498 ms.
The variables are matching the correct document, and it's served correctly, but
without xincludes being processed.
On Wed, Nov 14, 2012 at 6:54 AM, Robby Pelssers robby.pelss...@nxp.com wrote:
I think you will need to paste the complete sitemap to get more insight into
your issue. Can you please specify which version of Cocoon you're using per
question.. even if repeated. I really need to know the context as some things
might work differently between versions.
I don't exactly remember why you used an input module. In C2.2 I use
properties in combination with both the cocoon-spring-configurator to
- set bean property values in the application context files
- use them directly in my sitemap using ${propertyName}
map:match pattern=exportMergedFiles/*
map:generate src=cocoon:/linkinginfo/{1}/
map:transform src=xslt/writeTopics.xslt type=saxon
map:parameter name=folderPath
value=${exportFolder}/{1}/merged/
/map:transform
map:serialize type=xml/
/map:match
Robby
-Original Message-
From: Mansour Al Akeel [mailto:mansour.alak...@gmail.com]
Sent: Wednesday, November 14, 2012 6:40 AM
To: users@cocoon.apache.org
Subject: Re: XInclude in sitemap.xmap
Thank you both for helping.
Robby,
this is the message I am getting now.
05:35:08.304 [btpool0-1] DEBUG o.a.cocoon.pipeline.AbstractPipeline -
Adding component XMLSerializer(hashCode=306853147) to pipeline
[CachingPipeline(hashCode=1346781896
components=[XMLGenerator(hashCode=1918414275
internalGenerator=URLGenerator(hashCode=1966798757
RE: XInclude in sitemap.xmap
The solution you're looking for resides in using a LanguageInterpreter.
Cocoon already has a few implementations:
- org.apache.cocoon.sitemap.expression.SettingsInterpreter (works together
with cocoon-spring-configurator)
- org.apache.cocoon.sitemap.expression.JexlLanguageInterpreter
- org.apache.cocoon.sitemap.expression.SitemapLanguageInterpreter
http://cocoon.apache.org/3.0/apidocs/index.html
In cocoon-expression-language.xml these are configured as beans. You see that
the last part after the colon is the prefix you can use in a sitemap. I think
you should just use the SettingsInterpreter in your case. It's the default way
to access properties.
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd;
bean name=org.apache.cocoon.sitemap.expression.LanguageInterpreterFactory
class=org.apache.cocoon.sitemap.expression.PrototypeLanguageInterpreterFactory
/
bean name=expression-language:map
class=org.apache.cocoon.sitemap.expression.SitemapLanguageInterpreter /
bean name=expression-language:jexl
class=org.apache.cocoon.sitemap.expression.JexlLanguageInterpreter /
bean name=expression-language:global
class=org.apache.cocoon.sitemap.expression.SettingsInterpreter /
/beans
Robby
-Original Message-
From: Robby Pelssers [mailto:robby.pelss...@nxp.com]
Sent: Wednesday, November 14, 2012 5:18 PM
To: users@cocoon.apache.org
Subject: RE: XInclude in sitemap.xmap
I did a little test myself and by the looks of it it's not supported.
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl
value=file:///c:/{request-param:subfolder}//
/map:transform
I hacked a bit in the cocoon-sample project and invoked this url:
http://localhost:/aggregation/xinclude-transformer?subfolder=tmp
In that case I get a nice XML exception page with following message:
messagec:\{request-param:subfolder}\xinclude\testinclude.xml (The filename,
directory name, or volume label syntax is incorrect)/message
This means... that input modules are not supported yet. Will be interesting to
see if we plan to support this in C3. But this would work in C2.2 as I've used
inputmodules quite a lot.
Robby
-Original Message-
From: Mansour Al Akeel [mailto:mansour.alak...@gmail.com]
Sent: Wednesday, November 14, 2012 4:09 PM
To: users@cocoon.apache.org
Subject: Re: XInclude in sitemap.xmap
I am using 3.0.0-beta-1-SNAPSHOT built from trunk. Here's my sitemap:
map:pipeline
map:match pattern=article/{id}.xml
map:generate
src={global:base.repo.path}/articles/{map:id}/index.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl
value={global:base.repo.path}/articles/{map:id}/ /
/map:transform
!-- map:transform src=sheets/html/xslthl.xsl / --
map:serialize type=xml /
/map:match
Here's part of the document:
Another Example using xinclude:
===
programlisting language=c
xi:include href=hello.c parse=text
xmlns:xi=http://www.w3.org/2001/XInclude/
/programlisting
Here's the log:
15:04:37.529 [btpool0-1] DEBUG o.a.cocoon.pipeline.CachingPipeline - ~ adding
ParameterCacheKey(hashCode=516462290
parameters={encoding=UTF-8, method=xml}) for component
XMLSerializer(hashCode=834671663)
15:04:37.530 [btpool0-1] DEBUG o.a.cocoon.pipeline.CachingPipeline - Creating
CompoundCacheKey(hashCode=2115562712
key=[TimestampCacheKey(hashCode=2006330189
url=file:/home/mansour/workspace/pipelines/repo/articles/example/index.xml
timestamp=1352905028000 (2012-11-14 14:57:08.0)),
CachedCacheKey(hashCode=772251321
internalCacheKey=ObjectCacheKey(hashCode=686698957
obj=article/example.xml)
cachedCacheKey=org.apache.cocoon.pipeline.caching.InvalidCacheKey@b78a1f0d),
ParameterCacheKey(hashCode=516462290 parameters={encoding=UTF-8,
method=xml})]) for pipeline CachingPipeline(hashCode=1875503051
components=[XMLGenerator(hashCode=437776393
internalGenerator=URLGenerator(hashCode=333002925
source=file:/home/mansour/workspace/pipelines/repo/articles/example/index.xml)),
XIncludeTransformer(hashCode=1313024268
baseUrl=file:/home/mansour/workspace/pipelines/contents/src/main/resources/COB-INF/{global:base.repo.path}/articles/{map:id}/),
XMLSerializer(hashCode=834671663)])
15:04:37.530 [btpool0-1] INFO o.a.cocoon.servlet.RequestProcessor - Going to
send NOT MODIFIED response: statusCode=304, lastModified=-1 15:04:37.530
[btpool0-1] INFO o.a.cocoon.servlet.RequestProcessor - Sitemap execution for
/article/example.xml took 195.35498 ms.
The variables are matching the correct document, and
RE: XInclude in sitemap.xmap
I'm closing in on finding the issue but not sure if I can fix it this week.
Test 1: Use {global:propertyName} in @src of a generator works fine
-
map:match equals=aggregation/xinclude-transformer
map:generate src=aggregation/{global:testProperty}.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
/map:transform
map:serialize type=xml /
/map:match
Test2: Use {global:propertyName} in the @value of a parameter does not seem to
work
map:match equals=aggregation/xinclude-transformer
map:generate src=aggregation/xinclude.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl value={global:testProperty}/
/map:transform
map:serialize type=xml /
/map:match
The real magic happens in org.apache.cocoon.sitemap.InvocationImpl
public Object resolveParameter(final String parameter) {
}
But I think that method is not called for evaluating @value of a
map:parameter.
If anyone can fix this today.. be my guest. Otherwise I will take another look
this week (latest this weekend).
Robby
-Original Message-
From: Robby Pelssers [mailto:robby.pelss...@nxp.com]
Sent: Wednesday, November 14, 2012 5:38 PM
To: users@cocoon.apache.org
Subject: RE: XInclude in sitemap.xmap
The solution you're looking for resides in using a LanguageInterpreter.
Cocoon already has a few implementations:
- org.apache.cocoon.sitemap.expression.SettingsInterpreter (works together
with cocoon-spring-configurator)
- org.apache.cocoon.sitemap.expression.JexlLanguageInterpreter
- org.apache.cocoon.sitemap.expression.SitemapLanguageInterpreter
http://cocoon.apache.org/3.0/apidocs/index.html
In cocoon-expression-language.xml these are configured as beans. You see that
the last part after the colon is the prefix you can use in a sitemap. I think
you should just use the SettingsInterpreter in your case. It's the default way
to access properties.
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd;
bean name=org.apache.cocoon.sitemap.expression.LanguageInterpreterFactory
class=org.apache.cocoon.sitemap.expression.PrototypeLanguageInterpreterFactory
/
bean name=expression-language:map
class=org.apache.cocoon.sitemap.expression.SitemapLanguageInterpreter /
bean name=expression-language:jexl
class=org.apache.cocoon.sitemap.expression.JexlLanguageInterpreter /
bean name=expression-language:global
class=org.apache.cocoon.sitemap.expression.SettingsInterpreter /
/beans
Robby
-Original Message-
From: Robby Pelssers [mailto:robby.pelss...@nxp.com]
Sent: Wednesday, November 14, 2012 5:18 PM
To: users@cocoon.apache.org
Subject: RE: XInclude in sitemap.xmap
I did a little test myself and by the looks of it it's not supported.
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl
value=file:///c:/{request-param:subfolder}//
/map:transform
I hacked a bit in the cocoon-sample project and invoked this url:
http://localhost:/aggregation/xinclude-transformer?subfolder=tmp
In that case I get a nice XML exception page with following message:
messagec:\{request-param:subfolder}\xinclude\testinclude.xml (The filename,
directory name, or volume label syntax is incorrect)/message
This means... that input modules are not supported yet. Will be interesting to
see if we plan to support this in C3. But this would work in C2.2 as I've used
inputmodules quite a lot.
Robby
-Original Message-
From: Mansour Al Akeel [mailto:mansour.alak...@gmail.com]
Sent: Wednesday, November 14, 2012 4:09 PM
To: users@cocoon.apache.org
Subject: Re: XInclude in sitemap.xmap
I am using 3.0.0-beta-1-SNAPSHOT built from trunk. Here's my sitemap:
map:pipeline
map:match pattern=article/{id}.xml
map:generate
src={global:base.repo.path}/articles/{map:id}/index.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl
value={global:base.repo.path}/articles/{map:id}/ /
/map:transform
!-- map:transform src=sheets/html/xslthl.xsl / --
map:serialize type=xml /
/map:match
Here's part of the document:
Another Example using xinclude:
===
programlisting language=c
xi:include href=hello.c parse=text
xmlns:xi=http://www.w3.org/2001/XInclude/
Modular database actions
Hi, I am using ye old modular database actions which in my opinion is extremely handy tool. I was just wondering, how would I get some sort of a callback from e.g. insert/update action in order to tell the user that his/her data is saved? cheers, - mika - P.S. My two cents for the discussion, Is Cocoon dead?. I have build quite a large application with C2.1. I wanted to see, feel what it is like to use database actions, XSP, CForms and so on. This is what I observed. 1) First of all. Developing an app without some sort of an IDE is pain in the ass. Debugging is almost impossible. No help with your code. No nothing. 2) Modular database actions is something like I said, I like. 3) XSP is super to some stage. I really like it, if taking its restrictions into account. Say anything, I still like it. 4) CForms is a piece of shit hide behind nice curtains. Yeah, I know this is harsh to say. Still, it is something I banged my head against the wall all the time. 5) Jxtemplate and its relatives is hieroglyphic jargon. I wouldn't recommended them to anyone. 6) Flowscript. I never realized why. But the big question. How to do this all with C3. It's another kind of framework? Don't even try to do this? - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Modular database actions
Am 14.11.2012 21:21, schrieb Mika M Lehtonen: Hi, I am using ye old modular database actions which in my opinion is extremely handy tool. I was just wondering, how would I get some sort of a callback from e.g. insert/update action in order to tell the user that his/her data is saved? Gee, I haven't used them myself for about a decade but IIRC if they fail the nested pipeline parts are skipped which is true for all actions in cocoon. Chris. (beeing too lazy to unsubscribe) - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Modular database actions
3) I agree, XSP was very flexible and I do miss it in 2.2/3.x Cocoon. I wonder what kind of limits did you find in XSP ? Its pretty straightforward and very general in nature - you can put any kind of Java and mixmatch with XML. Its auto-compiled into Java classes so you don't have to redeploy anything, while making quick change to the system. It saves us a hell lot of time. Yet, you do have a full insight into Java class source that was auto-generated from .xsp file. Cocoon assists you with exact line number of problematic code while debugging. You also have full cache support of XSP files and thus blazingly fast responses! I find only advantages and no limits actually, notwithstanding the model/view/controller code blending, but its a kind of convention that you follow. What I dislike in the recent versions of Cocoon is its strict adherence to Spring framework and/or ORM/Hibernate. If you only use XML as native data format and only need native SQL transactions, why should you need any ORM ? ORM creates additional overhead in the system, another layer of mapping between your business logic and DB, another impedance mismatch. If you really care about the performance, you need to consider very carefully your persistence logic. IMHO, we ought to have the option to use only those parts of API that we actually need. Greetings, Greg 2012/11/14 Mika M Lehtonen m...@digikartta.net Hi, I am using ye old modular database actions which in my opinion is extremely handy tool. I was just wondering, how would I get some sort of a callback from e.g. insert/update action in order to tell the user that his/her data is saved? cheers, - mika - P.S. My two cents for the discussion, Is Cocoon dead?. I have build quite a large application with C2.1. I wanted to see, feel what it is like to use database actions, XSP, CForms and so on. This is what I observed. 1) First of all. Developing an app without some sort of an IDE is pain in the ass. Debugging is almost impossible. No help with your code. No nothing. 2) Modular database actions is something like I said, I like. 3) XSP is super to some stage. I really like it, if taking its restrictions into account. Say anything, I still like it. 4) CForms is a piece of shit hide behind nice curtains. Yeah, I know this is harsh to say. Still, it is something I banged my head against the wall all the time. 5) Jxtemplate and its relatives is hieroglyphic jargon. I wouldn't recommended them to anyone. 6) Flowscript. I never realized why. But the big question. How to do this all with C3. It's another kind of framework? Don't even try to do this? --**--**- To unsubscribe, e-mail: users-unsubscribe@cocoon.**apache.orgusers-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: XInclude in sitemap.xmap
Robby, thank you for taking care of this issue.
On Wed, Nov 14, 2012 at 12:11 PM, Robby Pelssers robby.pelss...@nxp.com wrote:
I'm closing in on finding the issue but not sure if I can fix it this week.
Test 1: Use {global:propertyName} in @src of a generator works fine
-
map:match equals=aggregation/xinclude-transformer
map:generate src=aggregation/{global:testProperty}.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
/map:transform
map:serialize type=xml /
/map:match
Test2: Use {global:propertyName} in the @value of a parameter does not seem
to work
map:match equals=aggregation/xinclude-transformer
map:generate src=aggregation/xinclude.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl value={global:testProperty}/
/map:transform
map:serialize type=xml /
/map:match
The real magic happens in org.apache.cocoon.sitemap.InvocationImpl
public Object resolveParameter(final String parameter) {
}
But I think that method is not called for evaluating @value of a
map:parameter.
If anyone can fix this today.. be my guest. Otherwise I will take another
look this week (latest this weekend).
Robby
-Original Message-
From: Robby Pelssers [mailto:robby.pelss...@nxp.com]
Sent: Wednesday, November 14, 2012 5:38 PM
To: users@cocoon.apache.org
Subject: RE: XInclude in sitemap.xmap
The solution you're looking for resides in using a LanguageInterpreter.
Cocoon already has a few implementations:
- org.apache.cocoon.sitemap.expression.SettingsInterpreter (works together
with cocoon-spring-configurator)
- org.apache.cocoon.sitemap.expression.JexlLanguageInterpreter
- org.apache.cocoon.sitemap.expression.SitemapLanguageInterpreter
http://cocoon.apache.org/3.0/apidocs/index.html
In cocoon-expression-language.xml these are configured as beans. You see that
the last part after the colon is the prefix you can use in a sitemap. I
think you should just use the SettingsInterpreter in your case. It's the
default way to access properties.
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd;
bean name=org.apache.cocoon.sitemap.expression.LanguageInterpreterFactory
class=org.apache.cocoon.sitemap.expression.PrototypeLanguageInterpreterFactory
/
bean name=expression-language:map
class=org.apache.cocoon.sitemap.expression.SitemapLanguageInterpreter /
bean name=expression-language:jexl
class=org.apache.cocoon.sitemap.expression.JexlLanguageInterpreter /
bean name=expression-language:global
class=org.apache.cocoon.sitemap.expression.SettingsInterpreter /
/beans
Robby
-Original Message-
From: Robby Pelssers [mailto:robby.pelss...@nxp.com]
Sent: Wednesday, November 14, 2012 5:18 PM
To: users@cocoon.apache.org
Subject: RE: XInclude in sitemap.xmap
I did a little test myself and by the looks of it it's not supported.
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl
value=file:///c:/{request-param:subfolder}//
/map:transform
I hacked a bit in the cocoon-sample project and invoked this url:
http://localhost:/aggregation/xinclude-transformer?subfolder=tmp
In that case I get a nice XML exception page with following message:
messagec:\{request-param:subfolder}\xinclude\testinclude.xml (The filename,
directory name, or volume label syntax is incorrect)/message
This means... that input modules are not supported yet. Will be interesting
to see if we plan to support this in C3. But this would work in C2.2 as I've
used inputmodules quite a lot.
Robby
-Original Message-
From: Mansour Al Akeel [mailto:mansour.alak...@gmail.com]
Sent: Wednesday, November 14, 2012 4:09 PM
To: users@cocoon.apache.org
Subject: Re: XInclude in sitemap.xmap
I am using 3.0.0-beta-1-SNAPSHOT built from trunk. Here's my sitemap:
map:pipeline
map:match pattern=article/{id}.xml
map:generate
src={global:base.repo.path}/articles/{map:id}/index.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl
value={global:base.repo.path}/articles/{map:id}/ /
/map:transform
!-- map:transform src=sheets/html/xslthl.xsl / --
map:serialize type=xml /
/map:match
Here's part of the
Re: XInclude in sitemap.xmap
One additional problem. This is not related to the property
resolution, but to the XInclude. After I process xinclude, if I apply
another transformation, I get an error:
Caused by: org.xml.sax.SAXException: Namespace for prefix 'xi' not
found.
at
org.apache.cocoon.sax.AbstractSAXTransformer.endPrefixMapping(AbstractSAXTransformer.java:79)
~[cocoon-sax-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
at
org.apache.cocoon.sax.component.XIncludeTransformer.endPrefixMapping(XIncludeTransformer.java:515)
~[cocoon-sax-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
The transformation can be any thing simple. Identity transformation
will cause this issue as well. Here's the transformation I am applying
after the xinclude:
?xml version=1.0 encoding=utf-8?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:xi=http://www.w3.org/2001/XInclude;
xsl:template match=@*|node()
xsl:copy
xsl:apply-templates select=@*|node()/
/xsl:copy
/xsl:template
/xsl:stylesheet
And here is the sitemap:
map:match pattern=article/{id}.xml
map:generate
src={global:base.repo.path}/articles/{map:id}/index.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl
value=file:///home/mansour/workspace/pipelines/repo/articles/example/
/
/map:transform
map:transform src=sheets/html/identity.xsl /
map:serialize type=xml /
/map:match
If I remove the identity.xsl step, then things works fine.
I am not sure how to solve this issue, but I think I can use two
match one for each step. However, knowing that cocoon applies xslt
in a pipeline without additional tweaks, should allow me to directly
process the stream with identity.xsl.
Thank you.
On Wed, Nov 14, 2012 at 7:39 PM, Mansour Al Akeel
mansour.alak...@gmail.com wrote:
Robby, thank you for taking care of this issue.
On Wed, Nov 14, 2012 at 12:11 PM, Robby Pelssers robby.pelss...@nxp.com
wrote:
I'm closing in on finding the issue but not sure if I can fix it this week.
Test 1: Use {global:propertyName} in @src of a generator works fine
-
map:match equals=aggregation/xinclude-transformer
map:generate src=aggregation/{global:testProperty}.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
/map:transform
map:serialize type=xml /
/map:match
Test2: Use {global:propertyName} in the @value of a parameter does not seem
to work
map:match equals=aggregation/xinclude-transformer
map:generate src=aggregation/xinclude.xml /
map:transform type=xinclude
map:parameter name=cacheKey value={map:0}/
map:parameter name=baseUrl value={global:testProperty}/
/map:transform
map:serialize type=xml /
/map:match
The real magic happens in org.apache.cocoon.sitemap.InvocationImpl
public Object resolveParameter(final String parameter) {
}
But I think that method is not called for evaluating @value of a
map:parameter.
If anyone can fix this today.. be my guest. Otherwise I will take another
look this week (latest this weekend).
Robby
-Original Message-
From: Robby Pelssers [mailto:robby.pelss...@nxp.com]
Sent: Wednesday, November 14, 2012 5:38 PM
To: users@cocoon.apache.org
Subject: RE: XInclude in sitemap.xmap
The solution you're looking for resides in using a LanguageInterpreter.
Cocoon already has a few implementations:
- org.apache.cocoon.sitemap.expression.SettingsInterpreter (works together
with cocoon-spring-configurator)
- org.apache.cocoon.sitemap.expression.JexlLanguageInterpreter
- org.apache.cocoon.sitemap.expression.SitemapLanguageInterpreter
http://cocoon.apache.org/3.0/apidocs/index.html
In cocoon-expression-language.xml these are configured as beans. You see
that the last part after the colon is the prefix you can use in a sitemap.
I think you should just use the SettingsInterpreter in your case. It's the
default way to access properties.
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd;
bean
name=org.apache.cocoon.sitemap.expression.LanguageInterpreterFactory
class=org.apache.cocoon.sitemap.expression.PrototypeLanguageInterpreterFactory
/
bean name=expression-language:map
class=org.apache.cocoon.sitemap.expression.SitemapLanguageInterpreter /
bean name=expression-language:jexl
