On 12/01/2012 01:15 AM, gelo1234 wrote:
>
> Hello,
>
> I was trying to find some samples from current C3.0 implementation to
> know more
> about C3.0 but some information is absent.
>
> Perhaps someone here could answer that:
>
> In some old Cocoon release (2.x) there was a possibility to define
> multipart generators, something like:
>
> <map:match="xxx">
>   <map:aggregate element="Page">
>       <map:part
> src="dir/file1.xml"/>                                                   
> a)
>       <map:part
> src="dir/file2.xml"/>                                                   
> b)
>       <map:part src="cocoon://call_some_match_generating_XML"/>     c)
>       <map:part
> src="http://somedomain.com/file3.xml"/>                     d)
>   </map:aggregate>
>   ...
> </map:match>
>
> 1. Is it still possible with C3.0 ? Especially c) option to call some
> sitemapservlet ?

In general the aggregate has not been implemented in c3. However you can
do the same with a xml file for you define the includes and the
transform it with the include transformer. Regarding c) that is since
2.2 servlet: you can find some docs around it.

>
> 2. If i implement my own SAXGenerator can I use it as c) option here ?
> (How?):
> <map:part type="my-custom"/> ??

not sure what you mean but I think the include example in the c3 samples
will show you how to include.
>
> 3. Is d) valid ?

well that depend on so many different things. If you refer "as is" yes
as construct. Actually all components work against urls. If you refer
whether the outcome is valid xml - you can make sure with the neko html
generator.
>
> 4. Can i pass additional parameters to c)
> like: <map:part
> src="cocoon://call_some_match_generating_XML?arg=1&arg=2"/>
> Are request parameters INHERITED from calling pipeline match ?
>

hmm they are normal urls. Query parameter are fully supported. Not sure
about the second part of the point but you can use {map:1} to access the
fist matching group of your match.

> 5. Can we use simple Java Controller (but NOT rest-controller?) and
> still have access
> to QueryString Parameters/HTTP Request object within such sitemapservlet ?

I am currently working on a project that is based on JSF. You can make
cocoon3 work along with anything it always depends on what benefit you
want to get from cocoon or another part. However as soon my project ends
I will look into using JSF in cocoon since I have to admit the form
handling and some contract/widget are really nice and easy to use.
However for form handling see the cocoon-wicket integration where you
integrate wicket into cocoon or vice versa depending on the main usage.
I you have many forms and little content you would go for the second option.

However there is no support for other controller then REST to access the
sitemap parameter.

> What should such a Java class extend or implement? and how does the spring
> bean/config for that Controller may look like ?

Not sure.

> Will it be still Controller or SAXGenerator ?


Currently you have either a normal generator/reader/... but you can
implement a sitemap Starter and do as you please. However see the wicket
integration on how to handle other controller and cocoon side by side.
>
> 6. What is the main difference between include and xinclude (apart
> from the fact the
> first is cocoon spec? impl while the other is w3c spec impl by cocoon?)
> Isn't include cacheable either ?
> Can i include/xinclude external src data e.g.
> src="http://somedomain.com/file.xml"; ?

Please see the docs and the mailing archive it is really good covered.

>
> 5. Can I call other REST Controller from REST Controller ?

As in URL calls, yeah why not.

>
> 6. Do XSLT transformations by default have access to ALL QueryString
> params
> with
> <xsl:param name="arg1"/>
> <xsl:param name="arg2"/>
> ...
> <xsl:param name="argn"/>
>
> without explicitly defining each one in the pipeline as some
> {jexl:cocoon.request.param1}?
> as map parameters for the XSL transformer ?

Not sure about it, in 2.x there where a flag for it AFAIR and if so it
would be easy to migrate to c3.

HTH

> Thank you for your time and answers.
>
> We are still hesitating whether to upgrade to Cocoon3.0/Spring or Java
> EE stack.

It is no either or anymore since you can use c3 in a java based pipeline
for certain processes.

salu2

>
> Greetings,
> -Greg
>


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

Reply via email to