On Mon, Aug 3, 2009 at 9:19 AM, Jody Garnett
<jody.garnett@xxxxxxxxx> wrote:
> I intended to use it in an immutable fashion. My worry about adding the
> additional constructors is: Is the API flexible enough with the qualifier?
> I went the setter route because it is easier to add more properties that
> way. We can document them as being only usable during construction phase
> and even do runtime checks to ensure it. Or maybe we need a ID factory?...
>
> Maybe that one extra field is enough. I don't know. We should decide
> that.
Nope; no factory; and I am still worried about the qualifier. If we
start to have a factory we start to make the object so complicated it
is no longer useful as what it is for - an identifier to look up
stuff.
A good point. Well we have to have the qualifier at least. Possibly we should mandate the qualifier? The reason for the qualifier is illustrated by Geotiff and World+image. They both support a geotiff if the geotiff has a world file. However the URL doesn't distinguish between the two types so they clobber each other in the catalog. We need to be able to say the type of element. Right now it is an optional field.
This is almost a problem with WMS and WFS but they actually have different URLs for the same data but the conceptual problem is the same. So I added qualifier. If you have a better idea I am all for it.
Maybe the solution is simply to edit all plugins and change the ID so that there is a type attribute that is required.
Dunno.
Another point about layer is that layer wants both the geotiff and the world+image like it wants both WMS and WFS so when it searches it needs a way to search saying find me the items with this id but don't restrict to a certain type. I think I added that sort of logic in too.
Oh, And about toString. Do good testing before and after because I don't know if it is used in appropriately in other places than the tests. To string should not be sematics I dont think. Just for display.
Jesse
