[jira] Issue Comment Edited: (OODT-147) Completely refactor TypeHandling code

["Paul Ramirez (JIRA)" <ji...@apache.org>]

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

Paul Ramirez edited comment on OODT-147 at 2/22/11 3:43 PM:
------------------------------------------------------------

+1, having types will be nice. It looks as the current TypeHandler was possibly trying to do this? Although it also seems to be a blend of value mapping and met extractor functionality. Although, I've never used it so I'd probably have to lean on Brian, since he wrote that code, to describe what use cases it was trying to satisfy. 

Starting with the basic types such as Integer, Double, Date, etc. would be nice as I'm sure there is a lot of functionality that would satisfy many of the use cases that would come along. Some minimal implementation of these types plus an extension place for adding one's own type would be a big win.

If the current functionality of the TypeHandler code is to do value mapping for queries and metadata then that should likely be more thought out. For instance, is that done server side or client side? Is it transparent to the user? How and where is it configured? Is this something that can be used outside the filemgr framework?

      was (Author: pramirez):
    +1, having types will be nice. It looks as the current TypeHandler was possibly trying to do this? Although it also seems to be a blend of value mapping and met extractor functionality. Although, I've never used it so I'd probably have to lean on Brian, since he wrote that code, to describe what use cases it was trying to satisfy. 

Starting with the basic types such as Integer, Double, Date, etc. would be nice as I'm sure there is a lot of functionality that would satisfy many of the use cases that would come along. Some minimal implementation of these types plus an extension place for adding one's own type would be a big win.

If the current functionality of the TypeHandler code is to do value mapping for queries and metadata then that should likely be more thought out.
  
> 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