We certainly need some sort of package/class include/declaration system.
We don't want to be tied too directly to any particular toolkit, so we could provide a thin wrapper around the Dojo stuff. The Dojo mechanic is a bit odd in a couple ways (like include dojo.widget.* doesn't include all widgets) but is a fine approach in general. We will certainly end up doing something similar if not outright the same. build.xml has a target called compile-tools and another called compress-source that use the Dojo compression stuff (their modified Rhino jar)to compress our files. That target is not part of the real build process right now, it has to be run separately. (For one thing I'm not sure how well it works on non-windows systems) My thought was we would combine that with a javascript file appending mechanism (throw all the javascript into a couple big files) and a package declaration/include system. As far as org.apache vs. xap, another point I thought of is that with an org.apache namespace the "org" object would be a top-level one, which is actually far less unique than "xap" as a top-level object. James Margaris --------- Martin Cooper wrote: I'm with you on both counts. The namespace approach is much more scalable, and also allows for automated package management, which would be much harder to do with a prefix approach. For example, Dojo's 'provides' and 'requires' mechanism is *very* cool, especially since you can use it for your own code, and for defining profiles, etc. I'm also fine with 'xap' as the root namespace. I don't think there's any requirement to add 'org.apache' to that, just for the sake of it. BTW, although it's not my favourite construct, you can often use JavaScript's 'with' construct if you _really_ want to shorten the code. On the other hand, if you use a compressor (e.g. Dojo's ShrinkSafe), then it's only an issue with writing the code, which, as you say, several editors will help you out with anyway. -- Martin Cooper
