commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ja...@carmanconsulting.com
Subject Re: [HiveMind] naming update
Date Thu, 18 Sep 2003 15:30:05 GMT
I think a consistency rule should be in place.  When you are referring to
the "id" attribute value of another element, you should use the attribute
name <element-name>-id="yaddayadda".  As in...

<implementation service-id="yaddayadda">

This is somewhat similar to the naming convention people use in databases.
So, I have a person table with an "id" column, and whenever there is a
foreign key pointing to a person, its column name is "person_id".  At least
that's how I like to structure it.  Some people would rather name the person
table's "id" column "person_id" thereby keeping the meaning of "person_id"
consistent across ALL tables.  I could even live with (I guess)...

<service service-id="MyService">
<implementation service-id="MyService">

It doesn't really matter what convention is chosen, as long as there is a
consistency to it, really (my $0.02).

----- Original Message ----- 
From: "Howard M. Lewis Ship" <hlship@comcast.net>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Sent: Thursday, September 18, 2003 11:19 AM
Subject: RE: [HiveMind] naming update


> Yeah ... the verb'ed attribute name is awkward.
>
> The underlying problem is the simularity between:
> <configuration-point id="..."> and
> <configuration point-id="...">
>
> Option A:
> <configuration-point id="...">
> <contribution point-id="...">
>
> Option B:
> <configuration-point id="...">
> <contribution id="...">
>
> (Don't like this one; are we defining a contribution or making a
contribution?)
>
> Option C:
> <define-configuration-point id="...">
> <configuration point-id="...">
>
> (Kinda like this one ... but then should it be <define-service>?)
>
> Other options?
>
> --
> 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: james@carmanconsulting.com [mailto:james@carmanconsulting.com]
> > Sent: Thursday, September 18, 2003 11:16 AM
> > To: commons-dev@jakarta.apache.org
> > Subject: Re: [HiveMind] naming update
> >
> >
> > I don't know if I'd put the "for" in there, but I like the
> > "implementation" idea....
> >
> > <implementation service-id="yaddayaddayadda">
> >
> > ----- Original Message ----- 
> > From: "Howard M. Lewis Ship" <hlship@comcast.net>
> > To: "'Jakarta Commons Developers List'"
> > <commons-dev@jakarta.apache.org>
> > Sent: Thursday, September 18, 2003 11:00 AM
> > Subject: RE: [HiveMind] naming update
> >
> >
> > > 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=>
> > >
> > > --
> > > 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: Howard M. Lewis Ship [mailto:hlship@comcast.net]
> > > > Sent: Thursday, September 18, 2003 7:39 AM
> > > > To: Jakarta Commons Developers List
> > > > Subject: [HiveMind] naming update
> > > >
> > > >
> > > > Harish's suggestion:
> > > >
> > > > <service id=> --> <service-point id=>
> > > > <extend-service service-id=> --> <service service-id=>
> > > > <extension-point id=> --> <configuration-point id=> <extension
> > > > point-id=> --> <configuration point-id=>
> > > >
> > > > Everyone seems pretty keen on this.
> > > >
> > > > I have minor reservations about <service> not quite
> > capturing what
> > > > the element does.  I agree that <extend-service> has some
> > unwanted
> > > > connotations.  <provide-service> perhaps? At one time it was
> > > > <contribute-service>.
> > > >
> > > > Last point was the excessive simularity of <configuration-point
> > > > id="..."> and <configuration point-id="...">.
> > > >
> > > > Perhaps that should be <configuration for-point-id="..."> to help
> > > > distinguish the two visually? An earlier version was
> > > > <contribute-configuration> but damn thats long.
> > > >
> > > > Alternately, here's my suggestion:
> > > >
> > > > <service> --> <define-service-point>
> > > > <extend-service> --> <service>
> > > > <extension-point> --> <define-configuration-point>
> > <extension> -->
> > > > <configuration>
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>


Mime
View raw message