cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: [2.2] CForms migration
Date Fri, 18 Apr 2008 15:00:51 GMT
Kamal Bhatt pisze:
> Hi,
> I asked some of these questions previously, but I got no answers, so I 
> thought I would try again and ask some more questions:

Hi Kamal. I'm sorry for lag in responding to your e-mails but I have some personal issues
to cope 
with. That means I won't be responding regularly in upcoming weeks, unfortunately.

> * It seems to me there are a number of approaches for placing your 
> sitemap in an arbitary location on the file system:
> 
> 1. You could use a mount in the block, such as this:
>  <map:match pattern="*/**">
>     <map:mount check-reload="true" reload-method="synchron" 
> src="file:///test/{1}/sitemap.xmap" uri-prefix="" />
> </map:match>
> This what I meant about sitemap redirections.

We are actively discussing idea of deprecating map:mount functionality but no decisions has
been 
made up to now. Anyway, it's quite common opinion that Servlet Service Framework is better
approach 
for achieving modular design in Cocoon-based applications thus map:mount is not advised technique

anymore.

> 2. You could use the RCL method and specify the property (though I 
> haven't got this to work in the packaged war, I will have a look at it 
> later)

It's really not RCL method. It works similar to the method explained in 4 point.

> 3. You could use Cocoon in classic mode and use the xconf

This is considered as legacy method so I would say that if don't need it don't invest your
time into 
this approach.

> 4. You could use the block servlet bean definition method:
> 
> <bean name="org.apache.cocoon-welcome.block" 
> class="org.apache.cocoon.sitemap.SitemapServlet">
>   <servlet:init-params>
>     <entry key="sitemap-path" value="file:///path/to/sitemap.xmap"/>
>   </servlet:init-params>
>   <servlet:context mount-path="/" 
> context-path="blockcontext:/cocoon-welcome/">
>     <servlet:connections>
>       <entry key="style" 
> value-ref="org.apache.cocoon.samples.style.default.servlet"/>
>     </servlet:connections>
>   </servlet:context>
> </bean>
> 
> 
> So which would be the best way?

You should add this one to your list:
<bean name="org.apache.cocoon-welcome.block" class="org.apache.cocoon.sitemap.SitemapServlet">
   <servlet:context mount-path="/" context-path="file:///path/to/">
     <servlet:connections>
       <entry key="style" value-ref="org.apache.cocoon.samples.style.default.servlet"/>
     </servlet:connections>
   </servlet:context>
</bean>

Where file:///path/to/ points to the directory where sitemap.xmap can be found. This method
sets 
whole context to your own location so all relative paths are resolved against that location.
I'm not 
sure about init-param method, though.

I said earlier that RCL does something similar to what is being discussed here. If you set
following 
property:
org.apache.cocoon-welcome.block/contextPath=file:///path/to/

You achieve exactly the same as you would configure the servlet bean the same way as suggested

above. Actually, the general syntax is:

   [BEAN_NAME]/[PROPERTY_NAME]=[PROPERTY_VALUE]

And it works for any beans you like. The idea behind this mechanism is that you are able to
tweak 
beans' configuration that are packaged in JAR files without touching JAR files itself.

I would say that modifying contextPath property of SitemapServlet bean is the best option
here.

> * Just wondering when we are likely to see the XSP block made available 
> outside of the trunk. I don't mind missing out SOAP capability (not 
> using it), is there a maven dependency I can use to get XSPs now?

You can always checkout cocoon-xsp-impl[1] module from trunk, build it using Maven so it's
being 
added to your local repository. Since then, you can use this module as your dependency.

> * In a development environment, you can specify a folder that Cocoon 
> will look at to get its class files. Is there a way of using this 
> functionality in production without an overhead?

I'm still not sure if it's a good idea, at all. Could others comment?

> * I am having session management issues with CForms and my application, 
> so I need to use URL rewriting. Is there a way of doing this with 
> Cocoon/CForms? Is it still an issue with 2.2?

Could you elaborate a little bit?

> * One day I was looking at the 2.1.10 code, and I noticed a GoogleMaps 
> widget. Is there any instruction on its use? Is it worth using?

AFAIR, it's been created as GSoC project and was working fine when I was looking at it a few
months 
ago. Not sure if it still works.

> * I need to update our woefully bad image upload. One of the issues we 
> had was that we could n't validate the filename with a regex. Has this 
> been fixed or is there a workaround?

Can't you write your own validator?

> * I would like to use the SQL transformer, but I see nothing about 
> registering connection pools with Cocoon (as we used to have to do in 
> 2.1). Are the connection pools mentioned in 
> http://cocoon.apache.org/2.2/blocks/databases/1.0/apidocs/index.html 
> referring to connection pools registered with the application servers? 
> Are there examples somewhere?

What about:
http://cocoon.apache.org/2.2/blocks/databases-bridge/1.0/1424_1_1.html
http://cocoon.apache.org/2.2/blocks/databases/1.0/1409_1_1.html

[1] http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-xsp/cocoon-xsp-impl/

-- 
Grzegorz Kossakowski

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


Mime
View raw message