Okay my "quick fix" for the day has produced results:
- http://docs.geotools.org/latest/userguide/library/main/filter.html#function
(the above should update with a filled in list of functions when the docs next
rebuild)
Here are some additional ideas that hold promise:
Annotated Class
Many of the functions just back onto the StaticGeometry class. Could we
annotate that class and produce a FunctionFactory from the annotations (thus
having access to both the attribute name and type information to make your
suggestion easier?) This is the long term direction I would like to go in for
defining functions ... kind of the point of FunctionFactory.
Property File
The result we want out of this, at the end of the day is very similar to a
property file; if we actually did implement this as a property file; it could
be translated into different languages. Since we expect these names to show up
in user interfaces this would be a *good thing*.
Property File version 2
The attribute names are often very similar (ie "geometry", "number", "string").
We could have FunctionNameImpl use a property file to translate these
internally with no change to existing Java code. We may be able to combine this
idea with the idea of an annotated class and get the best of both worlds.
--
Jody Garnett
On Sunday, 17 April 2011 at 8:57 PM, Jody Garnett wrote:
> The idea of improving FunctionName so it describes better is a good one.
> However it is a bit more that what I was doing now.
>
> If we were to do this I think my shopping list would be:
> - name
> - description
> - type (hard to express type for filter functions)
> - getNumberOfArguments(); // change javadocs to say this is a minimum number
> of argumetns
> - isNumberOfArgumentsUnlimited(); // true for things that accept unlimited
> number of arguments like Interpolate
>
> --
> Jody Garnett
>
> On Sunday, 17 April 2011 at 6:28 PM, Andrea Aime wrote:
> > On Sun, Apr 17, 2011 at 10:15 AM, Andrea Aime
> > <[email protected]> wrote:
> > > So this means we now have function overloading, but not the java way,
> > > based
> > > on attribute types, but on the argument names instead?
> > > That sounds odd to me, wouldn't it be better to leave overloading aside
> > > and just
> > > demand a unique name?
> >
> > Which also makes me wonder about describing not only the names, but also the
> > types of the arguments.
> > Ins't that just as important documentation wise?
> >
> > Here is the function reference I wrote some time ago for geoserver:
> > http://docs.geoserver.org/stable/en/user/filter/function_reference.html
> >
> > For each function we have a name, arguments and their types, and a function
> > description.
> >
> > Btw, also detailing the process funtion wrapper, they all have variable size
> > arguments, and each argument is a Map<String, Object>... not sure how
> > they fit with this proposal
> >
> > Cheers
> > Andrea
> >
> >
> > --
> > -------------------------------------------------------
> > Ing. Andrea Aime
> > GeoSolutions S.A.S.
> > Tech lead
> >
> > Via Poggio alle Viti 1187
> > 55054 Massarosa (LU)
> > Italy
> >
> > phone: +39 0584 962313
> > fax: +39 0584 962313
> > mob: +39 333 8128928
> >
> > http://www.geo-solutions.it
> > http://geo-solutions.blogspot.com/
> > http://www.youtube.com/user/GeoSolutionsIT
> > http://www.linkedin.com/in/andreaaime
> > http://twitter.com/geowolf
> >
> > -------------------------------------------------------
> >
>
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
