Discussion:
qooxdoo events best practices
(too old to reply)
Dimitri
2016-04-25 19:43:49 UTC
Permalink
Hi,

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
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?

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.set("foo.bar", "baz");
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?

Cheers,
Dimitri
John Spackman
2016-04-26 05:50:47 UTC
Permalink
Hi Dimitri

Please can you ask this on StackOverflow?  We want to improve the Q&A and our SEO, and StackOverflow is a great way to do that.

Make sure you use the “qooxdoo” tag on your question - I think I’ll get an email as soon as you’ve done it (I only signed up myself yesterday) but if you want to post back here with a link that’s fine too.

Regards
John
On 25 April 2016 at 21:22:17, Dimitri (***@cargosoft.ru) wrote:

Hi,

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 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?

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.set("foo.bar", "baz");
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 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?

Cheers,
Dimitri
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
qooxdoo-devel mailing list
qooxdoo-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Dimitri
2016-04-26 14:12:39 UTC
Permalink
Done
http://stackoverflow.com/questions/36867110/qooxdoo-events-best-practices
http://stackoverflow.com/questions/36867416/overriding-qx-core-objectbind

P.S. There is also an interesting question that seems to have gone unnoticed:
http://stackoverflow.com/questions/35156009/controlled-event-handling-flow-in-qooxdoo
Could you please take a look?
Post by John Spackman
Hi Dimitri
Please can you ask this on StackOverflow?  We want to improve the Q&A
and our SEO, and StackOverflow is a great way to do that.
Make sure you use the “qooxdoo” tag on your question - I think I’ll
get an email as soon as you’ve done it (I only signed up myself
yesterday) but if you want to post back here with a link that’s fine
too.
Regards
John
Post by Dimitri
Hi,
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 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?
2. In my application, I've got a key-value store that implements
var config = new Configuration();
config.set("foo.bar", "baz");
config.get("foo.bar"); // "baz"
Dotted names are used to introduce configuration hierarchy. I also
config.bind("foo.bar", target, "property.chain");
The idea here is to use traditional qooxdoo 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?
Cheers,
Dimitri
-----------------------------------------------------------------
------------- 
Find and fix application performance issues faster with
Applications Manager 
Applications Manager provides deep performance insights into
multiple tiers of 
your business applications. It resolves application problems
quickly and 
reduces your MTTR. Get your free trial! 
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___________
____________________________________ 
qooxdoo-devel mailing list 
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel 
Loading...