[Schema] Constants - A happy Medium?

[Ole Ersoy <ol...@gmail.com>]

Hey Guys,

I know what you are thinking.  Heeeere he goes again :-)

And you would be right.  But I think I may have found
a simpler solution that everyone can live with.

In order to minimize the DAS's dependencies, I created another
set of constants and I'm naming them like this:

AttributeTypeConstants

So AttributeType's constants have their own interface.

This completely eliminates the need for a convention,
and it's clear that these are attribute types.

So to get the CN attribute type we just do:
AttributeTypeConstants.CN

It's short and we see that it is an AttributeType.

So if we wanted to we could keep the
the other constants for now and slowly
introduce these.  That way
we don't break client code, and the
names are shorter still and more precise.

Cheers,
- Ole

Re: [Schema] Constants - A happy Medium?

[Ole Ersoy <ol...@gmail.com>]

Alex Karasulu wrote:
> Ole,
> 
> On 4/20/07, *Ole Ersoy* <ole.ersoy@gmail.com 
> <ma...@gmail.com>> wrote:
> 
>     Hey Guys,
> 
>     I know what you are thinking.  Heeeere he goes again :-)
> 
> 
> Heh well a little bit but persistence is a good thing.

Sometimes :-)

SNIP


> I see but the problem with this is that you mix the constants of all the 
> schemas together.

That's true.  Maybe this thought would help:

If I were to generalize it I would
describe it as the interface name
capturing the label for the constants
as accurately as possible.

So we could break it up further
if necessary.

We might have:
ObjectClassBarConstants
ObjectClassFooConstants
etc

So in the end we would have
more constant files, each file
being a container for a set
of constants intended for a specific purpose.

SNIP

Cheers,
- Ole

Re: [Schema] Constants - A happy Medium?

[Alex Karasulu <ak...@apache.org>]

Ole,

On 4/20/07, Ole Ersoy <ol...@gmail.com> wrote:
>
> Hey Guys,
>
> I know what you are thinking.  Heeeere he goes again :-)


Heh well a little bit but persistence is a good thing.

And you would be right.  But I think I may have found
> a simpler solution that everyone can live with.
>
> In order to minimize the DAS's dependencies, I created another
> set of constants and I'm naming them like this:
>
> AttributeTypeConstants
>
> So AttributeType's constants have their own interface.


I see but the problem with this is that you mix the constants of all the
schemas together.

My reason for separating schema constants into their separate files was
because not all
schema's are packaged into the same jar.  Some schemas are generated as
non-essential
schemas and their constants might be best kept with them.  However this
approach is
interesting.

This completely eliminates the need for a convention,
> and it's clear that these are attribute types.


Yeah it would but other issues might arise.

So to get the CN attribute type we just do:
> AttributeTypeConstants.CN
>
> It's short and we see that it is an AttributeType.
>
> So if we wanted to we could keep the
> the other constants for now and slowly
> introduce these.  That way
> we don't break client code, and the
> names are shorter still and more precise.


Yeah this might be good.  I wonder what others think.

Alex