2016-04-25 19:43:49 UTC
1. 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
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
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?
2. In my application, I've got a key-value store that implements user
configuration (a la Apache Commons Configuration):
var config = new Configuration();
config.get("foo.bar"); // "baz"
Dotted names are used to introduce configuration hierarchy. I also want
the following to work:
config.bind("foo.bar", target, "property.chain");
The idea here is to use traditional qooxdoo ##SELECTION_END##binding
semantics; the difference is, "foo.bar" does not denote a real property
chain, it's merely a key name.
How should I implement this? Is it OK to completely override
qx.core.Object#bind with my implementation? Or should I model the
internals of Configuration class such a way that standard
qx.core.Object#bind (delegating toÂ qx.data.SingleValueBinding) would
work? The second scenario would probably involve some generated classes
(similar to whatÂ qx.data.marshal.Json#toClass does) to reflect key
names with real properties. Frankly, it seems a bit complex to me. What
do you think?