> So yeah, while WPS per se is still not ready for GeoServer core
> (over my dead body as long as it lacks of service limits and ability
> to hide processes),
> 
> 

Agreed. 
> the process API looks like something we can commit to once these
> fixes are in.
> 
> 

That would make me cheerful / motivated.
> > @DescribeParameter(name = "multiplier", min = 0, default = 1d) double
> > multiplier
> > 
> > We may get more milage out of taking a default String and allowing
> > Converters to have a go at it.
> > 
> > Compare:
> > - @DescribeParameter(name = "background", min = 0, default = "#23112F")
> > Color background
> > - @DescribeParameter(name = "background", min = 0, default = new Color(
> > 35,17,47) Color background
> > 
> > But still point taken; great to document the default value that can be used
> > if null is passed in.
> > 
> 
> 
> Hum... taking always a string no, if possible I want something that
> can be type safe,
> but allowing Object there and trying converters if the type is not the
> target one
> is indeed in line with how the rest of GeoTools works, I can go for that.
> 
> 

Hold on we are missing something; I thought annotations could not accept full 
objects (since they are processed by the compiler). As such we may be stuck 
with converting strings.
> > The DescribeParameter information is pulled into a Parameter object; which
> > contains a metadata map and common keys. The base Parameter implementation
> > contains methods to perform common validation checks.
> > 
> 
> Yep, but they are too basic.
> 
> 

Then that is something we can fix; right now it looks like min, max and options 
are supported. Along with restricting CRS and FeatureType (I presume for 
feature collection parameters).
> Holy cow no, I don't want to make people write that much code around.
> 
> 

You are correct AnnotationDrivenProcessFactory should do it; and throw any 
illegal argument exceptions or full in any default values prior to calling the 
method.
> When I write something like:
> 
> @DescribeResult(name = "bar")
> public int execute(@DescribeParameter( name = "scale",
> min=100, max=200,defaultValue=100) double scale) {
> return foo(scale);
> }
> 
> I want be be sure that scale is not null and valid without having to
> write a single extra line of code.
> 
> 

So you would expect AnnotationDriveProcessFactory to do the work.

The only advantage to giving developers the tools to reuse the validation logic 
inside their method would be to allow the methods to be used by normal Java 
developers (i.e. as static methods). As such my example
provided a way to reuse the validation checks in that case.
> That's why I would like to roll a set of common validation routines,
> to make people have to write their custom validation code only
> if their need is totally uncommon.
> 
> 

So we are agreed; the only difference is I was going to add the methods to the 
Parameter class.  
> As for parameter having a map, yes it has one, but it's not exposed
> to the outside world, which it seems it's needed to provide some
> extra info needed in process execution (the association between
> output mime type and the input that will receive the chosen one,
> and the default value, thought with the latter we could use
> the "sample" value... yet sample does not mean default...)
> 
> 

The parameter class has the same open ended map solution you describe; the only 
difference is we were documenting the keys as they were agreed on. So adding a 
MIME_TYPE key, or DEFAULT_VALUE key can be done as needed.
The "sample" value has been used as the default up till now.

Jody
 

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to