Looks good justin
Sorry for the red-herring sending you looking at the "wrong" parameter class.
Is the approach working for you?
A couple of questions:
- Do you have any interest in the @UML annotations?
@UML(identifier="argumentCount", specification=UNSPECIFIED)
while I don't use them perhaps you do?
- I find the xml schema fragment (in the javadocs for FunctionName) act as a
good guide
--
Jody Garnett
On Tuesday, 10 May 2011 at 2:45 AM, Justin Deoliveira wrote:
> Ok, second attempt has been made and a new patch is available here:
>
> http://jira.codehaus.org/browse/GEOT-3569
>
> To sum up:
>
> * added org.opengis.parameter.Parameter to opengis module
> * modified org.geotools.data.PArameter to implement the new interface
> * FunctionName uses the new interface for its return type and arguments
>
> Feedback welcome. I will try to write up a more formal proposal soon.
>
> On Fri, May 6, 2011 at 7:07 PM, Jody Garnett <[email protected]> wrote:
> > I started playing around with adding parameter info to FunctionName today.
> > I attached a very rough page to this issue:
> > >
> > > http://jira.codehaus.org/browse/GEOT-3569
> > >
> > > By no means complete or ready to commit, but wanted to post it to foster
> > > discussion and get some initial feedback.
> > >
> > > So basically I tried to follow Jody's advice and reuse on of the existing
> > > "parameter" classes we have, which actually turned out to be troublesome.
> > > Basically here are the candidates i could find:
> > >
> > > 1. org.geotools.data.Parameter
> > > 2. org.opengis.parameter.ParameterDescriptor
> > >
> > > 1 would work generally but it is declared in gt main wheras the function
> > > interface lives in gt-opengis.
> > Darn; sorry Justin I did not think of that.
> > > 2 sort of works but is (a) an absolute nightmare to program against
> > > (getName() not returning a string, etc..). And it does not really allow
> > > me to set min and max occurs cleanly. And quite honestly is really
> > > overkill for what we need.
> > >
> > >
> > >
> >
> >
> > Yeah number (2) is horrible.
> > > So moving forward i see the following possibilities:
> > > 1. Stick with ParameterDescriptor even though it is really messy
> > >
> > >
> > >
> >
> >
> > please no!
> > > 2. Factor out an interface for org.geotools.data.Parameter into gt-opengis
> > >
> > >
> > >
> >
> >
> > Better idea; see below.
> > > 3. Roll our own new interface for Function parameters
> > >
> > >
> > >
> >
> >
> > Only advantage here would be an exact 1/2 match for the filter capabilities
> > document. I am really loath to introduce anything new (as have to make yet
> > another set of dynamic user interfaces support classes etc...
> > 4. Use some alternative that i did not find.
> > >
> > >
> > >
> >
> >
> > 4.1. Move org.geotools.data.Parameter to gt-opengis
> >
> > We could also just move the code over; remember we originally wanted to
> > combined gt-opengis and gt-api; but are stuck on a few issues (mostly
> > ReferencedEnvelope making use of the CRS utility class internally).
> >
> > 4.2 Variation on 2+3 - make an interface for FunctionParameters; and make
> > org.geotools.data.Parameter implement it?
> > > Thanks all. Feedback welcome.
> > >
> > >
> > >
> >
> > Thanks for looking at what is an annoying problem Justin; I am sorry I was
> > not more clear (org.opengis.parameter.ParameterDescriptor is indeed a
> > nightmare to use).
> >
> > Jody
> >
> >
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
