From neeme@one.lv  Tue Jun  6 17:41:39 2000
Return-Path: <neeme@one.lv>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 28451 invoked from network); 6 Jun 2000 17:41:39 -0000
Received: from the.one.lv (159.148.169.70)
  by locus.apache.org with SMTP; 6 Jun 2000 17:41:39 -0000
content-class: urn:content-classes:message
From: "Neeme Praks" <neeme@one.lv>
To: <cocoon-dev@xml.apache.org>
Subject: RE: XSP again
Date: Tue, 6 Jun 2000 19:42:54 +0200
Message-ID: <2ECFE9456D0F6A4FA77B38C25AAE2309027E04@the.one.lv>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.4208.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: XSP again
Thread-Index: Ab/Pnq0iBKCqrqbHRu+rx6aYz4JjEQAP4hbg
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N


> -----Original Message-----
> From: Ricardo Rocha [mailto:ricardo@apache.org]
> Sent: Tuesday, June 06, 2000 11:58 AM
>=20
> If one wants to write XSP pages that are portable across XML=20
> API's, one
> should  encapsulate access to "core" objects by means of logicsheets
> and/or
> method calls (as opposed to inlined, "raw" code). If one doesn't, who
> cares!
> :-)

So, coming back to my orginal question, it is not possible to achieve
total abstraction from the Cocoon engine for this kind of recursive
functionality. However, I should hide this stuff into logicsheet so the
final XML page would be truly portable and only logicsheets would need
to be ported (in case of engine change).

Thanks, it is clear now.

Neeme