Giving this one a bit more thought ... FunctionNameImpl is used directly by
most of the implementations in gt-main.
static FunctionName NAME = new FunctionNameImpl("snap", "point", "line");
This is backed by the following method:
private static List<String> generateArgumentNames( int count, List<String>
copy ){
List<String> names = Arrays.asList( new String[count]);
for( int i=0; i < count; i++){
String name = "arg"+i;
if( copy != null && i < copy.size() && copy.get(i) != null ){
name = copy.get(i);
}
names.set(i, name );
}
return names;
}
There are two quick approaches to use:
1. Make use of DataUtilities.type(String typeName) to support the following:
static FunctionName NAME = new FunctionNameImpl("snap", "point:Point",
"line:MultiLineString");
2. Create a property file that can map common values as you indicated before.
line=MultiLineString
point=Point
geom=Geometry
...
3. Or combine the two...
private static List<Parameter<?>> generateArguments( int count, List<String>
copy ){
List<Parameter<?>> arguments = new ArrayList<Parameter<?>>();
for( int i=0; i < count; i++){
String name = "arg"+i;
Class<?> type = Object.class;
String title = null;
String description = null;
if( copy != null && i < copy.size() && copy.get(i) != null ){
String specification = copy.get(i);
if( specification.contains(":")){
String split[] = specification.split(":");
name = split[0];
type = type( name, split[1]);
title = name;
description = null;
}
else {
title = name;
description = null;
type = type( name, null );
}
}
Parameter parameter = new Parameter(name, type, title, description );
arguments.add( parameter );
}
return arguments;
}
static Properties lookup;
static {
lookup = new Properties();
...
}
private static Class<?> type(String name, String spec) {
if( spec == null ){
// check for a default
spec = lookup.getProperty(name);
}
Class<?> type = null;
if (spec != null ){
type = DataUtilities.type(spec);
}
if( type != null){
type = Object.class;
}
return type;
}
--
Jody Garnett
On Saturday, 21 May 2011 at 10:28 AM, Jody Garnett wrote:
> The argument naming convention was part of jody's last proposal on adding
> arguments names to functionName. In some cases I tried to be a bit smarter in
> geoserver and as a workaround handle some "well known" argument names such as
> "geometry". For example:
> >
> >
> >
> >
>
> I had a similar idea; if we could handle "geom", "geom1","geom2","geomN" (and
> also "int","int1","int2","int3","intN") - even if just for the gt-main based
> functions a lot of of boiler plate code would not be needed (and it would
> encourage consistency).
>
> For the most part when I added names to functions I was consistent; so I
> think this approach would take us 90% of the way.
>
> Jody
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
