Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Thu, 21 Jun 2001 15:25:26 -0400 (EDT)
From: Donald Ball <balld@webslingerZ.com>
To: "cocoon-dev@xml.apache.org" <cocoon-dev@xml.apache.org>
Subject: Re: [RT] Alternative Solution to XSP
In-Reply-To: <3B324086.513A7DE7@apache.org>
Message-ID: <Pine.LNX.4.33L2.0106211455590.1732-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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.

some other failings include:

* it's difficult and buggy for the xsp engine to track and apply dependent
logicsheets

* it's difficult to modularize logic into functions. if you do it in java,
you have to track and pass all necessary internal variables yourself. if
you do it in xslt, parameter passing is a real bitch, and you have to
tread carefully to ensure your locally declared variables don't end up
conflicting with someone else's.

* debugging xsp pages can be very painful. debugging xsp logicsheets can
be even more painful.

> 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.

well, thank you, but i don't quite see where you're getting at with mixing
concerns. could you elaborate?

> 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.

[3] I like to easily theme my site
[4] 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.

> 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;
> }

if i might comment for a moment here - just about the nicest thing about
writing xsp pages is that the api for creating xml is so easy. working
with DOM is horrid, and SAX, while great for content receivers, is imho a
pretty bad api for content providers.

> 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.

the sitemap aggregation features, as they exist now, also make it
difficult to impossible to create a more complex skeletal xml structure to
include your content in. for instance, i found recently that i wanted to
do this:

<root>
  <meta>
    ... included content ...
  </meta>
  <page>
    <body>
      ... included content ...
    </body>
  </page>
</root>

without using multiple sitemap pipelines, i couldn't find any way to do
this. so i'm wondering if an alternate approach might be to construct the
xml skeleton right there in the sitemap if we wanted to:

<map:match pattern="event/add">
  <map:generate type="inline">
    <root>
      <meta>
        <map:include src="plain/meta"/>
      </meta>
      <page>
        <body>
          <map:include src="plain/form"/>
        </body>
      </page>
    </root>
  </map:generate>
</map:match>

of course, an alternative is to do the including in an xsp page, but then
the included content has to be accessible not via a sitemap component, but
rather via an xsp logicsheet or sax library method.

another alternative would be to consider implementing a simplified dynamic
page language. instead of allowing arbitrary code to be put in documents,
we could mandate that only dynamic tags associated with registered
'logicsheets' would be allowed. then i could write my example above like
so:

<root>
  <meta>
    <sitemap:include src="plain/meta"/>
  </meta>
  <page>
    <body>
      <formgen:generate table="event_table" schema="context://WEB-INF/etc/tables.xml"/>
    </body>
  </page>
</root>

instead of using xslt passes to transform this document into java source
code and then compiling it, we could use the axkit paradigm and just map
certain sax events to java methods:

public void startElement(...) {
  if (namespace URI (NOT PREFIX!!!) is registered) {
    namespaceHandler.invoke(element name, attributes, this);
  } else {
    this.underlyingContentHandler.startElement(...);
  }
}

thoughts, comments?

- donald


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