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! :-)
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
