RE: sitemap parameter in C3 (was Re: A generator with sitemap parameter in C3)

[Robby Pelssers]

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:scher...@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) 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 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 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 extends PipelineComponent  */ public class 
LinkExtractorPipeline extends
NonCachingPipeline {

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
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 getOutLinks() {
return linkExtractorTransformer.getOutLinks();
}


Then I call it from my java code like

LinkExtractorPipeline pipeline =
new LinkExtractorPipeline();
OutputStream output = new BufferedOutputStream(new 
ByteArrayOutputStream());
// pass parameter to the pipeline
Map parameters = new HashMap();
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:


   -> we do not have the concept of matcher in the 
java pipeline



  


Now since we have the config done in the same class we could do something like 
 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 
s

Re: sitemap parameter in C3 (was Re: A generator with sitemap parameter in C3)

[Thorsten Scherler]

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) 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 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 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 extends PipelineComponent
 */
public class LinkExtractorPipeline extends
NonCachingPipeline {

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
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 getOutLinks() {
return linkExtractorTransformer.getOutLinks();
}


Then I call it from my java code like

LinkExtractorPipeline pipeline =
new LinkExtractorPipeline();
OutputStream output = new BufferedOutputStream(new
ByteArrayOutputStream());
// pass parameter to the pipeline
Map parameters = new HashMap();
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:


   -> we do not have the concept of matcher
in the java pipeline



  


Now since we have the config done in the same class we could do
something like  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 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 

Re: sitemap parameter in C3 (was Re: A generator with sitemap parameter in C3)

[gelo1234]

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 

> 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) 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 
> codeBusters S.L. - web based systems
> 
>
> http://www.codebusters.es/
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> For additional commands, e-mail: users-h...@cocoon.apache.org
>
>

Re: sitemap parameter in C3 (was Re: A generator with sitemap parameter in C3)

[Francesco Chicchiriccò]

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) 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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

sitemap parameter in C3 (was Re: A generator with sitemap parameter in C3)

[Thorsten Scherler]

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) 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 
codeBusters S.L. - web based systems


http://www.codebusters.es/


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: A generator with sitemap parameter in C3

[Francesco Chicchiriccò]

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) 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ò >


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:


  ...


it does NOT have src attribute (Not every generator got src
attribute). So the question is still valid, how to get to those
 values in such case ? Simply by adding
useless src="" attribute to  e.g.

http://www.w3c.org";> ?

or through the use of some Helper class? as it is in [2] (to
Request Parameters instead of ) 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:


  


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 configuration) {
this.setup((Map) configuration);
}

@Override
public void setup(final Map 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:

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";>

  



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ò mailto:ilgro...@apache.org>>

On 11/02/2013 12:07, gelo1234 wrote:

Question 1:
Can we have some example of this one ?


   
   


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?



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:

https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/ap

Re: A generator with sitemap parameter in C3

[gelo1234]

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) 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ò 

>  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:
>
> 
>   ...
>  
>
>  it does NOT have src attribute (Not every generator got src attribute).
> So the question is still valid, how to get to those 
> values in such case ? Simply by adding useless src="" attribute to
>  e.g.
>
>  http://www.w3c.org";> ?
>
>  or through the use of some Helper class? as it is in [2] (to Request
> Parameters instead of  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:
>
> 
>   
> 
>
> 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
> configuration) {
> this.setup((Map) configuration);
> }
>
> @Override
> public void setup(final Map 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:
>
>  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";>
>
>scope="prototype"/>
>
> 
>
> 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ò 
>
>> On 11/02/2013 12:07, gelo1234 wrote:
>>
>>> Question 1:
>>> Can we have some example of this one ?
>>>
>>> 
>>>
>>>
>>> 
>>>
>>> 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?
>>>
>>> 
>>>
>>> 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:
>>>
>>> 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

[Francesco Chicchiriccò]

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:


  ...


it does NOT have src attribute (Not every generator got src 
attribute). So the question is still valid, how to get to those 
 values in such case ? Simply by adding useless 
src="" attribute to  e.g.


http://www.w3c.org";> ?

or through the use of some Helper class? as it is in [2] (to Request 
Parameters instead of 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:


  


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 
configuration) {

this.setup((Map) configuration);
}

@Override
public void setup(final Map 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:


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";>

  scope="prototype"/>




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ò >


On 11/02/2013 12:07, gelo1234 wrote:

Question 1:
Can we have some example of this one ?


   
   


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?



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:

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

[gelo1234]

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:


  ...


it does NOT have src attribute (Not every generator got src attribute). So
the question is still valid, how to get to those 
values in such case ? Simply by adding useless src="" attribute to
 e.g.

http://www.w3c.org";> ?

or through the use of some Helper class? as it is in [2] (to Request
Parameters instead of ) 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ò 

> On 11/02/2013 12:07, gelo1234 wrote:
>
>> Question 1:
>> Can we have some example of this one ?
>>
>> 
>>
>>
>> 
>>
>> 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?
>>
>> 
>>
>> 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:
>>
>> 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-h...@cocoon.apache.org
>
>

Re: A generator with sitemap parameter in C3

[Francesco Chicchiriccò]

On 11/02/2013 12:07, gelo1234 wrote:

Question 1:
Can we have some example of this one ?


   
   


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?



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:




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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org