I am throwing out some random ideas to eliminate the need for
code in XSP. XSP's major failing is the <xsp:logic/> construct,
and it's minor failing is the absence of loops and conditionals.
The need for <xsp:logic/> is created by the fact that you cannot
easily loop (unless you made a taglib that lets you perform that).
XSP was a relatively simple solution to what started as a simple
problem. However, the simple solution caused people's minds to
solve new problems with the tool. This is good, but the backlash
is that we now have lost the principle separation of Model and
Controller.
How do we come back and reclaim our right to separate MVC+Mgmt?
One solution is that we implement SLL (does everyone remember
that?) and use SLL for tag libraries. This will allow us to
remove code from our model. What do we do when the logicsheet
is too low level like ESQL? Don't get me wrong, Donald Ball
did a tremendous job with ESQL, but it is still mixing concerns.
To come to a full solution we have to understand the problem
domain. Below is a poll that I would like you to participate
in because it will help solve the answer:
What Problem does Cocoon Solve?
-------------------------------
Rate your response with a number between 1 and 5 where
1 is strong disagreement, 5 is strong agreement, and
3 is ambivolence.
[ ] I like to easily theme my site
[ ] I want to let business analysts write content, but
not screw up business logic or style
[ ] I still want to be in control of the project, but
I want to localize certain information in a few places.
Describing the Model
--------------------
Before we can identify what the model is, we have to identify
what the core consern is. There are many different types of
models in Cocoon, but as concerns the structure of a document,
the core model is the Content. In the webapps I have created,
I have a standard layout that is applied to all forms. The
differences are the instructions at the head of the form,
the prompts, the help text, and the input types. There are
always pages that are pure content, and do not mix business
level information at all.
My personal primary purpose for adopting Cocoon was the promise
of spliting development effort between different roles. The need
presented itself when I had four developers working for me on a
project, and we were working on different parts of the system
with different focuses. One focus was a uniform style. It was
not uncommon for one developer trying to fix a bug have their
code overwritten by someone fixing the formatting in a file.
We had gotten arround this by a crude file locking mechanism
called, "I'm working on file X--touch it and die!".
I did a quick demo of Cocoon (version 1.5.1) to my supervisor,
and they were impressed--but not enough to alter the direction
of the project at that time. With Cocoon 2.0b1 under our belt,
I have convinced our CTO that Cocoon is the way to go for future
development. However, I have struggled with three things:
education, mapping the problem space, and designing with security
integrated.
Education is still a big issue, and eventually I will be able
to write a paper on a practical guide to using Cocoon 2 for
Webapp development. This will alleviate the problem of education
for a number of people. Until that time, I have to explain and
reexplain how and why things are in Cocoon to my codevelopers.
With my last project, I experimented with using business objects--
not quite JavaBeans and not EJB either. My idea was that every
business object that will be represented to a user should have
a standard markup, but also a standard method of accessing the
XML representation. I created an interface that looks like this:
public interface XMLizable {
String toXML() throws SAXException;
void toSAX(ContentHandler handler) throws SAXException;
}
The two methods were for situations where I needed to send the
result over a wire vs. embed in the Cocoon context. What this
enabled was the possibility of creating XML fragments when and
where I needed them. In fact, when I had business objects that
were composed of other business objects, all I had to do is call
the embedded object's toSAX() method and I had perfect results
every time. This is a great timesaver for business object
modeling, and when you need to integrate business objects with
SOAP, JMS, or other distribution mechanism. However the drawback
was that now my business object is the central concern. When
it comes to displaying a business object, this is not always
the case.
The previously mentioned approach requires you to use XSL to
transform the business object into a layout for the screen.
While this may be fine in most cases, this is not fine for
forms where the captions and help text needs to be easily
modified by a business analyst. That is why I started the
ExFormula project--but never had the time to get it off the
ground. Part of the reason is the XForms standard is a little
obtuse in the way it maps markup to form data. Another
drawback is that if for some reason the markup for my business
object changes, my XForm will have to change as well.
With the advent of aggregation, and the ability to embed XML
structures via one of the two aggregation methods, we have some
very powerfull solutions available to us. I personally don't
like the Sitemap aggregation because it takes the construction
of the page out of the Graphic Artist's hands. A templating
approach is much more flexible, and exciting because it allows
the Graphic Artist to use familiar tools, while we create
different pieces of the content in the background.
What are some other solutions that we can throw in the mix here?
S/MIME Cryptographic Signature
