cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hugh Sparks" <h...@csparks.com>
Subject Re: Cocoon 2.2.1 - Context path at root doesn't work
Date Sun, 27 Jul 2008 19:05:07 GMT
> Hugh suffers regression:
> [...wants to allow the SitemapServlet context path
> to point to the webapp root directory for some but
> not all webapps...]

>> Grzegorz Kossakowski writes:
>> Is there anything that stops you from using one block for
>> migration? I guess your life should be  much easier in that
>> case.

It is not entirely an issue of migration. I think there are
other good reasons to allow some webapps easy access to files
in the root directory.

>> [...]
>> You may convince us that we need to support blockless style
>> of using 2.2 by pointing out some serious limitation that
>> block architecture introduces. At this moment, I fail to
>> see any.

Let me try.

First of all, the block architecture and the use of Spring is 
a fantastic development: It is now possible to create servlets 
using Cocoon that deploy and behave like java servlets. And with
Spring, they can be created and interconnected entirely by editing 
configuration files. Cocoon has truly become "Web glue for web 
applications." This is a great thing! In my opinion there are
no "serious limitations" introduced by the block architecture.
Only advantages!

But I feel that a distinction should be made between software 
and content: It is a fine thing to assemble functional 
components from a network of servlets. I have several
applications very well suited to this pattern. Even some
content naturally belongs in the "instance variables" of servlets.

But packing <all> content into blocks is another matter: One of
the greatest contributors to software productivity in my opinion 
is the use of interactive development environments. Being able 
to navigate into the web server's root directory and edit html 
with only a browser refresh needed to see the changes is very 
powerful. It is simply not reasonable to restart the web 
server when simple "eye-candy" content is modified. Not only
does it take time, but it disrupts the transactions of other
users who access the site. I realise we have the RCL, but
what happens when we deploy blocks with other servlet
containers? 

Web developers expect to have instant gratification when it
comes to changing simple content and would have serious
reservations about adopting a tool that prevents this sort
of experience. And cocoon - for its entire history until
a few days ago - did support this interactive style as well
as the blocks style. Why not preserve both capabilities?
Particularly since it makes cocoon far more accessible to
outsiders.

As an example: I configure tomcat so the cocoon webapp is 
a symbolic link to the apache server root directory. The 
WEB_INF and META_INF for cocoon are right at the top level of 
my website. Apache recognizes special urls and uses a proxy 
connection to send these requests to Tomcat and on to Cocoon.
The top level sitemap.xmap is also at the apache root directory.

What is gained by this?

I can edit any content - html, css, sitemaps, and flowscript 
without disturbing any of the running software or (in most
cases,) anyone accessing the site.  Most importantly, I can
see the effects of these changes by simply refreshing the
browser page.

The content at the webserver root can be mixed:

Apache handles requests it does best with its vast
assortment of modules and languages while cocoon handles content
it does best. And these domains are not independent: I have
applications where the same content may be accessed by both
apache and cocoon. A simple example is the set of css
stylesheets.

So what I'd like to preserve is a hybrid environment: 
It is a valuable innovation to have blocks as independent
servlets configured by Spring. But I feel that putting all
content into blocks is a barrier to developer productivity
and shuts out the ability of some-but-not-all web tools to
share content with cocoon.

I'd like to mention another advantage of interactive 
programming environments: The preservation of state:

It takes very little time to update a block with maven. 
The same is true for recompiling a C source code file in a 
traditional application. The real cost is re-establishing the 
state of a complex network of interacting components. In many 
cases, this takes far more time than rebuilding the entire 
site. But with interactive tools (think Smalltalk) you 
can explore the state of the running program, recompile a 
particular method and continue running. True, you may want to 
restart the whole thing to verify that the changes are 
consistent, but much of the time, particularly when only 
static content is altered, nothing has to be disturbed. 

This is one of the reasons why scripting language users
report higher levels of productivity than "compiler
language" users. I'd like to see cocoon evolve as a
"never shut it down" network of components, just as
we expect from a web server O.S. or distributed set of
cooperating hosts.

This seems like a lot to gain at the cost of allowing a 
context-path to be "/" in the SitemapServlet bean.

To summarize my position: I am not advocating a 
"blockless style" of using cocoon. I'm not a "block skeptic"
or a "Spring skeptic." But I believe there is a place for
allowing content outside of jars in the webapp root directory
and this should probably be the default situation when no
protocol is specified. This allows cocoon applications to work
and play well with other established web development tools,
and makes it far easier for developers to see the consequences
of trivial changes when editing content.

Thanks for listening. -  Perhaps I'm the only cocoon user who
thinks this way and I will have to mend my ways.

-Hugh Sparks, hugh@csparks.com





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


Mime
View raw message