You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by gelo1234 <ge...@gmail.com> on 2013/02/11 12:07:13 UTC
A generator with sitemap parameter in C3
Question 1:
Can we have some example of this one ?
<map:generate type="some-custom">
<map:parameter name="a" value="1"/>
<map:parameter name="b" value="2"/>
</map:generate>
I mean, how to get sitemap parameter value from Java Generator code ?
btw. Request Parameters are obtained by the use of HttpContextHelper, is
this correct ?
Question 2:
What is the best (optimal) way to include XML content generated from
servlet/controller?
<x:include .... src="servlet:/..."/>
If the servlet is calling a REST controller there are 2 invocations
involved (one to gather data, the other one (with e.g. string-template) to
actually serialize the data). Is there any way that REST controller could
serialize the data itself ? without invoking another servlet/Page ?
Question 3:
If the generator is included in some transformer phase (via x:include)
does it still have access to original Request Parameters when invoked with:
<x:include ... src="servlet:/generate?par1=a&par2=b/>
or they are lost (original request params) and substituted by new ones
(par1, par2 from the line above) ?
Greetings,
-Greg
Re: sitemap parameter in C3 (was Re: A generator with sitemap
parameter in C3)
Posted by gelo1234 <ge...@gmail.com>.
So value from any parameter name (not only "source" is available from
setConfiguration(...) configuration object :)
Thanks for clarifying this!
Greetings,
-Greg
2013/2/18 Thorsten Scherler <sc...@gmail.com>
> On 02/11/2013 01:55 PM, gelo1234 wrote:
> > ...
> > So the setup(...) has access to sitemap parameters :) Why not
> > setConfiguration(..) ?
> >
> > Does call:
> > this.setup((Map<String, Object>) configuration)
> > strips off?/adds? some unwanted/additional data for sitemap-servlet
> > framework ?
> >
> > As i recall setConfiguration is for Java only (without
> > sitemap-servlet) Cocoon use and setup is for standard sitemap-servlet
> > ? Is that correct ?
> >
>
> No actually setConfiguration is for passing parameters from the sitemap
> to the component e.g. http://svn.apache.org/r1447255
>
> The setup() will be called when the pipeline setup is called, I think we
> should drop one since it is highly confusing.
>
> salu2
>
> --
> Thorsten Scherler <scherler.at.gmail.com>
> codeBusters S.L. - web based systems
> <consulting, training and solutions>
>
> http://www.codebusters.es/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
Re: sitemap parameter in C3 (was Re: A generator with sitemap parameter
in C3)
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 18/02/2013 14:50, Thorsten Scherler wrote:
> On 02/11/2013 01:55 PM, gelo1234 wrote:
>> ...
>> So the setup(...) has access to sitemap parameters :) Why not
>> setConfiguration(..) ?
>>
>> Does call:
>> this.setup((Map<String, Object>) configuration)
>> strips off?/adds? some unwanted/additional data for sitemap-servlet
>> framework ?
>>
>> As i recall setConfiguration is for Java only (without
>> sitemap-servlet) Cocoon use and setup is for standard sitemap-servlet
>> ? Is that correct ?
>>
> No actually setConfiguration is for passing parameters from the sitemap
> to the component e.g. http://svn.apache.org/r1447255
>
> The setup() will be called when the pipeline setup is called, I think we
> should drop one since it is highly confusing.
+1 - I get often confused as well... :S
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: sitemap parameter in C3 (was Re: A generator with sitemap
parameter in C3)
Posted by Robby Pelssers <Ro...@nxp.com>.
I agree on the fact that it's confusing to say the least when programming against the Java API. And any simplifications on this aspect are welcome.
Robby
-----Original Message-----
From: Thorsten Scherler [mailto:scherler@gmail.com]
Sent: Tuesday, February 19, 2013 11:45 AM
To: users@cocoon.apache.org
Subject: Re: sitemap parameter in C3 (was Re: A generator with sitemap parameter in C3)
On 02/18/2013 02:50 PM, Thorsten Scherler wrote:
> On 02/11/2013 01:55 PM, gelo1234 wrote:
>> ...
>> So the setup(...) has access to sitemap parameters :) Why not
>> setConfiguration(..) ?
>>
>> Does call:
>> this.setup((Map<String, Object>) configuration) strips off?/adds?
>> some unwanted/additional data for sitemap-servlet framework ?
>>
>> As i recall setConfiguration is for Java only (without
>> sitemap-servlet) Cocoon use and setup is for standard sitemap-servlet
>> ? Is that correct ?
>>
> No actually setConfiguration is for passing parameters from the
> sitemap to the component e.g. http://svn.apache.org/r1447255
>
> The setup() will be called when the pipeline setup is called, I think
> we should drop one since it is highly confusing.
PipelineComponent:
/**
* Pass component specific configuration parameters to the pipeline
* component in a generic way. This is useful in environments that
* automatically assemble pipelines with their components and can't use the
* components constructors or setters.
*
* @param configuration The {@link Map} of configuration parameters.
*/
void setConfiguration(Map<String, ? extends Object> configuration);
/**
* The shared object map for this pipeline run.
*
* @param parameters A {@link Map} of parameters that are available to all
* {@link PipelineComponent}s. This is a modifiable map
that can
* be changed by this pipeline component.
*/
void setup(Map<String, Object> parameters);
The main div is global vs. local map. Meaning the configure is intended to only configure the specific component and not all. That makes sense in terms of the sitemap but in a pure java pipeline hardly, well I can imagine a use case where it would be indeed very handy, but first let us look on some java pipes.
I use something like the following to process some droidsTask in java with the help of c3:
/**
* LinkExtractorPipeline.
* @param <T> T extends PipelineComponent */ public class LinkExtractorPipeline<T extends PipelineComponent> extends
NonCachingPipeline<SAXPipelineComponent> {
private static final Logger logger =
LoggerFactory.getLogger(LinkExtractorPipeline.class);
private LinkExtractorTransformer linkExtractorTransformer;
/**
* LinkExtractorPipeline.
*/
public LinkExtractorPipeline() {
linkExtractorTransformer = new LinkExtractorTransformer();
}
@Override
public void setup(OutputStream outputStream, Map<String, Object>
parameters) {
if (outputStream == null) {
throw new SetupException("An output stream must be passed.");
}
try {
this.addComponent(new XMLGenerator((InputStream) parameters.get("src")));
this.addComponent(linkExtractorTransformer);
this.addComponent(new XMLSerializer());
super.setup(outputStream, parameters);
} catch (Exception e) {
String message = "There were a problem setting up the pipeline.";
logger.error(message, e);
throw new SetupException(message, e);
}
}
/**
* @return outLinks
*/
public List<String> getOutLinks() {
return linkExtractorTransformer.getOutLinks();
}
Then I call it from my java code like
LinkExtractorPipeline<SAXPipelineComponent> pipeline =
new LinkExtractorPipeline<SAXPipelineComponent>();
OutputStream output = new BufferedOutputStream(new ByteArrayOutputStream());
// pass parameter to the pipeline
Map<String, Object> parameters = new HashMap<String, Object>();
parameters.put("src", task.getContentEntity().getContent());
pipeline.setup(output, parameters);
try {
pipeline.execute();
} catch (Exception e) {
logger.error("Could not excecute pipeline.", e);
throw new DroidsException(e);
}
Now the main difference to the usage from within the sitemap is that you cannot create your own components like in java and configure them as you please.
However imagine the above LinkExtractorPipeline as pseudo sitemap config:
<map:pipeline id="linkExtractorPipeline">
<map:match pattern="**"> -> we do not have the concept of matcher in the java pipeline
<map:generate src="{droids:content}" />
<map:transform type="linkExtractorTransformer"/>
<map:serialize type="xml"/>
</map:match>
</map:pipeline>
Now since we have the config done in the same class we could do something like <map:pipeline id="linkExtractorPipeline" /> and then simply use spring to link back to LinkExtractorPipeline.class
However the other way around should as well be possible. Imagine we see the sitemap as simple pipe config store, then I could simplify the above code to something like:
LinkExtractorPipeline<SAXPipelineComponent> pipeline = sitemap.getPipeline("linkExtractorPipeline");
and use the pseudo sitemap config instead of the java code LinkExtractorPipeline (leaving along the matcher problematic).
The basic problem is that the concept of matcher and pipeline is a bit different in java vs sitemap pipeline. Originally the main purpose of the pipeline element were to group certain matches out of caching reasons. The matches however decide which part of the code will be called, but basically you can call the pipe as much as you want. In java that is not true. A pipe is disposable, once used it cannot be called again.
I personally would love to see that sitemap pipe and java pipe are the same (better said following the same concept). Basically the java pipes would adopt the concept of matcher and be reusable not disposable.
wdyt?
Regarding the original setup vs. setConfiguration maybe renaming setConfiguration to configure(...) makes more sense and encourage to use the configure method for simple configuration.
If I recall the NekoGenerator modification I could have as well implemented a setDefaultEncoding() and force the config into spring, however that would loose the ability to change it in a specific match.
salu2
--
Thorsten Scherler <scherler.at.gmail.com> codeBusters S.L. - web based systems <consulting, training and solutions>
http://www.codebusters.es/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: sitemap parameter in C3 (was Re: A generator with sitemap parameter
in C3)
Posted by Thorsten Scherler <sc...@gmail.com>.
On 02/18/2013 02:50 PM, Thorsten Scherler wrote:
> On 02/11/2013 01:55 PM, gelo1234 wrote:
>> ...
>> So the setup(...) has access to sitemap parameters :) Why not
>> setConfiguration(..) ?
>>
>> Does call:
>> this.setup((Map<String, Object>) configuration)
>> strips off?/adds? some unwanted/additional data for sitemap-servlet
>> framework ?
>>
>> As i recall setConfiguration is for Java only (without
>> sitemap-servlet) Cocoon use and setup is for standard sitemap-servlet
>> ? Is that correct ?
>>
> No actually setConfiguration is for passing parameters from the sitemap
> to the component e.g. http://svn.apache.org/r1447255
>
> The setup() will be called when the pipeline setup is called, I think we
> should drop one since it is highly confusing.
PipelineComponent:
/**
* Pass component specific configuration parameters to the pipeline
* component in a generic way. This is useful in environments that
* automatically assemble pipelines with their components and can't
use the
* components constructors or setters.
*
* @param configuration The {@link Map} of configuration parameters.
*/
void setConfiguration(Map<String, ? extends Object> configuration);
/**
* The shared object map for this pipeline run.
*
* @param parameters A {@link Map} of parameters that are available
to all
* {@link PipelineComponent}s. This is a modifiable map
that can
* be changed by this pipeline component.
*/
void setup(Map<String, Object> parameters);
The main div is global vs. local map. Meaning the configure is intended
to only configure the specific component and not all. That makes sense
in terms of the sitemap but in a pure java pipeline hardly, well I can
imagine a use case where it would be indeed very handy, but first let us
look on some java pipes.
I use something like the following to process some droidsTask in java
with the help of c3:
/**
* LinkExtractorPipeline.
* @param <T> T extends PipelineComponent
*/
public class LinkExtractorPipeline<T extends PipelineComponent> extends
NonCachingPipeline<SAXPipelineComponent> {
private static final Logger logger =
LoggerFactory.getLogger(LinkExtractorPipeline.class);
private LinkExtractorTransformer linkExtractorTransformer;
/**
* LinkExtractorPipeline.
*/
public LinkExtractorPipeline() {
linkExtractorTransformer = new LinkExtractorTransformer();
}
@Override
public void setup(OutputStream outputStream, Map<String, Object>
parameters) {
if (outputStream == null) {
throw new SetupException("An output stream must be passed.");
}
try {
this.addComponent(new XMLGenerator((InputStream)
parameters.get("src")));
this.addComponent(linkExtractorTransformer);
this.addComponent(new XMLSerializer());
super.setup(outputStream, parameters);
} catch (Exception e) {
String message = "There were a problem setting up the
pipeline.";
logger.error(message, e);
throw new SetupException(message, e);
}
}
/**
* @return outLinks
*/
public List<String> getOutLinks() {
return linkExtractorTransformer.getOutLinks();
}
Then I call it from my java code like
LinkExtractorPipeline<SAXPipelineComponent> pipeline =
new LinkExtractorPipeline<SAXPipelineComponent>();
OutputStream output = new BufferedOutputStream(new
ByteArrayOutputStream());
// pass parameter to the pipeline
Map<String, Object> parameters = new HashMap<String, Object>();
parameters.put("src", task.getContentEntity().getContent());
pipeline.setup(output, parameters);
try {
pipeline.execute();
} catch (Exception e) {
logger.error("Could not excecute pipeline.", e);
throw new DroidsException(e);
}
Now the main difference to the usage from within the sitemap is that you
cannot create your own components like in java and configure them as you
please.
However imagine the above LinkExtractorPipeline as pseudo sitemap config:
<map:pipeline id="linkExtractorPipeline">
<map:match pattern="**"> -> we do not have the concept of matcher
in the java pipeline
<map:generate src="{droids:content}" />
<map:transform type="linkExtractorTransformer"/>
<map:serialize type="xml"/>
</map:match>
</map:pipeline>
Now since we have the config done in the same class we could do
something like <map:pipeline id="linkExtractorPipeline" /> and then
simply use spring to link back to LinkExtractorPipeline.class
However the other way around should as well be possible. Imagine we see
the sitemap as simple pipe config store, then I could simplify the above
code to something like:
LinkExtractorPipeline<SAXPipelineComponent> pipeline =
sitemap.getPipeline("linkExtractorPipeline");
and use the pseudo sitemap config instead of the java code
LinkExtractorPipeline (leaving along the matcher problematic).
The basic problem is that the concept of matcher and pipeline is a bit
different in java vs sitemap pipeline. Originally the main purpose of
the pipeline element were to group certain matches out of caching
reasons. The matches however decide which part of the code will be
called, but basically you can call the pipe as much as you want. In java
that is not true. A pipe is disposable, once used it cannot be called
again.
I personally would love to see that sitemap pipe and java pipe are the
same (better said following the same concept). Basically the java pipes
would adopt the concept of matcher and be reusable not disposable.
wdyt?
Regarding the original setup vs. setConfiguration maybe renaming
setConfiguration to configure(...) makes more sense and encourage to use
the configure method for simple configuration.
If I recall the NekoGenerator modification I could have as well
implemented a setDefaultEncoding() and force the config into spring,
however that would loose the ability to change it in a specific match.
salu2
--
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
sitemap parameter in C3 (was Re: A generator with sitemap parameter
in C3)
Posted by Thorsten Scherler <sc...@gmail.com>.
On 02/11/2013 01:55 PM, gelo1234 wrote:
> ...
> So the setup(...) has access to sitemap parameters :) Why not
> setConfiguration(..) ?
>
> Does call:
> this.setup((Map<String, Object>) configuration)
> strips off?/adds? some unwanted/additional data for sitemap-servlet
> framework ?
>
> As i recall setConfiguration is for Java only (without
> sitemap-servlet) Cocoon use and setup is for standard sitemap-servlet
> ? Is that correct ?
>
No actually setConfiguration is for passing parameters from the sitemap
to the component e.g. http://svn.apache.org/r1447255
The setup() will be called when the pipeline setup is called, I think we
should drop one since it is highly confusing.
salu2
--
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: A generator with sitemap parameter in C3
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 11/02/2013 13:55, gelo1234 wrote:
> Thank you Francesco. That is what I was looking for!! :)
>
> So the setup(...) has access to sitemap parameters :) Why not
> setConfiguration(..) ?
>
> Does call:
> this.setup((Map<String, Object>) configuration)
> strips off?/adds? some unwanted/additional data for sitemap-servlet
> framework ?
>
> As i recall setConfiguration is for Java only (without
> sitemap-servlet) Cocoon use and setup is for standard sitemap-servlet
> ? Is that correct ?
This is correct: I've just reported my own default when I start
developing new sitemap components, with purpose of staying as much
compatible with sitemap and non-sitemap usage.
Regards.
> 2013/2/11 Francesco Chicchiriccò <ilgrosso@apache.org
> <ma...@apache.org>>
>
> On 11/02/2013 13:27, gelo1234 wrote:
>> Ohh...ok that clarifies a problem a bit. So if the generator
>> declaration inside sitemap.xmap does NOT have src=".." attribute
>> i won't get this piece of code [1] executed:
>>
>> if (this.source != null) {
>> Object attributesObj = configuration.get("attributes");
>> if (attributesObj != null && attributesObj instanceof Map) {
>> ...
>> }
>>
>> In case of the custom example given before:
>>
>> <map:generate type="some-custom">
>> ...
>> </map:generate>
>>
>> it does NOT have src attribute (Not every generator got src
>> attribute). So the question is still valid, how to get to those
>> <map:parameter .../> values in such case ? Simply by adding
>> useless src="" attribute to <map:generate ..> e.g.
>>
>> <map:generate type="some-custom" src="http://www.w3c.org"> ?
>>
>> or through the use of some Helper class? as it is in [2] (to
>> Request Parameters instead of <map:parameter name="a"
>> value="jexl:cocoon.request.a"/>) with HttpContextHelper - wonder
>> if there is any equivalent Helper class for Cocoon Sitemap :)
>
> Hi,
> [2] injects HTTP request parameters as sitemap parameters: here's
> why the usage of HttpContextHelper.
>
> Let's suppose you want to implement a generator able to deal with:
>
> <map:generate type="mycustom">
> <map:parameter name="customParam" value="customValue"/>
> </map:generate>
>
> Then you need to
>
> 1. create class MyCustomGenerator extending AbstractSAXGenerator
>
> 2. implement setup() and setConfiguration() - an example
> implementation could be
>
> @Override
> public void setConfiguration(final Map<String, ? extends
> Object> configuration) {
> this.setup((Map<String, Object>) configuration);
> }
>
> @Override
> public void setup(final Map<String, Object> parameters) {
> if (parameters == null) {
> return;
> }
>
> // do something with parameters.get("customParam")
> }
>
> 3. add a file
> src/main/resources/META-INF/cocoon/spring/my-sitemap-components.xml with
> the following content:
>
> <beans xmlns="http://www.springframework.org/schema/beans"
> <http://www.springframework.org/schema/beans>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> <http://www.w3.org/2001/XMLSchema-instance>
> xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd">
>
> <bean name="generator:mycustom" class="xx.yyy.MyCustomGenerator"
> scope="prototype"/>
>
> </beans>
>
> HTH
>
> Regards.
>
>> [1]
>> https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XSLTTransformer.java
>> [2]
>> https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-servlet/src/main/java/org/apache/cocoon/servlet/component/RequestParametersGenerator.java
>>
>> 2013/2/11 Francesco Chicchiriccò <ilgrosso@apache.org
>> <ma...@apache.org>>
>>
>> On 11/02/2013 12:07, gelo1234 wrote:
>>
>> Question 1:
>> Can we have some example of this one ?
>>
>> <map:generate type="some-custom">
>> <map:parameter name="a" value="1"/>
>> <map:parameter name="b" value="2"/>
>> </map:generate>
>>
>> I mean, how to get sitemap parameter value from Java
>> Generator code ?
>> btw. Request Parameters are obtained by the use of
>> HttpContextHelper, is this correct ?
>>
>>
>> No: you can access map:parameter elements from within Java
>> code in the same way how this is done in the XSLTTransformer
>> [1]: consider that "source" is the only pre-defined parameter
>> you have in any pipeline component, mapped to the 'src' XML
>> attribute.
>>
>>
>> Question 2:
>> What is the best (optimal) way to include XML content
>> generated from
>> servlet/controller?
>>
>> <x:include .... src="servlet:/..."/>
>>
>> If the servlet is calling a REST controller there are 2
>> invocations involved (one to gather data, the other one
>> (with e.g. string-template) to actually serialize the
>> data). Is there any way that REST controller could
>> serialize the data itself ? without invoking another
>> servlet/Page ?
>>
>>
>> Not that I know: anyway I am using similar includes in
>> different production environments with high load and I've
>> experienced no troubles so far.
>>
>>
>> Question 3:
>> If the generator is included in some transformer phase
>> (via x:include)
>> does it still have access to original Request Parameters
>> when invoked with:
>>
>> <x:include ... src="servlet:/generate?par1=a&par2=b/>
>>
>> or they are lost (original request params) and
>> substituted by new ones (par1, par2 from the line above)?
>>
>>
>> They are lost: you need to explicitly pass them though.
>>
>> Regards.
>>
>> [1]
>> https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XSLTTransformer.java
>>
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: A generator with sitemap parameter in C3
Posted by gelo1234 <ge...@gmail.com>.
Thank you Francesco. That is what I was looking for!! :)
So the setup(...) has access to sitemap parameters :) Why not
setConfiguration(..) ?
Does call:
this.setup((Map<String, Object>) configuration)
strips off?/adds? some unwanted/additional data for sitemap-servlet
framework ?
As i recall setConfiguration is for Java only (without sitemap-servlet)
Cocoon use and setup is for standard sitemap-servlet ? Is that correct ?
Greetings,
Greg
2013/2/11 Francesco Chicchiriccò <il...@apache.org>
> On 11/02/2013 13:27, gelo1234 wrote:
>
> Ohh...ok that clarifies a problem a bit. So if the generator
> declaration inside sitemap.xmap does NOT have src=".." attribute i won't
> get this piece of code [1] executed:
>
> if (this.source != null) {
> Object attributesObj = configuration.get("attributes");
> if (attributesObj != null && attributesObj instanceof Map) {
> ...
> }
>
>
> In case of the custom example given before:
>
> <map:generate type="some-custom">
> ...
> </map:generate>
>
> it does NOT have src attribute (Not every generator got src attribute).
> So the question is still valid, how to get to those <map:parameter .../>
> values in such case ? Simply by adding useless src="" attribute to
> <map:generate ..> e.g.
>
> <map:generate type="some-custom" src="http://www.w3c.org"> ?
>
> or through the use of some Helper class? as it is in [2] (to Request
> Parameters instead of <map:parameter name="a"
> value="jexl:cocoon.request.a"/>) with HttpContextHelper - wonder if there
> is any equivalent Helper class for Cocoon Sitemap :)
>
>
> Hi,
> [2] injects HTTP request parameters as sitemap parameters: here's why the
> usage of HttpContextHelper.
>
> Let's suppose you want to implement a generator able to deal with:
>
> <map:generate type="mycustom">
> <map:parameter name="customParam" value="customValue"/>
> </map:generate>
>
> Then you need to
>
> 1. create class MyCustomGenerator extending AbstractSAXGenerator
>
> 2. implement setup() and setConfiguration() - an example implementation
> could be
>
> @Override
> public void setConfiguration(final Map<String, ? extends Object>
> configuration) {
> this.setup((Map<String, Object>) configuration);
> }
>
> @Override
> public void setup(final Map<String, Object> parameters) {
> if (parameters == null) {
> return;
> }
>
> // do something with parameters.get("customParam")
> }
>
> 3. add a file
> src/main/resources/META-INF/cocoon/spring/my-sitemap-components.xml with
> the following content:
>
> <beans xmlns="http://www.springframework.org/schema/beans"<http://www.springframework.org/schema/beans>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<http://www.w3.org/2001/XMLSchema-instance>
> xsi:schemaLocation="http://www.springframework.org/schema/beans
>
> http://www.springframework.org/schema/beans/spring-beans.xsd">
>
> <bean name="generator:mycustom" class="xx.yyy.MyCustomGenerator"
> scope="prototype"/>
>
> </beans>
>
> HTH
>
> Regards.
>
> [1]
> https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XSLTTransformer.java
> [2]
> https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-servlet/src/main/java/org/apache/cocoon/servlet/component/RequestParametersGenerator.java
>
> 2013/2/11 Francesco Chicchiriccò <il...@apache.org>
>
>> On 11/02/2013 12:07, gelo1234 wrote:
>>
>>> Question 1:
>>> Can we have some example of this one ?
>>>
>>> <map:generate type="some-custom">
>>> <map:parameter name="a" value="1"/>
>>> <map:parameter name="b" value="2"/>
>>> </map:generate>
>>>
>>> I mean, how to get sitemap parameter value from Java Generator code ?
>>> btw. Request Parameters are obtained by the use of HttpContextHelper, is
>>> this correct ?
>>>
>>
>> No: you can access map:parameter elements from within Java code in the
>> same way how this is done in the XSLTTransformer [1]: consider that
>> "source" is the only pre-defined parameter you have in any pipeline
>> component, mapped to the 'src' XML attribute.
>>
>>
>> Question 2:
>>> What is the best (optimal) way to include XML content generated from
>>> servlet/controller?
>>>
>>> <x:include .... src="servlet:/..."/>
>>>
>>> If the servlet is calling a REST controller there are 2 invocations
>>> involved (one to gather data, the other one (with e.g. string-template) to
>>> actually serialize the data). Is there any way that REST controller could
>>> serialize the data itself ? without invoking another servlet/Page ?
>>>
>>
>> Not that I know: anyway I am using similar includes in different
>> production environments with high load and I've experienced no troubles so
>> far.
>>
>>
>> Question 3:
>>> If the generator is included in some transformer phase (via x:include)
>>> does it still have access to original Request Parameters when invoked
>>> with:
>>>
>>> <x:include ... src="servlet:/generate?par1=a&par2=b/>
>>>
>>> or they are lost (original request params) and substituted by new ones
>>> (par1, par2 from the line above)?
>>>
>>
>> They are lost: you need to explicitly pass them though.
>>
>> Regards.
>>
>> [1]
>> https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XSLTTransformer.java
>>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Memberhttp://people.apache.org/~ilgrosso/
>
>
Re: A generator with sitemap parameter in C3
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 11/02/2013 13:27, gelo1234 wrote:
> Ohh...ok that clarifies a problem a bit. So if the generator
> declaration inside sitemap.xmap does NOT have src=".." attribute i
> won't get this piece of code [1] executed:
>
> if (this.source != null) {
> Object attributesObj = configuration.get("attributes");
> if (attributesObj != null && attributesObj instanceof Map) {
> ...
> }
>
> In case of the custom example given before:
>
> <map:generate type="some-custom">
> ...
> </map:generate>
>
> it does NOT have src attribute (Not every generator got src
> attribute). So the question is still valid, how to get to those
> <map:parameter .../> values in such case ? Simply by adding useless
> src="" attribute to <map:generate ..> e.g.
>
> <map:generate type="some-custom" src="http://www.w3c.org"> ?
>
> or through the use of some Helper class? as it is in [2] (to Request
> Parameters instead of <map:parameter name="a"
> value="jexl:cocoon.request.a"/>) with HttpContextHelper - wonder if
> there is any equivalent Helper class for Cocoon Sitemap :)
Hi,
[2] injects HTTP request parameters as sitemap parameters: here's why
the usage of HttpContextHelper.
Let's suppose you want to implement a generator able to deal with:
<map:generate type="mycustom">
<map:parameter name="customParam" value="customValue"/>
</map:generate>
Then you need to
1. create class MyCustomGenerator extending AbstractSAXGenerator
2. implement setup() and setConfiguration() - an example implementation
could be
@Override
public void setConfiguration(final Map<String, ? extends Object>
configuration) {
this.setup((Map<String, Object>) configuration);
}
@Override
public void setup(final Map<String, Object> parameters) {
if (parameters == null) {
return;
}
// do something with parameters.get("customParam")
}
3. add a file
src/main/resources/META-INF/cocoon/spring/my-sitemap-components.xml with
the following content:
<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.xsd">
<bean name="generator:mycustom" class="xx.yyy.MyCustomGenerator"
scope="prototype"/>
</beans>
HTH
Regards.
> [1]
> https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XSLTTransformer.java
> [2]
> https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-servlet/src/main/java/org/apache/cocoon/servlet/component/RequestParametersGenerator.java
>
> 2013/2/11 Francesco Chicchiriccò <ilgrosso@apache.org
> <ma...@apache.org>>
>
> On 11/02/2013 12:07, gelo1234 wrote:
>
> Question 1:
> Can we have some example of this one ?
>
> <map:generate type="some-custom">
> <map:parameter name="a" value="1"/>
> <map:parameter name="b" value="2"/>
> </map:generate>
>
> I mean, how to get sitemap parameter value from Java Generator
> code ?
> btw. Request Parameters are obtained by the use of
> HttpContextHelper, is this correct ?
>
>
> No: you can access map:parameter elements from within Java code in
> the same way how this is done in the XSLTTransformer [1]: consider
> that "source" is the only pre-defined parameter you have in any
> pipeline component, mapped to the 'src' XML attribute.
>
>
> Question 2:
> What is the best (optimal) way to include XML content
> generated from
> servlet/controller?
>
> <x:include .... src="servlet:/..."/>
>
> If the servlet is calling a REST controller there are 2
> invocations involved (one to gather data, the other one (with
> e.g. string-template) to actually serialize the data). Is
> there any way that REST controller could serialize the data
> itself ? without invoking another servlet/Page ?
>
>
> Not that I know: anyway I am using similar includes in different
> production environments with high load and I've experienced no
> troubles so far.
>
>
> Question 3:
> If the generator is included in some transformer phase (via
> x:include)
> does it still have access to original Request Parameters when
> invoked with:
>
> <x:include ... src="servlet:/generate?par1=a&par2=b/>
>
> or they are lost (original request params) and substituted by
> new ones (par1, par2 from the line above)?
>
>
> They are lost: you need to explicitly pass them though.
>
> Regards.
>
> [1]
> https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XSLTTransformer.java
>
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: A generator with sitemap parameter in C3
Posted by gelo1234 <ge...@gmail.com>.
Ohh...ok that clarifies a problem a bit. So if the generator declaration
inside sitemap.xmap does NOT have src=".." attribute i won't get this piece
of code [1] executed:
if (this.source != null) {
Object attributesObj = configuration.get("attributes");
if (attributesObj != null && attributesObj instanceof Map) {
...
}
In case of the custom example given before:
<map:generate type="some-custom">
...
</map:generate>
it does NOT have src attribute (Not every generator got src attribute). So
the question is still valid, how to get to those <map:parameter .../>
values in such case ? Simply by adding useless src="" attribute to
<map:generate ..> e.g.
<map:generate type="some-custom" src="http://www.w3c.org"> ?
or through the use of some Helper class? as it is in [2] (to Request
Parameters instead of <map:parameter name="a"
value="jexl:cocoon.request.a"/>) with HttpContextHelper - wonder if there
is any equivalent Helper class for Cocoon Sitemap :)
[1]
https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XSLTTransformer.java
[2]
https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-servlet/src/main/java/org/apache/cocoon/servlet/component/RequestParametersGenerator.java
Greetings,
Greg
2013/2/11 Francesco Chicchiriccò <il...@apache.org>
> On 11/02/2013 12:07, gelo1234 wrote:
>
>> Question 1:
>> Can we have some example of this one ?
>>
>> <map:generate type="some-custom">
>> <map:parameter name="a" value="1"/>
>> <map:parameter name="b" value="2"/>
>> </map:generate>
>>
>> I mean, how to get sitemap parameter value from Java Generator code ?
>> btw. Request Parameters are obtained by the use of HttpContextHelper, is
>> this correct ?
>>
>
> No: you can access map:parameter elements from within Java code in the
> same way how this is done in the XSLTTransformer [1]: consider that
> "source" is the only pre-defined parameter you have in any pipeline
> component, mapped to the 'src' XML attribute.
>
>
> Question 2:
>> What is the best (optimal) way to include XML content generated from
>> servlet/controller?
>>
>> <x:include .... src="servlet:/..."/>
>>
>> If the servlet is calling a REST controller there are 2 invocations
>> involved (one to gather data, the other one (with e.g. string-template) to
>> actually serialize the data). Is there any way that REST controller could
>> serialize the data itself ? without invoking another servlet/Page ?
>>
>
> Not that I know: anyway I am using similar includes in different
> production environments with high load and I've experienced no troubles so
> far.
>
>
> Question 3:
>> If the generator is included in some transformer phase (via x:include)
>> does it still have access to original Request Parameters when invoked
>> with:
>>
>> <x:include ... src="servlet:/generate?par1=a&**par2=b/>
>>
>> or they are lost (original request params) and substituted by new ones
>> (par1, par2 from the line above)?
>>
>
> They are lost: you need to explicitly pass them though.
>
> Regards.
>
> [1] https://svn.apache.org/repos/**asf/cocoon/cocoon3/trunk/**
> cocoon-sax/src/main/java/org/**apache/cocoon/sax/component/**
> XSLTTransformer.java<https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XSLTTransformer.java>
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.**apache.org<us...@cocoon.apache.org>
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
Re: A generator with sitemap parameter in C3
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 11/02/2013 12:07, gelo1234 wrote:
> Question 1:
> Can we have some example of this one ?
>
> <map:generate type="some-custom">
> <map:parameter name="a" value="1"/>
> <map:parameter name="b" value="2"/>
> </map:generate>
>
> I mean, how to get sitemap parameter value from Java Generator code ?
> btw. Request Parameters are obtained by the use of HttpContextHelper,
> is this correct ?
No: you can access map:parameter elements from within Java code in the
same way how this is done in the XSLTTransformer [1]: consider that
"source" is the only pre-defined parameter you have in any pipeline
component, mapped to the 'src' XML attribute.
> Question 2:
> What is the best (optimal) way to include XML content generated from
> servlet/controller?
>
> <x:include .... src="servlet:/..."/>
>
> If the servlet is calling a REST controller there are 2 invocations
> involved (one to gather data, the other one (with e.g.
> string-template) to actually serialize the data). Is there any way
> that REST controller could serialize the data itself ? without
> invoking another servlet/Page ?
Not that I know: anyway I am using similar includes in different
production environments with high load and I've experienced no troubles
so far.
> Question 3:
> If the generator is included in some transformer phase (via x:include)
> does it still have access to original Request Parameters when invoked
> with:
>
> <x:include ... src="servlet:/generate?par1=a&par2=b/>
>
> or they are lost (original request params) and substituted by new ones
> (par1, par2 from the line above)?
They are lost: you need to explicitly pass them though.
Regards.
[1]
https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XSLTTransformer.java
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org