<service service-id="org.puppies.math.Adder"> <implementation service-id="org.puppies.math.Adder"> <configuration-schema service-id="org.puppies.math.Adder"> <configuration service-id="org.puppies.math.Adder">
Did you mean "point-id" or "config-id" or something (besides "service-id") in the last two? -- 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: Bill Lear [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 18, 2003 12:03 PM > To: Jakarta Commons Developers List > Subject: RE: [HiveMind] naming update > > > On Thursday, September 18, 2003 at 11:00:29 (-0400) Howard M. > Lewis Ship writes: > >Current consensus: > > > ><service id=> --> <service-point id=> > ><extend-service service-id=> --> <service for-service-id=> > ><extension-point id=> --> <configuration-point id=> > ><extension point-id=> --> <configuration for-point-id=> > > > >... but consider: > > > ><extend-service service-id=> --> <implementation for-service-id=> > > Let's try this: > > <service-point service-id="org.puppies.math.Adder"> > > <implementation service-id="org.puppies.math.Adder"> > > This, I like. I really dislike moving between "id" and > "service-id". I think it should be consistent. Now, for > configuration, I feel that the last element that you have for > configuration stuff should be: > > <config service-id="org.puppies.math.Adder"> > > or > > <configuration service-id="org.puppies.math.Adder"> > > but the question is, what comes before this? You specify the > abstract configuration that will be accepted, and you then > can specify the concrete values to supply to the > configuration, hence your idea of "contribution". I would > like, again, to retain use of "service-id" throughout, so > let's see what we get with keeping this constraint and > fiddling with the language of "configuration" and "contribution"... > > What we really need is to define the schema, so why not: > > <config-schema service-id="org.puppies.math.Adder"> > > and then: > > <config service-id="org.puppies.math.Adder"> > > or, more verbosely: > > <configuration-schema service-id="org.puppies.math.Adder"> > > and then: > > <configuration service-id="org.puppies.math.Adder"> > > Me likee the stranger. So, to summarize: > > <service-point service-id="org.puppies.math.Adder"> > <implementation service-id="org.puppies.math.Adder"> > <config-schema service-id="org.puppies.math.Adder"> > <config service-id="org.puppies.math.Adder"> > > or: > > <service-point service-id="org.puppies.math.Adder"> > <implementation service-id="org.puppies.math.Adder"> > <configuration-schema service-id="org.puppies.math.Adder"> > <configuration service-id="org.puppies.math.Adder"> > > Visually, I like it. Because the service-id is consistent, > it anchors the previous element name to it strongly and there > is no visual or mental ambiguity about what the intended > "target" of the id actually is. > > Now, one final tweak?: > > <service service-id="org.puppies.math.Adder"> > <implementation service-id="org.puppies.math.Adder"> > <configuration-schema service-id="org.puppies.math.Adder"> > <configuration service-id="org.puppies.math.Adder"> > > Above all, I think we shouldn't be hasty. Names are > important. Good naming schemes generate little overhead for > the community in repetitive explanation to newbies, easier > ramp-up, etc., so we should be careful... > > > Bill > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
