On Tue, May 24, 2011 at 2:13 AM, Jody Garnett <jody.garn...@gmail.com>wrote:
> 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
> ...
>
> And why not be explicit directly in code? An argument has a name and a type
directly... what would the point of storing them in a property file? Only
thing i can think of is for i18n purposes.
I don't like a utility method DataUtilities either. Seems like another
unnecessary abstraction, again i prefer to be explicit and just use the
filter factory for creation. That DataUtilities class already contains so
much random stuff of various levels of quality that I generally stay away
from it.
If a utility method is desired I would put it somewhere more relevant like
on FunctionImpl or a more filter related utility class.
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
>
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
