[ng-dhtml] directory structure

Alex Russell alex at netWindows.org
Thu Sep 16 13:56:38 CDT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.:
>
> import('foo.bar.baz');
>
> 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 
system.

Regards

- -- 
Alex Russell
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)

iD8DBQFBSeHmoV0dQ6uSmkYRApKSAKDPqJUrDe/mTk3dWfeF8a2wtoyY6ACghH4h
E+TmOHYgRFniK1sKp1PHXKs=
=qAdA
-----END PGP SIGNATURE-----




More information about the NG-DHTML mailing list