I'll try to answer all 3 mails in one...
On 06/01/2011 05:12 PM, Derrell Lipman wrote:
> The following demo app displays all of the this.debug() messages in the
> Firebug console, even though neither of the appenders is being added.
> (Neither of the "Found qx.debug" console messages displays, but the
> initial "Testing for qx.debug" message does display.) How/why is the
> Console appender getting added? Why do the this.debug() messages display
> in the console if I haven't added that appender? Intentional or a bug?
> main : function()
> {
> var appender;
>
> // Enable logging in debug variant
> console.log("Testing for qx.debug");
'console' is browser API, not qooxdoo.
> if (typeof(qx.core.Variant) !== "undefined")
By mentioning qx.core.Variant you're creating a dependency to it. It
will be included in the build. If you try to build against a version of
qooxdoo that doesn't have qx.core.Variant (like the upcoming 1.5),
you'll get an "unknown symbol" warning.
> {
> if (qx.core["Variant"].isSet("qx.debug", "on"))
Even if qx.core.Variant is available, this way of referencing it
prohibits optimization. That means the following code will be included
with the build in any case.
> {
> console.log("Found qx.debug VARIANT");
> appender = qx.log.appender.Native;
> appender = qx.log.appender.Console;
> }
> }
At run time, the call to qx.core.Variant.isSet() will be executed, and
depending on the value of qx.debug, the code will be executed.
>
> // Enable logging in debug environment
> if (typeof(qx.core.Environment) !== "undefined")
> {
> if (qx.core["Environment"].get("qx.debug"))
> {
> console.log("Found qx.debug ENVIRONMENT");
> appender = qx.log.appender.Native;
> appender = qx.log.appender.Console;
> }
> }
The same reasoning applies to this section: qx.core.Environment becomes
a hard requirement of the build, the 'if' statement is not being
optimized, and the execution of the 'then' part depends on the value of
qx.debug at run time.
>
> var tzDate;
>
> this.debug("test 1");
Well, the appenders are available, and I think the logging system will
use Native. That's why all the this.debug() calls get displayed.
> tzDate = new timezonedate.TimezoneDate(0);
> if (this.assertEquals)
> {
> this.assertEquals((new Date(0)).getTime(), tzDate.getTime());
> }
> this.debug("date: " + tzDate);
>
> this.debug("test 2");
> tzDate = new timezonedate.TimezoneDate("1970-01-01T00:00Z");
> if (this.assertEquals)
> {
> this.assertEquals((new Date(0)).getTime(), tzDate.getTime());
> }
> this.debug("date: " + tzDate);
>
> this.debug("test 3");
> tzDate = new timezonedate.TimezoneDate("1970-01-01T04:00-04:00");
> tzDate.setOutputFormatter(tzDate.constructor._formatRfc2822);
> if (this.assertEquals)
> {
> this.assertEquals((new Date(0)).getTime(), tzDate.getTime());
> }
> this.debug("date: " + tzDate);
> this.debug(tzDate.format(240));
> }
> }
> });
>
>
and later ...
> In fact, pressing CTRL-D brings up the appender window onscreen too.
Are you talking about the qooxdoo console (usually with F7)?!
> This definitely seems like a bug. These appenders should exist in
> the build at all.
This should probably read "should _not_ exist", right?!
Well, as you mention them in code that doesn't get optimized away, they
are include. Ok?!
> Ok, the problem is that the test for qx.core.Variant is bringing it
> in even though that's not defined.
I don't get it. What does qx.core.Variant bring in? qx.core.Variant is
defined as soon as you mention it (s.above).
> What is the working method of supporting both qx.core.Variant and
> qx.core.Envrionment in contribs?
If you mean how to support them *at the same time*, you can't. There
were versions of qooxdoo that hadn't qx.core.Environment, and there will
be versions that won't have qx.core.Variant.
If you mean to have a code base that can be used under both versions,
you could use variants, you can't either. Theoretically you could have
switches in your code. Say you are working with qooxdoo 1.4. You could
add code like
if (qx.core.Environment.get("qx.version") !== "1.5") {
// add pre-qx.core.Environment stuff
if (qx.core.Variant.isSet("qx.debug", "on") { ... }
else {
// qx.core.Environment stuff
if (qx.core.Environment.get("qx.debug")) { ... }
}
As probably the two nested then blocks will be similar you might devise
a more clever scheme here.
Then you just need to set qx.version in your job configs accordingly and
compile for two different versions. It's sort of cross-compiling :).
But in practice this never gonna work, as a contrib doesn't have control
over the job definitions with which it is compiled. You could demand
that the user of the contrib add sufficient settings to its jobs, but
that would impose a lot of protocol. Not nice.
Best is, you create different versions of your contrib, one that works
with qx.core.Variant, the other working with qx.core.Environment. Much
cleaner. And the contrib demobrowser will thank you :).
> How do I get code to be excluded if
> NEITHER qx.core.Variant.isSet() nor qx.core.Environment.get() is true?
It is the wrong question. You could crumsily test for either of them, like
if (qx && qx["core"] && qx["core"]["Variant"]) ...
or something, but as I said above as soon as you mention the class, it
gets included (if it is available), and if you don't mention the class
the code doesn't get optimized. You cannot sniff the classes that are
the implementation tools of the variant optimization.
I hope this answers most of your questions.
T.
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
