Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <48093C77.7060100@tt.com.au>
Date: Sat, 19 Apr 2008 10:27:35 +1000
From: Kamal <kbhatt@tt.com.au>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: [2.2] CForms migration
References: <4805A0A1.20505@tt.com.au> <4808B7A3.5080809@tuffmail.com>
In-Reply-To: <4808B7A3.5080809@tuffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Grzegorz Kossakowski wrote:
> 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.
That's fine, I had no expectations of an answer :) I just thought I 
would start a new thread because that one was getting hard to follow.
>
> 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.
OK, I am not too keen on the idea of deprecating map:mount. We have a 
number of sub sitemaps in our projects and as I have already stated I 
would prefer not having to redeploy an application every time I make a 
minor change. I think even some people at work probably think me anal 
about this requirement, but they have not done as many deployments of 
Cocoon as I have and do not know how difficult it is to deploy Cocoon 
(in an environment with a lot of load). Also, we have constructed much 
of a our build processes around this idea that every client will have a 
common set of files (sitemaps, flowscripts, XSPs, etc) and aside from 
some automated tweaking we do to the sitemap (for things like file 
locations and database pools) these files remain the same across 
clients. The map:mount has given us a way to nicely modularise and 
customise our application. In actual fact, I was leaning towards this 
option as it gave me something I didn't have in the past - zero Cocoon 
redeployments for setting up new clients. Previously, we would have to 
change mount tables and datasources to add a new clients, but thanks to 
Hibernate's configuration options (yes, I have finally decided to bit 
the bullet and use Hibernate :) ) and some mount table trickery I should 
be able to deploy a new client with very little overhead.

If SSF allows me to do this (or you can suggest to me a way of 
fulfilling my requirements with SSF), I will happily use it, otherwise, 
I would actually prefer using potentially deprecated functionality.

I might add, that the Lenya crowd have setup this concept called 
Usecases which (in the past) have relied on sitemap mounts. They may 
have changed it (there was talk, I think, of them using actions or some 
other sitemap component to do this), but many people (including 
ourselves) are probably using usecases the old fashion way.
>> 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.
After all the pain the SQLTransformer has caused me, I think I will 
steer away from legacy functionality where possible.
>> 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>
>
I actually played with this, and I think I got no results from it 
(though, I don't think I had the "<entry key="style" 
value-ref="org.apache.cocoon.samples.style.default.servlet"/>"). What I 
found was that anything I did here was wiped away by the RCL.
> 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.
Thanks.
>
>> * 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?
Nevermind I have turned off the idea.
>
>> * 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?
If I open browser tabs (even sometimes two windows) and I run our CForms 
application from both, then all sorts of weirdness ensues when I save. 
Changes from one window will automagically migrate to the other window, 
and it is just a bit of a disaster. The pervading theory right now, is 
this is because of Cookie based session management. Therefore, the 
solution is to use URL rewriting (right?).
>
>> * 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.
OK, so it sound completely undocumented. That's fine. I could probably 
get GoogleMaps/YahooMaps functionaltiy using some clever use of form 
styling if I really needed it.
>
>> * 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?
<sigh> I guess I will have to.
>
>> * 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
Thanks, I actually found this afterwards.


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