With the view related security issues that have arrisen, we have to look at some realities of development and deployment. They have some potentially conflicting concerns.
Developer Concern #1:
A developer needs to have all the information available to them to allow them to debug and correct mistakes. Part of that also include needing development time functions to clear the cache, or have the system reload from scratch. Not to mention the developer needs to be able to look at the various log messages and runtime internals as best as is possible.
Deployment Concern #1:
Deployment must have the most stable and predictable environment as possible. That means as long as the client (the site's user in this case) can only interact with the server in a very limited way. In no way should a client be able to do all the things listed for a developer to do.
Developer Concern #2:
Developers need flexibility. They don't want to be locked into too small a box. They need to try different approaches and compare more than one similar way of doing things.
Deployment Concern #2:
Deployment needs stability (just like concern 1). Nothing can can change. Once its deployed its deployed. The only things that should be dynamically happening are data releated, and already well understood.
What does this mean for Cocoon?
#1) Views expose necessary functionality for developers, but alot of
potential abuse for deployment.#2) XSP is a great tool for development, but nothing should be dynamic
in deployment--esp. logic.What do we do about it?
There are a couple paths to go down. The first path is generative programming. IOW, Cocoon is just another way of generating servlets that are powerful and collaborative. No logic is dynamic when the site is deployed, but it is during development. The second path is to use aspects (not necessarily AspectJ, but using the same principles). Developer concerns are applied during development--but removed for deployment.
Both require work, and probably shouldn't be started before a 2.1 release. In the past I favored the first option. I mean once a site is generated its generated. The problem is debugging. What happens when the generation process introduces errors or artifacts that were not there during development? It's not pretty.
I favor the aspect oriented approach. This would require the ability to abstract certain functionality for Cocoon into aspects. Things like clearing the chache, forcing refresh, or selecting view. The Cocoon system needs to know how or when to apply these concerns. These concerns should also be placed in an external JAR. When the jar is removed, the concerns are never applied.
