An example is: org.apache.jena.security.utils.RDFListSecFilter
Which filters results based on user access and is used whereever a RDFList (or an iterator on one) is returned . Claude On Fri, May 1, 2015 at 5:12 PM, [email protected] <[email protected]> wrote: > Oh, now I think I understand your point better. > > Yes, I have already trawled that code and worked over those reusable guys, > and yes, you will certainly still be able to combine and reuse Predicates > in the same way that you have used Filters. When I get this PR in, you can > see some examples of that. > > A Java 8 Predicate is just an interface that looks much like Jena's > Filter, which can benefit from the -> lamda syntax and which is designed to > fit into the Java 8 language APIs (e.g. for use with Streams). > > --- > A. Soroka > The University of Virginia Library > > On May 1, 2015, at 12:07 PM, Claude Warren <[email protected]> wrote: > > > We have a number of places where Filter objects are created and reused > > (usueally due to complexity or to reduce the code footprint in terms of > > debugging). Will it still be possible to define these complex filters > and > > use them in multiple places. > > > > The permissions system does this in that it creates a filter for RDFNodes > > and then applies them to the 3 elements in a triple to create a single > > filter for triples. > > > > There are several cases like this. > > > > I will have to look at the permissions code to find a concrete example, > but > > I think this is the case. > > > > Claude > > > > On Fri, May 1, 2015 at 4:53 PM, [email protected] <[email protected]> > > wrote: > > > >>> As for the Filter implementation..... will that be transparant to > filter > >> implementations? I assume so. > >> > >> I think this was in response to my question about Filter? > >> > >> If you mean that things that currently implement Filter (outside of > Jena's > >> own code) will not be greatly affected, then yes, so I would hope. I > will > >> @Deprecated Filter and its methods, but that seems to me to be all that > is > >> needed for this first step. > >> > >> I should have a PR with this later today, when you can observe some real > >> code and give me feedback. > >> > >> --- > >> A. Soroka > >> The University of Virginia Library > >> > >> On May 1, 2015, at 11:47 AM, Claude Warren <[email protected]> wrote: > >> > >>> I don't see any reason not to remove the Node functions. > >>> > >>> As for the Filter implementation..... will that be transparant to > filter > >>> implementations? I assume so. > >>> > >>> On Fri, May 1, 2015 at 4:16 PM, Andy Seaborne <[email protected]> wrote: > >>> > >>>> (mainly for Claude - I did check jena-pemissions and didn't see any > >> usage) > >>>> > >>>> There are a bunch of deprecated statics in Node (the correct way is to > >> use > >>>> NodeFactory) > >>>> > >>>> Node.createAnon() > >>>> Node.createAnon(AnonId) > >>>> Node.createLiteral(LiteralLabel) > >>>> Node.createURI(String) > >>>> Node.createVariable(String) > >>>> Node.createLiteral(String) > >>>> Node.createLiteral(String, String, boolean) > >>>> Node.createLiteral(String, String, RDFDatatype) > >>>> Node.createLiteral(String, RDFDatatype) > >>>> Node.createUncachedLiteral(Object, String, RDFDatatype) > >>>> Node.createUncachedLiteral(Object, RDFDatatype) > >>>> > >>>> It looks like they are not used by the jena codebase and are there for > >>>> compatibility only. > >>>> > >>>> Any reason not to remove them? > >>>> > >>>> Andy > >>>> > >>> > >>> > >>> > >>> -- > >>> I like: Like Like - The likeliest place on the web > >>> <http://like-like.xenei.com> > >>> LinkedIn: http://www.linkedin.com/in/claudewarren > >> > >> > > > > > > -- > > I like: Like Like - The likeliest place on the web > > <http://like-like.xenei.com> > > LinkedIn: http://www.linkedin.com/in/claudewarren > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
