Michael Hartle wrote:
>
> Get the CMS to copy the needed content to Cocoon2-controlled paths
> and files, finally process the resulting valid XML documents of business
> analysts
> via Cocoon2, transform the documents and by this seperately add business
> code
> and style.
>
> What am I missing that might screw such a setup ?
Data driven sites. There has to be a way for business anylists to alter
things like "What is a prompt called?", "What are the instructions for this
form", and "What is the text of the help for this entry?" without screwing
up standard layout conventions as well as how the information is pulled
from the persistence layer.
The real danger is when the Business Analyst *thinks* they know something
about the system. In smaller companies like mine, we all know what is going
on with a project. If he (thinking he is helping) adjusts a SQL statement
that is embedded, the app is broken. The extent of the fix may be easy to
locate or difficult depending on what has changed (I've seen a wrong sort order
screw up expected results--esp. in complex joins).
What I am saying is typically what happens with XSP in general is that logic
creeps into the page even if it is for something simple. As soon as that
happens, it is not suitable for a Business Analyst. Besides Softquad XMetaL
is not that good with namespaces--esp. when you are creating new documents.
We need to come up with something scalable, that works for every company
from open source project to fortune 500.
S/MIME Cryptographic Signature
