Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 4915 invoked from network); 24 Sep 2003 21:44:57 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 24 Sep 2003 21:44:57 -0000 Received: (qmail 31273 invoked by uid 500); 24 Sep 2003 21:44:41 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 31081 invoked by uid 500); 24 Sep 2003 21:44:40 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 31064 invoked from network); 24 Sep 2003 21:44:40 -0000 Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39) by daedalus.apache.org with SMTP; 24 Sep 2003 21:44:40 -0000 Received: from almightybeast (unknown[65.114.188.240]) by comcast.net (rwcrmhc13) with SMTP id <2003092421444601500knrehe> (Authid: hlship); Wed, 24 Sep 2003 21:44:46 +0000 From: "Howard M. Lewis Ship" To: "'Jakarta Commons Developers List'" Subject: RE: [HiveMind] Re: Schema instead of BuilderFactory? Date: Wed, 24 Sep 2003 17:44:41 -0400 Message-ID: <008d01c382e5$1019e500$d0020a0a@ALMIGHTYBEAST> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3F71EFCE.2070400@comcast.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I didn't see this earlier. It's another interesting idea; Basically, a more powerful version of = BuilderFactory that supports a stack-oriented approach to constructing the service, similar to how = contributions are processed into Java objects. I see this as something that could sit beside = BuilderFactory unless it could be made as easy to use as BuilderFactory. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com > -----Original Message----- > From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]=20 > Sent: Wednesday, September 24, 2003 3:26 PM > To: Jakarta Commons Developers List > Subject: [HiveMind] Re: Schema instead of BuilderFactory? >=20 >=20 > In case any of you missed it. >=20 > Christian Essl wrote: >=20 > > I am realy found of the idea of using the BuilderFactory. > > > > What I suggest is that you have like for=20 > configuration-points also the > > possibility to define a schema(-processing) for the most important=20 > > 'configuration' - the initial setup of a ServiceImplementation. > > > > Therefore I think a tag lets say > class=3D"implementingClass"> which contains a schema-processing=20 > > definition would be useful. The tag could than=20 > > contain the xml for the schema. When the rules of the schema are=20 > > processed, the CoreImplementation would be on top of the=20 > stack. (May=20 > > be it could also be enforced that when for a class such a schema is=20 > > given it can only be created with ). > > > > Through the BuilderFactory which does this currently rather a > > 'property- scripting' aproach is given. I know the=20 > BuilderFactory also=20 > > has the point- id-attribute. However using this means more=20 > typing for=20 > > the user and the service-implementor and there is a=20 > difference between=20 > > service-construction configuration and contributed configuration=20 > > (similar to java constructors and properties). > > > > I think the suggested approach has also other advantages. It would > > make the configuration of the Service easier and more clear than=20 > > through the BuilderFactory. It would relieve the service of some=20 > > initial state- checking. It would also provide better documentation=20 > > about what are initialization (constructor-like) properties and=20 > > 'normal' properties. Finally it would also make the whole=20 > > 'BuilderFactory-aproach' more powerful. (Future stuff: I=20 > was thinking=20 > > of the late module loading and for this it would be very useful -=20 > > because there would be a distinction between initial=20 > configuration and=20 > > contributed configuration.) > > > > For my problem (you know a clean-shutdown ;-)) it would certainly > > help. Currently I try to define the dependencies in a=20 > > configuration-point (pro: the user can see the dependencies) but I=20 > > think it should be bound to the implementation of the=20 > Service, however=20 > > also there I have my problems (the Service does not know=20 > its id nor of=20 > > its dependent services). I also think for other such 'in-between'=20 > > things (like events) such a tag would help. > > > > > > > > > > > > > > > >=20 > --------------------------------------------------------------------- > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org > > > > >=20 >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: commons-dev-help@jakarta.apache.org >=20 --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org