SearchBean Jim Talbut Wed, 10 Aug 2016 09:29:56 -0700 Hi, I'm trying to reuse the FIQL code (and possibly the ODP code) to implement a generic filtering mechanism for a data processing service. The data being processed can come from a variety of sources and its structure certainly won't be know at compile time. I have the data represented internally as an interface that is a very stripped down Map<String,Object> (it only implements get and forEach at the moment) - the data is presented to the filter one row at a time and can either be passed on or ignored. I have the FIQL code working using a SearchBean, but that involves copying all the data into the SearchBean, and then converting all the accessed fields into Strings. At the moment the FIQL code is quite tightly coupled to the SearchBean class - I can't directly use my QueryRow objects without either copying their data into SearchBeans or creating a new class derived from SearchBean and then overriding the getter. Would you be interested in making the Search API more usable with objects that don't fit either the POJO model or SearchBeans? One thought is to introduce a Beanspector interface and then give the parsers the ability to be given a Beanspector rather than create their own. I'd be happy to work on a patch if you think it'd be useful (won't be immediate, getting married in a fortnight!). Thanks. Jim Previous message View by thread View by date Next message SearchBean<Object> Jim Talbut Re: SearchBean<Object> Sergey Beryozkin Reply via email to Search the site The Mail Archive home dev - all messages dev - about the list Expand Previous message Next message The Mail Archive home Add your mailing list FAQ Support Privacy c74f7d16-c514-1ff2-5fdc-886a3bfe32b6@spudsoft.co.uk

[Jim Talbut]

Hi,

I'm trying to reuse the FIQL code (and possibly the ODP code) to 
implement a generic filtering mechanism for a data processing service.
The data being processed can come from a variety of sources and its 
structure certainly won't be know at compile time.
I have the data represented internally as an interface that is a very 
stripped down Map<String,Object> (it only implements get and forEach at 
the moment) - the data is presented to the filter one row at a time and 
can either be passed on or ignored.

I have the FIQL code working using a SearchBean, but that involves 
copying all the data into the SearchBean, and then converting all the 
accessed fields into Strings.

At the moment the FIQL code is quite tightly coupled to the SearchBean 
class - I can't directly use my QueryRow objects without either copying 
their data into SearchBeans or creating a new class derived from 
SearchBean and then overriding the getter.

Would you be interested in making the Search API more usable with 
objects that don't fit either the POJO model or SearchBeans?
One thought is to introduce a Beanspector interface and then give the 
parsers the ability to be given a Beanspector rather than create their own.
I'd be happy to work on a patch if you think it'd be useful (won't be 
immediate, getting married in a fortnight!).

Thanks.

Jim