Return-Path: 
 <cocoon-dev-return-14549-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 38326 invoked by uid 500); 23 Jun 2001 08:04:42 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 38313 invoked from network); 23 Jun 2001 08:04:42 -0000
Date: Sat, 23 Jun 2001 09:40:06 +0200 (CEST)
From: giacomo <giacomo@apache.org>
X-X-Sender: <giacomo@lap1.otego.com>
To: "cocoon-dev@xml.apache.org" <cocoon-dev@xml.apache.org>
Subject: Re: [RT] Alternative Solution to XSP
In-Reply-To: <Pine.LNX.4.33L2.0106222257230.7219-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.31.0106230937280.15680-100000@lap1.otego.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

On Fri, 22 Jun 2001, Donald Ball wrote:

> On Fri, 22 Jun 2001, giacomo wrote:
>
> > > 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.
>
> and that might be an okay technique, but i dunno, i think it smacks of
> Hammer Syndrome (when all you have is a hammer...) now we're talking about
> preprocessing xsp logicsheets with other stylesheets. this system is going
> to be messy to write and debug - both the engine and the sheets. witness
> the current xsp logicsheet application bugs that no one's tracked down
> yet.
>
> > 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.
>
> sounds like an interesting technique. how do you insert the business
> objects into the cocoon sax pipeline? e.g. from an xsp page, a generator,
> a transformer, what?

>From an XSP page:

  <page>
    <xsp:logic>
      Unmarshaller.unmarshal(this.contentHandler, businessObj);
    </xsp:logic>
  </page>

Giacomo


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