Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
To: dev@cxf.apache.org
From: Jim Talbut <jtalbut@spudsoft.co.uk>
Subject: SearchBean<Object>
Message-ID: <c74f7d16-c514-1ff2-5fdc-886a3bfe32b6@spudsoft.co.uk>
Date: Wed, 10 Aug 2016 17:29:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Wed, 10 Aug 2016 16:29:32 -0000

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