[ng-dhtml] directory structure

David Schontzler schontz at gmail.com
Thu Sep 16 14:06:58 CDT 2004


Actually, on second thought, I think I'd prefer that less be done
during build time so maybe we shouldn't break things up with the
thought that the build will put them together.

I'm tired though, so who knows.


On Thu, 16 Sep 2004 11:56:38 -0700, Alex Russell <alex at netwindows.org> wrote:
> -----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-----
> 
> 
> 
> 
> _______________________________________________
> NG-DHTML mailing list
> NG-DHTML at netwindows.org
> http://netwindows.org/mailman/listinfo/ng-dhtml_netwindows.org
>



More information about the NG-DHTML mailing list