[ng-dhtml] directory structure
ng-dhtml at dept-z.com
Thu Sep 16 15:42:20 CDT 2004
I'm in New York for a spell, so answering or looking over the list will be sporatic (sp?) for a few days...
That being said, what has been described so far is pretty much exactly the way I did it with f(m), so maybe taking a look at that and seeing if it will work for this project.
As far as one class per file...I personally do not like this approach, as it really does make for increased maintenance. My approach has been (so far) to consider a file a "package", and put related classes within that file.
Note that for f(m), I did *not* consider a package and a namespace to be the same thing; I had no problem writing different classes/packages to work within the same basic namespaces. I think that this may be a distinction we'd like to keep in mind, especially when it comes to things like choosing which rendering packages to load (a la Alex's example), etc.
One other thing I should mention: the use of the lower-case "import" will probably not be ok, as at least Mozilla has reserved that as a keyword (one of the main reasons why I used proper case in f(m)).
Talk to y'all.
---------- Original Message ----------------------------------
From: David Schontzler <schontz at gmail.com>
Reply-To: david at stilleye.com,discussion on the future of DHTML <NG-DHTML at netwindows.org>
Date: Thu, 16 Sep 2004 12:06:58 -0700
>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
>> - --
>> 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)
>> -----END PGP SIGNATURE-----
>> NG-DHTML mailing list
>> NG-DHTML at netwindows.org
>NG-DHTML mailing list
>NG-DHTML at netwindows.org
More information about the NG-DHTML