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