oodt-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OODT-147) Completely refactor TypeHandling code
Date Tue, 22 Feb 2011 18:51:38 GMT

    [ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997965#comment-12997965

Chris A. Mattmann commented on OODT-147:

Heh, the Element Name was *never* suppossed to be unique, hence the Element ID :)

I'm fine with adding a method to getElementByName(String elementName, ProductType productType),
but I'm not fine with removing the existing getElementByName(String elementName) function.
That function should simply return the first (possibly only) occurrence of the Element with
the given name per its original intended behavior.

I think we're in agreement though!

> 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
> {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
> # 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


View raw message