Hi,
Can you please confirm that map:mount will make it into the next version
of Cocoon? This will greatly influence whether we migrate to Cocoon 2.2
or not.
Cheers.
Grzegorz Kossakowski wrote:
Kamal pisze:
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).
I see your arguments. In a fact, the ability of sitemap (and other
resources) reloading mechanism is not bound to map:mount functionality
so I don't see much a problem here.
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.
Just out of curiosity: have you developed your own build process becuase:
a) Cocoon failed to provide flexible enough default development
skeleton that you could use
or rather
b) your requirements were so specific that you would have to develop
it anyway?
I ask because one of the identified weaknesses of C2.1 was poor
support for real development process. There was nothing standard and
flexible enough that anyone could take and only customize to her needs
but still retaining base in common. One of the goals of C2.2 is to
change that hence switch to Maven 2, archetypes and real blocks
implementation.
The map:mount has given us a way to nicely modularise and customise
our application.
I think that blocks+SSF give you even more flexibility in this
regards. Actually, there are both invented exactly for achieving nice
modularization of Cocoon-based applications.
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.
If you tell SitemapServlet (by chaning context-path property) to look
for the resources _outside_ the block JAR you are achieving fairly the
same.
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.
We imagined (and it's already working) that you just create new
application as a new block, compile and package it into JAR. Then you
just drop the JAR containing block into WEB-INF/lib, restart and you
are done. Your application will get mounted/discovered without any
extra steps. Since block's are meant to be mostly self-contained you
can configure DataSources (as Spring beans) inside block and Cocoon
(along with Spring) will pick up your configuration and will setup
everything as needed.
As you see, deployment of a new application involves only dropping the
JAR and restarting Servlet container. I think there is a little that
could be easier, don't you think?
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.
SSF is only about mounting (if we limit ourselves to your situation of
course); resource reloading is out of scope of this framework but
you've been already explained how to achieve the same.
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.
Huh, it looks like I'll need to take a look at Lenya's architecture
and maybe help them to migrate, too. :-)
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.
Ah right. If you start block using RCL then it may be true that it
overrides your settings. I'll need to have a look at this in order to
see how to avoid this overriding.
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?).
But Form's state is bound to Flowscript continuation that is
identified by has in URL already. AFAIK, continuation's ID are not put
into cookies so nothing could be messed up. I fail to see any reason
for the odd behavior you describe here.
Can't you write your own validator?
<sigh> I guess I will have to.
Kamal, but it's damn easy to write a such! :-)
--
Kamal Bhatt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
