Loading ...
Sorry, an error occurred while loading the content.

Re: [taffydb] Re: Using TaffyDB? Attending JSConf?

Expand Messages
  • Jon Crosby
    ... That would be very helpful. If one could attach more than one event and they could each be sync/async as needed, that would take care of a large number of
    Message 1 of 8 , Mar 30, 2009
    • 0 Attachment
      On Sun, Mar 29, 2009 at 4:47 PM, tacoman_cool <ian@...> wrote:
      > Thanks for the details. Those both sound like great additions.
      > One thing I've been thinking about is rewriting the event API to make it more flexible (and to potentially add more events). So there would be a collection.attachEvent() and a collection.removeEvent()...potentially they could also encapsulate the ability to call the events asynchronously.

      That would be very helpful. If one could attach more than one event
      and they could each be sync/async as needed, that would take care of a
      large number of use cases.

      > Also, tell me if this would to care of your map needs. I've though about returning an "enhanced" array from get() that is actually a modified version of a taffy collection (in array form). This would allow for a type of JQuery style chaining. For example you could call collection.get({status:"active"}).orderBy("createDTG").forEach(function (r) {alert(r.name})
      > So in theory you could call .get().forEach() to take care of your mapping needs.

      I like the forEach chaining idea although it would still expose the
      hidden elements in my collections to the user, requiring them to run
      the forEach on all result sets. This is an unusual situation though,
      that of CloudKit wrapping TaffyDB instead of using it directly, so
      others may be better suited to comment on this feature.


      > Let me know your thoughts.
      > Ian
      > > Sure thing. The purpose of the adding "map" to the configuration is to allow
      > > a function to be applied to the output of get. For example, in CloudKit, I
      > > need to store a metadata ID in the database in order to map it to a parallel
      > > local database that contains only HTTP metadata (like ETag, Last-Modified,
      > > URI, etc.). By configuring the collection with a mapping function, I can
      > > express that each result in a set of JSON objects should not include the
      > > metadata ID (i.e. a function that runs delete
      > > item['___cloudkit_local_id___'] on each member of the collection.
      > >
      > > The async patches account for the fact that a callback for insert, update,
      > > and delete might not be instant. In the jQuery CloudKit plugin, I have added
      > > callbacks for these functions that make network calls to CloudKit. This
      > > allows the browser to stay responsive while a request is running in the
      > > background. When the result of the request is returned, I update the local
      > > metadata with the information reported by the server or take action if there
      > > was an error.
      > >
      > > Both of these items would probably make useful additions to the core
      > > library. The map function would not affect the current API whereas the async
      > > callback patch is a little more intrusive and adds complexity in the cases
      > > where it is not necessary. If there was a way to have two types of callbacks
      > > -- sync and async -- that would solve the problem.
      > >
      > > -Jon
      > >
    Your message has been successfully submitted and would be delivered to recipients shortly.