qooxdoo events best practices

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

qooxdoo events best practices

mitya
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo events best practices

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

On 25 April 2016 at 21:22:17, Dimitri ([hidden email]) 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo events best practices

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

> 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 ([hidden email]) 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 
> > [hidden email] 
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel 

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel