2

In my application, I'm loading/saving some data from/to qx.io.rest.Resource. To hide the complexity of REST, I want to expose a simplified, high-level interface to application components; think of load()/save() methods and some events to monitor progress of operations.

In this scenario, there is a total of six events: [ load, save ] x [ starting, success, failure ]. (I'm not interested in monitoring amount of data transferred, since a typical request will consist of less than 1KB.)

What is the best/preferred way to model this event scheme? Do I use single event type and pack all the info into event data, or do I use different event types? Should I extend qx.event.type.Event, or should I adopt an existing class like qx.event.type.Data?

Dimitri
  • 301
  • 2
  • 13

2 Answers2

3

It largely depends on the natural usage pattern of your events; for example, if any code which wants to know progress will typically need to subscribe to all three of [starting, success, failure ] then it would more more appropriate to add a "progress" event of type qx.event.type.Data, and the data would contain finer grained information.

This is a common pattern in Qooxdoo - for example, look at qx.data.Array and it's "change" event. The data of the event includes information about what the change is, but there is only one event to listen to.

"load" and "save" are pretty different events, so perhaps you'd end up with "load", "save", and "progress"

johnspackman
  • 980
  • 4
  • 10
  • By [ load, save ] x [ starting, success, failure ] I meant Cartesian product of event types, giving the following six: load-started, load-success, load-failure, save-started, save-success, save-failure. I think I should implement two event types (load and save), each of them being fired per each processing phase (started, success, failure). – Dimitri Apr 26 '16 at 14:44
2

I'm using a mixin mylib.io.MREST where I have the following events defined:

   events:
   {
    "load"        : "qx.event.type.Event",
    "loadSuccess" : "qx.event.type.Data",
    "loadError"   : "qx.event.type.Data",

    "save"        : "qx.event.type.Event",
    "saveSuccess" : "qx.event.type.Data",
    "saveError"   : "qx.event.type.Data",

    "del"        : "qx.event.type.Data",
    "delSuccess" : "qx.event.type.Event",
    "delError"   : "qx.event.type.Event",
  },

These correspond to the REST paths load, save and del using the request methods GET, PUT, DELETE with qx.io.rest.Resource.

The events load, save and del are fired on start whereas methodSuccess, methodError are fired on, well success or error ot the transport.

Methods load, save, del are implemented to start those actions, sending an object id a sessionid and some payload as JSON.

level420
  • 829
  • 5
  • 8