On 6/23/06, James Margaris <[EMAIL PROTECTED]> wrote:
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.
I suppose. Note, though, that we could rely on just the 'minimal' profile of Dojo, which would get us the packaging system and a few other small pieces, without pulling in the rest of Dojo. That way, we don't have to wrap or reinvent, and there's only a minimal dependency. The Dojo mechanic is
a bit odd in a couple ways (like include dojo.widget.* doesn't include all widgets)
Yes, I agree this is odd, but I also agree with why it was done that way. It was done so that you could bring in all of the widget underpinnings easily, without dragging in all the actual widgets, since it would be exceptionally rare that you would actually want them all. 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)
I'm a Windows user, so I haven't tried it on a non-Windows system myself. However, I can tell you that the official Dojo releases are built in a Unix shell on a Mac, so ShrinkSafe itself (the custom Rhino you referred to) works fine in that environment. 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.
Right. That's what the Dojo packaging system does. 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.
True. If we could rely on all other packaging implementations to play nice together, that wouldn't be a big deal - and in fact it would be nice to have a single packaging system for ASF code. But would I put my own money on it? Nope. ;-) So I think a top level 'xap' is the way to go. -- Martin Cooper 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
