Return-Path: 
 <dev-return-63900-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 93653 invoked from network); 30 Jul 2004 07:15:50 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 30 Jul 2004 07:15:50 -0000
Received: (qmail 36234 invoked by uid 500); 30 Jul 2004 07:15:50 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 35725 invoked by uid 500); 30 Jul 2004 07:15:46 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 35711 invoked by uid 99); 30 Jul 2004 07:15:46 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received: from [195.28.83.3] (HELO fwlin.asset.sk) (195.28.83.3)
  by apache.org (qpsmtpd/0.27.1) with ESMTP; Fri, 30 Jul 2004 00:15:42 -0700
Received: from localhost (fwlin [127.0.0.1])
	by fwlin.asset.sk (Postfix) with ESMTP id A00625A3B7
	for <dev@cocoon.apache.org>; Fri, 30 Jul 2004 09:17:14 +0200 (CEST)
Received: from fwlin.asset.sk ([127.0.0.1])
 by localhost (fwlin [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 06885-05 for <dev@cocoon.apache.org>;
 Fri, 30 Jul 2004 09:17:14 +0200 (CEST)
Received: from s2-ba.asset-internal (s2-ba.asset-internal [172.16.51.1])
	by fwlin.asset.sk (Postfix) with ESMTP id 6702C5A1A7
	for <dev@cocoon.apache.org>; Fri, 30 Jul 2004 09:17:14 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Disposition-Notification-To: "DURDINA Michal" <Michal.Durdina@assetsoft.sk>
Subject: RE: Design of unmarshaling sitemap component
Date: Fri, 30 Jul 2004 09:15:35 +0200
Message-ID: <4C47FFB0CC6A2E4D92550B89B68FC7830170C74F@s2-ba.asset-internal>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Design of unmarshaling sitemap component
Thread-Index: AcR1PINxnpxdiThqRxG1zyJuY/UR0AAUTE7QABtt1eA=
From: "DURDINA Michal" <Michal.Durdina@assetsoft.sk>
To: <dev@cocoon.apache.org>
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

> -----Original Message-----
> From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
> Sent: Thursday, July 29, 2004 7:06 PM
> To: dev@cocoon.apache.org
> Subject: RE: Design of unmarshaling sitemap component
>=20
>=20
> DURDINA Michal <Michal.Durdina@assetsoft.sk> writes:
>=20
> > Hi,
> > I would like to discuss the design problem of the sitemap=20
> > component. My plan is to develop special let's call it=20
> > transformer for transforming sources for pages written or=20
> > generated by analysts (model) to dynamic pages generating=20
> > required results (implementation). The form of model is=20
> > custom XML according to given XMLSchema and the=20
> > implementation pages should be in form of jxtemplates (or xsp).
> >=20
> > The transformation should go like this:
> >=20
> > pipeline:
> >             additional data
> >                    |
> > modelXML -> populated modelXML -> computed model ->=20
> jxtemplate source
> >=20
> > The intent of the pipeline is to generate executable source=20
> > from model that will generate required dynamic page. The=20
> > trick is that the computed modelXML is not trivial and should=20
> > be implemented as Java OM.=20
>=20
> Wow.  You're overall requirements sounds a lot like ours so I'm
> interested in how you reached this design?  Given your use of=20
> jxtemplate
> I can't see that it's performance driven? If not, why not just keep
> everything in XML from end to end and use XSLT to derive the computed
> model? =20
>=20
> <snip>Castor/java implementation issues</snip>
>=20
>=20

Yes, keeping everything in XML and using XSLT would also realize the =
transformation. Given that it would involve a XSL stylesheet that will =
do all the computations. Such a stylesheet would not be easy to write =
and it will be probably too complex to maintain. Using Java for =
computation on input XML should be more straightforward and using =
jxtemplate for outputing the resulting XML gains from clear view how the =
resulting XML will look like. Performance was not the main requirement =
as the source generation occures only once and then it is cached =
although this should perform better than XSLT.

I already started the implementation and have first version of such a =
component implemented as a transformer (case A.). I hope it will meet my =
requirements and we will profit form this kind of concept.

Thank you for comment,
Michal