[ng-dhtml] directory structure
alex at netWindows.org
Thu Sep 16 13:56:38 CDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 16 September 2004 11:26 am, Cal Henderson wrote:
> David Schontzler wrote:
> : Well, I think that we'll probably want to combine some classes in
> : a single file in some cases, but I'm sure we can set it up to
> : combine files during build time. That said, one file per class
> : should be fine.
> this is what i was thinking - lay it out very simply (one class
> per file) but use the build process to package it into bundles.
> that would seem to meet our needs of being easy to develop and
> fast to load in production.
I guess on top of this, I can see a package concept which will provide
to the script loader/importer the kind of location information you're
talking about. This package description should probably no need to do
anything in order to use the class-per-file layout, but in the case
where I might have multiple classes in a single file, it should allow
the loader to specify which classes they want and have it get mapped
back to the file.
I can see multiple reasons for wanting such a beast. Firstly, in the
case where I've got a lot of little classes, having multiple files
isn't a virtue. In this case, having them in one file and having the
package description mention as such to the loader is preferable (esp
for core things). Secondly, when we get into widgets which may have
several renderings (HTML, SVG, other (flash?) ) we will need a way to
let the loader figure out what to load based on the needs of the
renderer. A package system that lets us roll-up the various versions
of a particular widget when targeting one type of environment will
help solve on of the nastier problems I've got when envinsioning
having template files, per-rendering specialization JS files, and
base-widget interface files for every widget in the toolkit.
> perhaps the loader/importer gets generated at build time so that
> it knows which classes are where, e.g.:
> imports /src/foo/bar/baz.js at dev time and /src/foo_lib.js at
> production time.
Agreed. I like this import syntax. My only addition would be to let
the package foo.bar inform the loader that what it needs is in
_either_ baz.js or foo_lib.js without a dependency on the build
alex at burstlib.org BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
alex at netWindows.org F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----
More information about the NG-DHTML