On Wednesday 03 December 2008 23:28:42 Jody Garnett wrote: > Gabriel Roldán wrote: > > understood. > > But since my first goal was to port what currently is on > > PostPreProcessFilterSplittingVisitor to non deprecated stuff what if I > > move it to main so we can look at what's needed for fallback values on > > actual code? > > Good plan; get onto non deprecated code first and then we can look at > fallback value as we find it; I only mentioned fallback value as it was > part of the change > that gave you variable number of arguments (ie your origional question). > > > For doing so, tough, I have a naming clash. Should I call the non > > deprecated one PostPreProcessFilterSplittingVisitor2 or something? > > Can we find anything shorter? That is a real moth full... > > SplitLocalVisitor - result in filter that can be executed on the local > implementation (ie the capabilities of geotools) > SplitRemoteVisitor - result in filter that can be executed on the remote > service (ie the capabilities of the datastore) (using fallback values if > needed based on capabilities function list) > BiSplitUsingCapabilitiesVisitor - result in two filters (one for local > and one for remote) that applied together would be the same as the > origional filter well, I just ported PostPreProcess... to use Capabilities and it already works by working over two stacks, one for supported and another for unsupported filters, and the code is quite convoluted so I'm afraid of splitting the splitter now.. yet yours seems like a good idea cuase I've seen the use of getPreFilter and getPostFilter on the jdbc land being tricky (tricky like in holding the last computed filters internally to avoid recomputing when calling one or the other method). But that's JDBCDataStore specifics, I guess in general the two are needed together and hence the single splitter.
So I guess my proposal comes down to just get a filter splitter on trunk that works on non deprecated stuff.. Andrea, how will this fit your dream of getting rid of the old filters once for all? As for a name, I could just call it CapabilitiesFilterSplitter. The fact its a visitor could even be kept as implementation detail (but then I would need to abstract out the visitor to an inner class) Gabriel > > > the other way around would be to just overload the current > > PostPreProcessFilterSplittingVisitor constructor with a Capabilities and > > make the appropriate forks inside depending on whether it was fed with a > > geotools FitlerCapabilities (deprecated) or a Capabilities (non > > deprecated), and maintain both sets of unit tests while we don't remove > > the deprecated bits. > > That sounds a bit magic to me; and I always tripped up over the really > long name. > > Jody ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
