Hi David, As the developer I assume you are referring to the datastore developer? The "extraData" parameter is something that is more intended to be used internally by the filter encoder. As the data store developer you will likely never be just encoding a literal in isolation ( i could be wrong ), but as part of a binary expression as stated below. Internally the encoder will pass information around via "extraData". In this case in the accept(PropertyName) method, the encoder will figure out what the type of "NAME" is, and pass that to accept(Literal) via extraData.
-Justin David Adler wrote: > I ran into the same problem when handling a geometry literal. How is a > developer supposed to know that the call to accept needs to include an > extraData parameter of Geometry.class in this case? > > Farber, Saul (ENV) wrote: >> Rob, >> >> Yeah, cory's right. The 'extraData' object in the FilterVisitor interface >> is a 'utility' object. Often when passing things around a filter visitor, >> you want to pass along something else. An output stream to write output to, >> some 'class context', or a stateful tracker of some sort. >> >> In the specific case of the FilterToSQL class, in *most* cases the extraData >> object is null. However, in the very specific case of resolving a Literal, >> the parent operator (the one that's 'doing the comparison' as it were) needs >> to tell the Literal exactly how it's going to be interpreted. >> >> For example: >> >> <PropertyIsEqualTo> >> <PropertyName>NAME</PropertyName> >> <Literal>123</Literal> >> </PropertyIsEqualTo> >> >> Should the comparison function treat 123 as a number or as a string? Well, >> what are we comparing it to? >> >> The FilterToSQL class, when encountering this bit of filter, first visit the >> PropertyIsEqualTo node, notes that one or the other of the children is a >> Literal, and then decides that it must tell the code that's encoding the >> literal how the literal will be expected to behave (as a number or string). >> So it figures the class of the referenced property (NAME in this case) by >> doing some FeatureType manipulation, and then passes that class to the >> visit() method which goes to visit the literal. >> >> >> Sorry if that explanation was overkill. >> >> You asked "is there some general documentation about the extradata parameter >> in the FilterVisitor interface?" >> >> The reason there's isn't much that's useful is that it's a pretty general >> mechanism, that's meant to be abused by whichever particular algorithm >> decides to implement FilterVisitor. >> >> --saul >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] on behalf of Cory Horner >> Sent: Thu 4/5/2007 11:20 AM >> To: geotools list >> Cc: Rob Atkinson >> Subject: Re: [Geotools-devel] Implementing GeoAPI FilterVisitor (FilterToSQL) >> >> Rob Atkinson wrote: >> >>> in FilterToSQL >>> >>> public Object visit(Literal expression, Object context) throws >>> Class target = (Class)context; >>> >> If I remember correctly, the context (extraData) parameter is optional >> and is basically whatever you want it to be. A null/instanceof check >> should do the trick, unless the visitor really should blow chunks if it >> doesn't have a context. >> >> Cory. >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
