I think going through the filtercapabilities and operation description just to
figure out function args would be too much a burden from a usability pov
even if it _might_ be "correct" thinking in ogc terms
2c-
Gabriel
On Wednesday 07 February 2007 20:27, Justin Deoliveira wrote:
> Jody Garnett
Jody Garnett wrote:
> Right - so let's try and be productive.
>
> Function - not self describing (it is a representation of data the user
> provided)
> FilterCapbilities - contains the descriptive element Function (which
> extends Operator) looks like the whole mess involves GenericName again.
>
Right - so let's try and be productive.
Function - not self describing (it is a representation of data the user
provided)
FilterCapbilities - contains the descriptive element Function (which
extends Operator) looks like the whole mess involves GenericName again.
I wonder how we can escalate Gen
Understandable since it came after the fact. In my opinion its not ok, a
function by itself is not self describing enough to create the
FilterCapabilities in the first place!!
Jody Garnett wrote:
> I see - so the GeoAPI Function API may be "okay", we just not have used
> the full scope of the
I see - so the GeoAPI Function API may be "okay", we just not have used
the full scope of the GeoAPI interfaces needed to define our problem?
Sigh!
Jody
> Unfortunatley I have no way of generating a FilterCapabilities from
> the functions plugged in via factory api. And no we are not using
> Fi
Unfortunatley I have no way of generating a FilterCapabilities from the
functions plugged in via factory api. And no we are not using
FilterCapabilities right now. The only use of it I have seen is in
Postgis to declare which functions it can encode as sql, which does not
report the number of a
Sorry I thought that information was in the FilterCapabilities? Are we
using the FilterCapabilities information right now? If not can we? Note
that the way the OGC has defined this abstraction there each name
appears exactly once (with a known number of arguments).
Cheers,
Jody
> How do you fig
How do you figure it is standing up ok? The api has no way of telling
you how many arguments a function can take!! What is one supposed to do,
start at 1 argument and see if that works, if an exception try 2, etc...
Jody Garnett wrote:
> I am less discouraged; the function api is standing up oka
I am less discouraged; the function api is standing up okay - it is our
implementation that is falling down.
Jody
> Well not really since its the original problem. I am a little
> discourages that the only resolution is to redesign the entire
> function api.
>
> Jody Garnett wrote:
>> That is ha
Well not really since its the original problem. I am a little
discourages that the only resolution is to redesign the entire function api.
Jody Garnett wrote:
> That is hack 1
>
> (Going to keep score)
>
> Jody
>> So I guess I am stuck casting to Geotools implementation version .
>> Sigh, so c
That is hack 1
(Going to keep score)
Jody
> So I guess I am stuck casting to Geotools implementation version .
> Sigh, so close to being fully against geoapi interfaces.
>
> Jody Garnett wrote:
>> Justin Deoliveira wrote:
>>> I agree Jody, this is a better design. But do we really need the new
So I guess I am stuck casting to Geotools implementation version . Sigh,
so close to being fully against geoapi interfaces.
Jody Garnett wrote:
> Justin Deoliveira wrote:
>> I agree Jody, this is a better design. But do we really need the new
>> interface. And I don't mean can you think of hypot
Justin Deoliveira wrote:
> I agree Jody, this is a better design. But do we really need the new
> interface. And I don't mean can you think of hypothetical situations
> in which we could use it? I mean is there someone waiting on this
> issue and will be able to commit an implementation and use
I agree Jody, this is a better design. But do we really need the new
interface. And I don't mean can you think of hypothetical situations in
which we could use it? I mean is there someone waiting on this issue and
will be able to commit an implementation and use it within a few weeks.
If the an
We are heading into proposal territory :-( However I think you have
found a real issue with the Function api - I am sorry I did not catch it
earlier.
Here is the use code example:
interface Function {
String getName();
List getParams();
}
class FunctionImpl {
Object evaulate ( Objec
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 h
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 m
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
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
19 matches
Mail list logo
