in my case, I know the class name only at the runtime, and not at the coding 
time, 

so the method porosed by Adrian is the right one.

Here's what I finally do:

line 59 in 
https://github.com/ssinyagin/gerty-reports/blob/master/frontend/source/class/gertyreports/Application.js


also config.json needed a bit of a tweak: the build system has to know all 
dynamically added classes:
line 49 in
https://github.com/ssinyagin/gerty-reports/blob/master/frontend/config.json.in



> From: thron7 <[email protected]>

> To: qooxdoo Development <[email protected]>
> Sent: Sun, February 27, 2011 4:07:40 PM
> Subject: Re: [qooxdoo-devel] creating objects of dynamic types
> 
> > Hi.
> >
> >> Here's a little code to make you an idea about  using qx.Class.getByName.
> >>
> >> qx.Class.define("Bacon",  {
> >>   extend: qx.core.Object,
> >>   construct:  function(foo, bar) {
> >>     this.foo = foo;
> >>      this.bar = bar;
> >>   }
> >>  });
> >>
> >> var klass = qx.Class.getByName("Bacon");
> >>  var obj = new klass("foo", "bar");
> >>  this.debug(obj.foo);
> >
> > IIRC, you also have to have something like  #require("Bacon") or such in
> > the file where you want to instantiate  Bacon objects, if you only
> > instantiate Bacon objects by name. Otherwise  the build process won't know
> > to include the Bacon class in the generated  script.
> 
> It really depends. What you address is the case where you have a  normal
> qooxdoo class (i.e. a class statically defined in its own file within  a
> library), and then you use the qx.Class.getByName() call in some  arbitrary
> other class. Then, yes, using a #require hint is one of the means  to
> ensure the Bacon class will actually be included in the build, and  is
> available at run time.
> 
> But the code example seems to indicate a  different situation. As the call
> to qx.Class.define() is just a normal  function call, you can use it
> basically anywhere in the code to create  classes on the fly. Not the
> recommended way to do that, but sometimes handy  (The framework unit test
> code uses this a lot, see e.g.  qx.test.core.Variants). But classes created
> on the fly this way are not known  to the generator (there is no deep
> inspection for calls to qx.Class.define  and the like), so it's also no use
> to mention them in a #require hint (the  generator wouldn't recognize them
> there either).
> 
> One more thing: After  the call returns, you know the class you passed as
> argument is available for  normal use, so you don't even have to resort to
> qx.Class.getByName(), you can  use the class name directly:
> 
> qx.Class.define("Bacon", ...);
> 
> var  bacon = new Bacon("foo", "bar");
> 
> So .getByName() is really only necessary  if you cannot write down the name
> of the class at coding time, but is a  dynamic value at run  time.
> 
> T.
> 
> 
> ------------------------------------------------------------------------------
> Free  Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT  
> data 

> generated by your applications, servers and devices whether physical,  virtual
> or in the cloud. Deliver compliance at lower cost and gain new  business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> qooxdoo-devel mailing  list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to