Ok you have an interesting idea Jody, but I really need to focus here and not wander off on a design tangent.
How will i look up all functions available and report back their names and number of arguments? Code example welcome :). -Justin Jody Garnett wrote: > I think you hit the nail on the head ... we are talking about different > things :-) > > Indeed I think I am onto something and a lot of the reason we are having > problems of this nature is due to a design mistake we made. > > Let me outline Idea #2 and see if it makes sense (for get your problem > for a moment and think on what "Function" is for) > > Function - interface matching Filter 1.1, represents "name", and some > parameters as specified by the user > FunctionImpl - direct implementation of the above, able to store the > "name" and "parameters" > > (Nowhere am I talking about Cosine extends Function able to store "cos" > and two parameters) > > This is *it* - a definition of what Function needs to do for us at the > GeoAPI level to capture Filter 1.1. > > We do however have this idea where we would like to evaulate( Object ) a > Function can get a value back, to do that we need to go from Function to > an implementation (we need to look up "cos" and use our two parameters > to get a value). > > > If you remember for our implementation of PropertyAcessor we had *one* > implementation that only knew how to work with Features. We broke this > assumption and made our implementation of evaulate look up > "propertyaccessors" that had implementations for Feature, POJOs, etc... > > I think we have the same situation going on here; and I can capture it > in a single question: > - Can we (in GeoTools) parse a Filter document that uses a function for > which we have no matching implementation? > > To continue; the information you wanted to know (the number of > parameters) is documented in the FilterCapabilities; it should *not* be > modeled as part of the Function. Separation between data and metadata. > > Jody >> Hmm, you seem to make the separation between interface an >> implementation in both your ideas, I am not sure that is the issue. I >> think the issue is that we are not properly modelling a function. Or >> at least not the parameters anyways. >> >> Function parameters are something that will change each time the >> function is called. The more I think about it the more I think that >> they need to be mutable. >> >> Regardless, I am sorry I dont understand either of your ideas Jody :). >> >> -Justin >> >> Jody Garnett wrote: >>> Justin Deoliveira wrote: >>>> Hi all, >>>> >>>> Transitioning from the geotools FunctionExpression to geoapi >>>> Function has raised an issue. The FunctionExpression interface had >>>> the "getNumArgs()" method which returns the number of arguments the >>>> function can take. The api was also mutable which meant I could >>>> create the function, and then set its arguments. >>>> >>>> However, with Function I don't have this ability. The Function >>>> interface is immutable, which means that I cant create an instance >>>> of a function without having the parameters that I intend to >>>> evaluate it with. The number of arguments would then be available >>>> via getParameters().size(). >>>> >>>> The underlying problem is that in a Filter capabilities document one >>>> needs to declare which functions are available and how many >>>> arguments they have. There is really no way to do this with this api. >>>> >>> Idea#1: Good conflict; should this be moved to a FunctionFactory API? >>> >>> Do we not need to have access to the description of the service >>> (FunctionFactory in >>> this case) in order to produce that filter capabilities description?; >>> the creation of an >>> actual Function to do the work is a separate matter. >>> >>> This is a tough one; since we are stuck between data representation >>> (ie perhaps the user >>> has an invalid function call?) and implementation (perhaps the >>> implementation only *has* two fields >>> to store arguments in. >>> Idea#2: Separate as with PropertyAcccessor >>> >>> It strikes me we have the same scenario as with PropertyAccessor; the >>> ability to "hold" the users request >>> is different from the implementation used to satisfy it. >>> >>> 1. Make Function *pure* so we can represent what the user said >>> 2. Make a LibraryFactory that returns FilterCapabilies information >>> describing the function implementations made available, and makes a >>> Library object capable of doing the work. >>> 3. When evaluating a Function process the LibraryFactory list, >>> grabbing the library that can implement the function the user >>> specified, and then call that implementation >>> >>> Consequences: >>> - Note this makes it easy for us to advertise the abilities of back >>> end data sources (like Oracle) simply in terms of FilterCapabilies; >>> in this case the "implementation" would not be provided - the >>> function would just be written out with the SQL writer. >>> - It would be simple to do a first cut of a Library based simply on >>> Java reflection (using the Math class as an example) >>>> So... any ideas on how to proceed? Should we make Function "semi >>>> mutable", in that you can create one without specifying any >>>> parameters, and then call #getParamters().add( ... ). I guess we >>>> would also need a method for the number of parameters. >>>> >>> I am not sure this would work for someone creating a "formula >>> builder"; what do you think of the above two ideas? >>> >>> Cheers, >>> Jody >>> >>> ------------------------------------------------------------------------- >>> >>> Using Tomcat but need to do more? Need to support web services, >>> security? >>> Get stuff done quickly with pre-integrated technology to make your >>> job easier. >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>> Geronimo >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>> _______________________________________________ >>> Geoapi-devel mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/geoapi-devel >>> >>> >>> >> > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Geoapi-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/geoapi-devel > > !DSPAM:1004,45c8ea8a130921425493344! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
