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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
