cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <scher...@gmail.com>
Subject Re: sitemap parameter in C3 (was Re: A generator with sitemap parameter in C3)
Date Tue, 19 Feb 2013 10:45:05 GMT
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


Mime
View raw message