[aerogear-dev] [iOS] Datamanager / AGStore

[Lucas Holmquist]

i like the idea of keeping it because in JS it serves a purpose,  but if it will cause problems for the other libs, then removing it now and adding it back in might be the better solution

On Feb 22, 2013, at 12:28 PM, Matthias Wessendorf <matzew at apache.org> wrote:

> I like the comment from Christos, on iOS;
> 
> Using a NSPredicate as the 'filter argument' makes sense for the overal iOS platform, and it should smoothly work with our current impls
> 
> -M
> 
> On Fri, Feb 22, 2013 at 6:25 PM, Kris Borchers <kris at redhat.com> wrote:
> JS has implemented a pretty generic and rather useful filter method :
> 
> https://github.com/aerogear/aerogear-js/blob/master/src/data-manager/adapters/memory.js#L281-L403
> 
> It is currently used in the JS TODO app. I am hesitant to remove it as it is useful and is one of the main useful features of DataManager for 1.0 other than it being a base for future development.
> 
> At the same time, I am leery of leaving it in if iOS and Android don't have something similar since this feature was not thoroughly discussed. I would hate to leave this in, only to have to deprecate it in a later release for something that we decide works better for all libs.
> 
> Other input would be appreciated.
> 
> On Feb 22, 2013, at 10:08 AM, Christos Vasilakis <cvasilak at gmail.com> wrote:
> 
>> +1 
>> 
>> (I was thinking on using an NSPredicate to match what is offered in Android, but let's revisit this with a proper API)
>> 
>> Thanks,
>> Christos
>> 
>> On Feb 22, 2013, at 5:49 PM, Summers Pittman <supittma at redhat.com> wrote:
>> 
>>> +1.  I have some implementations in Android, but they aren't great yet. (One throws an exception if you search for nested objects for instance).
>>> 
>>> 
>>> On 02/22/2013 09:17 AM, Matthias Wessendorf wrote:
>>>> Hi,
>>>> 
>>>> AGStore defines the following func:
>>>> 
>>>> -(NSArray*) filter:(id)filterObject;
>>>> 
>>>> Right now, there is NO implementation, so I'd vote to remove it.... Otherwise we will have this function around in future releases... 
>>>> If (later) we want some filtering (e.g. when more complex stores are around), we can define a proper API - instead of having some 'guess-ware' around...
>>>> 
>>>> 
>>>> FWIW, I created this ticket:
>>>> 
>>>> https://issues.jboss.org/browse/AEROGEAR-938
>>>> 
>>>> -M
>>>> 
>>>> 
>>>> -- 
>>>> Matthias Wessendorf 
>>>> 
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>> 
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> 
> -- 
> Matthias Wessendorf 
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130222/3bcb099d/attachment-0001.html