[
https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997933#comment-12997933
]
Brian Foster edited comment on OODT-147 at 2/22/11 6:11 PM:
------------------------------------------------------------
haha . . . chris, it is attached to ProductTypes and not Elements because you
wouldn't let me when i first implemented it . . . this is because different
TypeHandlers many times have to be specified for the same ElementName depending
on the ProductType. For example, DataVersion is a field usually shared across
multiple ProductTypes, however usually this field is very different for each
ProductType (i.e. one ProductType may have a version which is of the format
v01.02 where others are just integers -- the former requires a TypeHandler
which enforces v\d{2}\.\d{2} and the latter would probably have a type handler
which enforces \d{3}. If this where to be attached to Elements, then
ElementName could not be unique -- since i would need two Elements with the
same name but different ids such that each of the Eleents could have their own
TypeHandler and then attached to the appropriate ProductType and you where set
on having ElementName unique (not just ElementId).
was (Author: bfoster):
haha . . . chris, it is attached to ProductTypes and not Elements because
you wouldn't let me when i first implemented it . . . this is because different
TypeHandlers many times have to be specified for the same ElementName depending
on the ProductType. For example, DataVersion is a field usually shared across
multiple ProductTypes, however usually this field is very different for each
ProductType (i.e. one ProductType may have a version which is of the format
v01.02 where others are just integers -- the former requires a TypeHandler
which enforces v\d{2}\.\d{2} and the latter would probably have a type handler
which enforces \d{3}. If this where to be attached to Elements, then
ElementName could not be unique (since i would need two Elements which the same
name but different ids such that each of the Eleents could have their own
TypeHandler and then attached to the appropriate ProductType and you where set
on having ElementName unique (not just ElementId).
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally
> intended to strongly type Metadata elements within CAS file manager. IOW, it
> was originally conceived to make declaring a type for an Element easy.
> Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when
> it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a
> number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is
> not tailored for the general audience and does little to inform a user of
> what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when
> instead they really should be a part of the Validation layer policy (i.e.,
> elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of
> having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler,
> we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does
> the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file
> manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
