You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Kamal Bhatt <kb...@tt.com.au> on 2008/04/16 08:45:53 UTC
[2.2] CForms migration
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:
* 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.
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)
3. You could use Cocoon in classic mode and use the xconf
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?
* 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?
* 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 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?
* 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?
* 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?
* 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?
Any help would be appreciated.
Thanks.
--
Kamal Bhatt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms migration
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Kamal Bhatt wrote:
> 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.
Kamal, we are only thinking about deprecating map:mount. That means,
even if we decide to deprecate map:mount in C2.2 it will be supported
for at least one year (more likely: two years) in 2.2 line. I'm not sure
what's our removal policy of deprecated functionality but I guess it
will be possible to remove it in 3.0 version that is not even planned now.
I think it's totally safe to use map:mount but I must admit I'm little
bit sad because it goes somehow against directions C2.2 has taken.
Anyway, I've warned and now my work is finished.
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms migration
Posted by Kamal Bhatt <kb...@tt.com.au>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms migration
Posted by Kamal Bhatt <kb...@tt.com.au>.
Grzegorz Kossakowski wrote:
>
> 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.
Bit of both. As I may have said previously, we have a set of files
(XSPs, XSLTs, sitemaps, etc) that are common to all our clients, we then
overlay client specific files. The client specific files may override
the base set of files (and do). I don't see the process you are talking
about as facilitating this functionality. Regardless, we barely have
enough time to migrate to 2.2, so I cannot imagine changing the build
process as well.
>
>> 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?
Actually, what you describe isn't easy in our case. I would prefer
Cocoon in its own environment, but it isn't. It is with a bunch of
significant applications. Deploying Cocoon with all its dependencies is
going to bring down most application servers eventually. This is
something I wish to mitigate.
>
>> 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.
>
>
>> 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.
I thought so too, but somehow it caused this sort of behaviour.
>
>>>
>>> Can't you write your own validator?
>> <sigh> I guess I will have to.
>
> Kamal, but it's damn easy to write a such! :-)
It probably is now that everything is using maven :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms migration
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms migration
Posted by Kamal <kb...@tt.com.au>.
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
Re: [2.2] CForms migration
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Is this out of date?
Posted by Kamal Bhatt <kb...@tt.com.au>.
On this page:
http://cocoon.apache.org/2.2/1362_1_1.html
It says the following:
You can mount your block at the root level in the application URI space,
so that instead of using (for example) the URI
http://localhost:8888/myBlock/foo/bar to request a page, you would
request it at http://localhost:8888/foo/bar.
To do this, edit
myBlock/src/main/resources/META-INF/cocoon/spring/block.xml , and change
the element
<property name="mountPath" value="/myBlock1"/>
to
<property name="mountPath" value=""/>
and then run mvn:install.
/I don't see this file anywhere. Should this page be updated?/
--
Kamal Bhatt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms migration
Posted by Kamal Bhatt <kb...@tt.com.au>.
Hi,
I have been trying to find out what effect the different scopes have for
beans specified in a Spring bean definition files. For example, if you
specify that a bean is at the session level, what impact would that have
for Flowscripts and (in particular) CForms. What should be the scope of
beans that represent persistent objects, or should we not use session
objects and just create the objects as we need them (which is what we
did when we used flowscript in Cocoon 2.1)?
Cheers.
--
Kamal Bhatt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org