ArrayHelper and other helpers

[James Margaris <jm...@nexaweb.com>]

I want to come up with a standard helper type of class format, where a
helper is defined as a class that adds additional functionality to an
existing javascript class.

I don't think we want to modify object definitions directly, that could
have some problems when people start mixing in conflicting toolkits.

If you look at xap.util.ArrayHelper, it always takes an array as the
first argument. I would like to remove the "Helper" part and just have
the formula where

"xap.util.XXXX" is a helper class if XXXX is a standard JS class. Maybe
instead of xap.util this should be under xap.lang or xap.js or something
like that?

Thoughts?

James Margaris

Dojo.require() and stack overflow issues

[James Margaris <jm...@nexaweb.com>]

So I hit an interesting problem today. Apparently in IE if you have a
file that requires another file that requires a third file etc etc you
can get a stack overflow error somewhat quickly. (After about 10 levels
of nesting or so.)

Thinking of ways to avoid this, one thing I think would make sense would
be to organize things like utils so that it has a package-level listing,
and structure that so that things required by other thing are on top.
For example, Hashtable requires Exception. So if we list them like:

Hashtable
Exception

When hashtable is loaded it will then load exception. If we list them
like:

Exception
Hashtable

Then when Hashtable is loaded Exception has already been loaded first.
If exception itself requires other classes this can save a few stack
frames. 

---

This is more a problem with unit tests right now as a real application
should run against a compiled profile that should have more things baked
into it rather than a bunch of nested requires.

James Margaris

RE: ArrayHelper and other helpers

[James Margaris <jm...@nexaweb.com>]

Yes you may be right, leaving the "Helper" on is probably better, although xap.helpers might be better than xap.util. Right now util is a collection of a whole bunch of junk that isn't all that similar. xap.helpers would be pretty straightforward.
 
Right now we just just Array but we need String as well. (I have some code that sticks a toString() onto a string directly that I need to remove) I can also see something like XmlHttpRequestHelper being useful in the future.
 
James Margaris

________________________________

From: Michael Turyn [mailto:MTuryn@nexaweb.com]
Sent: Wed 9/20/2006 8:44 PM
To: xap-dev@incubator.apache.org
Subject: RE: ArrayHelper and other helpers



>If you look at xap.util.ArrayHelper, it al-
>ways takes an array as the first argument.

This seems natural and simple.

I'd propose a further (and particularly uninspired) convention
that when a Java method exists, it be used:
       aString.trim()  --->  StringHelper.trim(aString)
or
       aFoo.bar(a_0,...,a_n)  --->  FooHelper.bar(aFoo,a_0,...,a_n)



>I would like to remove the "Helper" part and just
>have the formula where "xap.util.XXXX" is a helper
>class if XXXX is a standard JS class.

This does not seem natural or simple; to have a class named "xap.foo.String"
or "xap.blah.Array" seems like a recipe for future confusion; I think
appending a "Helper" isn't so bad and accurately describes the class.


>Maybe instead of xap.util this should be under xap.lang or xap.js
>or something like that?
Well, if we _do_ do it that way, I'd prefer
          xap.helpers.String
(but just look at that name---it looks like it's a string in itself....)

RE: ArrayHelper and other helpers

[Michael Turyn <MT...@nexaweb.com>]

>If you look at xap.util.ArrayHelper, it al-
>ways takes an array as the first argument. 

This seems natural and simple.

I'd propose a further (and particularly uninspired) convention 
that when a Java method exists, it be used:
       aString.trim()  --->  StringHelper.trim(aString)
or
       aFoo.bar(a_0,...,a_n)  --->  FooHelper.bar(aFoo,a_0,...,a_n)



>I would like to remove the "Helper" part and just 
>have the formula where "xap.util.XXXX" is a helper
>class if XXXX is a standard JS class.

This does not seem natural or simple; to have a class named "xap.foo.String"
or "xap.blah.Array" seems like a recipe for future confusion; I think 
appending a "Helper" isn't so bad and accurately describes the class.


>Maybe instead of xap.util this should be under xap.lang or xap.js 
>or something like that?
Well, if we _do_ do it that way, I'd prefer
          xap.helpers.String
(but just look at that name---it looks like it's a string in itself....)