On Thu, 21 Jun 2001, Berin Loritsch wrote:
> 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.
My stand point here is that XSP isn't made to have these looping
constructs or contitionals. It is used to present content. Clearly
dynamic tags should allow the content supplier to state what he like to
present but the logic behind those tags should de the business logic
soley.
>
> 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.
This is why I have proposed to extend the XSP engine to allow to apply a
XSLT stylesheet to a logicsheet befor it is entered into the XSP engine
for use. This would make it fexible enough to have a filter for invalid
stuff at a granularity of an attribute. Or to make higher level markup
languages like SLL which gets transformed into a usual XSP logicsheet.
> 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.
>
> [4] I like to easily theme my site
> [5] I want to let business analysts write content, but
> not screw up business logic or style
> [5] 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.
>
<snip/>
>
> 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.
Today Cocoon 2 can touch almost every problem space. Publishing, web
apps, messaging systems, dispatching system, and may more. It can serve
almost any client like WAP, browsers, SOAP and even CORBA.
> 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.
We've also thought alot about it in our company. We came to the solution
that you need better ways of describing business objects and services
that using plain Java. For that we've developed a toolkit that is able
to generate your business objects out of a XML Schema definition. For
now we have helper classes that let you easily marshal and unmarshal
these objects from and to streams (Parser/ContentHandler,
InputStreams/OutputStream) with Avalon components of course. Future
improvements could be that you can generate a specific ContentHandler
for unmarshalling (possibly chaining several together) or generate the
Java code of what you've called the XMLizable interface because you have
all the information to do so defined in the XSchema.
We also thought of (partly) using WSDL to describe the logic part of
business objects/applications. I think even if you don't send messages
over the wire it is a good standard to define logic in terms of methods
and their required parameters and output types. This part of that
toolkit could generate interfaces from the WSDL description which a
normal skilled developer can implement as a concrete class. Using WSDL
the tool kit could be enabled to generate XSP logicsheets which
implement the services described by use of the generated interface. This
would have the benefit of a strongly typed taglib system which XSP
logicsheets developed by hand can do but is painfull and a mess to
maintain (MVHO) on release changes.
The toolkit it's only able to generate business objects from a subset of
XSchema definitions so far but it suites my needs for now. Today I use
that toolkit to enable a C2 app to talk to browsers as well as to SOAP
client offering the same services using the same logic pieces. It uses
CORBA services in the backend which also get converted/deconverted from
and to those business objects to and out of the usual Structs CORBA idls
definitions generate. The system uses specific adapters to convert a
request into a general request business object. Every
logic/service/manipulations are made on these business objects. The
steps are chained using Actions. When it comes to need to serilaize
objects onto a SAX Stream its a matter of getting the serializer from
the ComponentManager and send it down the pipeline where it is
transformed depending on the original requesting client type. The
serializers don't need to use reflections because they business objects
can tell the serializers what to do.
Giacomo
> 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
