For what it's worth, using the 'well performance uses charts' as an
argument it depended on dojo isn't entirely valid. It would use it
if it were available, otherwise it would not. At least in the way I
did it at the time:

if(doh.perfTestResults){
if(window.dojo){
//If we have dojo and here are perf tests results,
//well, we'll use the dojo charting functions
dojo.require("dojox.charting.Chart2D");
dojo.require("dojox.charting.DataChart");
dojo.require("dojox.charting.plot2d.Scatter");
dojo.require("dojox.charting.plot2d.Lines");
dojo.require("dojo.data.ItemFileReadStore");
plotResults = doh._dojoPlotPerfResults;
}else{
plotResults = doh._asciiPlotPerfResults;
}

If dojo wasn't available, it had a fallback mode that didn't have pretty charts.

Sincerely,
-- Jared Jurkiewicz
On Fri, Feb 3, 2012 at 9:13 AM, Alex Russell wrote:
On Feb 3, 2012, at 10:41 AM, Rawld wrote:

Not trying to start a fight, but your characterizations are incorrect
because [I think] you're not understanding the intended design: dojo can
now be sandboxed in DOH so that DOH *does not* depend on the code under
test unless you happen to be testing the same version of dojo as DOH is
using...which typically would not be the case.
On 02/03/2012 02:01 AM, Alex Russell wrote:
On Feb 2, 2012, at 7:11 PM, Rawld wrote:

I'm not sure exactly when the change was made to add a dojo.js
dependency, but I remember the rational...

DOH was always dependent on parts of dojo.
Untrue. And if true, easily fixed.
It was true--at least parts of one particular version of dojo--because
it used code from dojo.
That's a semantic dodge. Sorry. It was a small set of stuff that you could fit in a couple of screens. It was intentionally tiny. Difference in size == difference in type in this case.
It happened to be ccp'd. But it was dojo code
none the less.

And it is absolutely true that DOH depended on some of the dojo API.
Again, bug if so.
In the old days, those
dependencies were ccp from the dojo code stack over to the DOH code
stack.
That was an *explicit* choice on my part: the idea of a test harness depending on the code under test is *NUTS*. Completely bonkers. At a *minimum*, if there's a dep, DOH should have it's *own copy* of a *stable version* of that thing.
This misses the point of a sandboxed dojo. When you wrote DOH, you
didn't have that choice (at least easily).

The dojo that is used by DOH can be a different instance and/or version
of the dojo that is under test. You can test, for example, dojo 1.8
while DOH is using dojo 1.7. This is far better than ccp because you
decide which library DOH depends on by a configuration switch rather
than an editor.
Just to clarify: does that *usually* happen? I dont' see a separate copy of dojo.js checked in along side DOH. It's good that it can (and yes, I was somewhat unaware of how much different the brave new world is), but it's not clear to me that this happens in practice no matter how much easier it may be.
This resulted in the need to mx two copies of the same
code...which resulted in one of those copies rotting (DOH's). In fact,
DOH has become more and more janky over the years.
That's a question of interest and investment, not design and architecture.
See above.
The naive alternative--just depend on dojo.js--wasn't/isn't any better
(as you point out). This pollutes the test environment too much and may
be adjudicated as too heavy.
It is actively worse in at least 2 ways:

? ? ?1.) projects that just want DOH (as I happen to right now) no longer can do that without figuring out what web of dependencies they need to un-tangle. As it is, I'm just going to take the 1.6.x version and hack out all the other stuff in there that feels wonky to me. Yes, that's a fork...but at least I can do it easily enough.
I don't understand this.
? ? ?2.) instability in Dojo is now instability in DOH.
No. Configure DOH to use the exact version of dojo you would otherwise
cpp into DOH. DOH doesn't care. It just needs a library of functions.
I suppose that's fair enough, but the argument that you can't use DOH w/o Dojo now still stands. I see it as a regression.
Changing dojo != changing the dojo DOH depends on. In the old days,
changing the [parts of] dojo DOH depends on == ccp; now is means
changing a single config string.
Also, "pollutes the test environment"? 'Fo serious? Did you see how DOH was structured? It added one global. That's it.
The alternative of "just depend on dojo.js" does pollute the test
environment. That's exactly what you are unhappy about. I didn't say
that old DOH did that. In fact, I said that old DOH depended on a ccp
version of dojo, and that *that* design was not optimal now that we have
the ability to load sandboxed libs.
The wise alternative is to use only the particular modules of dojo
needed to impl DOH, and *push them into a private namespace* as is
possible with dojo's AMD loader. This way duplication of code is
eliminated and code doesn't rot, yet the test environment is not
polluted. This option is available with the "sandbox" url arg. It is
experimental in 1.7 and was working at one point, though I haven't
tested it in a while.
Again, bonkers. The point of a test system is to be isolated. Having dependencies from the *code under test* is *INSANE*.
Full circle: DOH *does not* depend on the code under test unless you
happen to be testing the same version of dojo as DOH is using...which
typically would not be the case.
_______________________________________________
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 38 | next ›
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedFeb 2, '12 at 1:30p
activeMar 2, '12 at 5:25a
posts38
users13
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase