I can live with that.
> 1. Javascript Extension and Register
> ======================================
> Seeing as the new DynAPI code already requires changes to the usage of the
> files (which ones to include, etc).
> I'm proposing another idea, and this would be the perfect time, because it
> would require only 1 change, and hopefully not another change with another
> release after this one.
>
> We currently link in the dynapi.js file.. And the new dynapi.js file
> contains multiple objects.. I personally don't like that aproach (I think
> none of us did). My idea would be to make another file that needs to be
> linked in. This file is not directly part of the dynapi-cycle (no relation
> to objects in anyway) but would be one single file containing seperate
> functions like the include function.
>
> Basically this would be it (rough code, just typing it)
>
> <script language="Javascript" src="jsextend.js"></script>
>
> the file would include simple functions like:
>
> function include(src,path) {
> //blablabla
> }
>
> So basically we can put all the non dynapi related stuff in that file. The
> file name says it all, simply javascript extensions that should have been
> available in the official ECMA docs :) This way we can create all the code
> and other "systems" using the only include line for the jsextend.js file..
> All other source files are then linked in using the global function
> include().
>
> This also means we add functions like registerPackage() to register groups
> and library files.
>
> One step further would then be to have 2 default include lines:
>
> <script language="Javascript" src="jsextend.js"></script>
> <script language="Javascript" src="register.js"></script>
>
> The register.js file would contain all the registPackage() calls required by
> your project (website,webapp,game,etc). If you then want to include a
> certain widgetpack, that widgetpack will contain installation instructions
> specifying the lines you should add to the register.js file. This way, main
> projects need less updating when ever some idiot decides to change all
> filenames :)
> 1. Javascript Extension and Register
> ======================================
> Seeing as the new DynAPI code already requires changes to the usage of the
> files (which ones to include, etc).
> I'm proposing another idea, and this would be the perfect time, because it
> would require only 1 change, and hopefully not another change with another
> release after this one.
>
> We currently link in the dynapi.js file.. And the new dynapi.js file
> contains multiple objects.. I personally don't like that aproach (I think
> none of us did). My idea would be to make another file that needs to be
> linked in. This file is not directly part of the dynapi-cycle (no relation
> to objects in anyway) but would be one single file containing seperate
> functions like the include function.
>
> Basically this would be it (rough code, just typing it)
>
> <script language="Javascript" src="jsextend.js"></script>
>
> the file would include simple functions like:
>
> function include(src,path) {
> //blablabla
> }
>
> So basically we can put all the non dynapi related stuff in that file. The
> file name says it all, simply javascript extensions that should have been
> available in the official ECMA docs :) This way we can create all the code
> and other "systems" using the only include line for the jsextend.js file..
> All other source files are then linked in using the global function
> include().
>
> This also means we add functions like registerPackage() to register groups
> and library files.
>
> One step further would then be to have 2 default include lines:
>
> <script language="Javascript" src="jsextend.js"></script>
> <script language="Javascript" src="register.js"></script>
>
> The register.js file would contain all the registPackage() calls required by
> your project (website,webapp,game,etc). If you then want to include a
> certain widgetpack, that widgetpack will contain installation instructions
> specifying the lines you should add to the register.js file. This way, main
> projects need less updating when ever some idiot decides to change all
> filenames :)
I agree whole heartedly with the
following sentement..
:-)
> 2. Coding defaults
> ======================================
> I'm no fan of private/readonly/public variables, but I hate the fact that
> you can't see what variable is private (read: don't touch) and what variable
> is public. My idea would be to rename all variables that are private or
> readonly by adding an underscore infront of the names.. So in DynLayer this
> could become:
>
> myLayer._isDynLayer <- private
> myLayer._x <- readonly
> myLayer._y <- readonly
>
>
> This way when you use the code you know that you either a) shouldn't touch
> the variable, or b) there's a method to controll this variable. It should
> make things a bit clearer (once everybody gets used to these "rules") and
> would make the usage and debugging of 3rd-party widgets also a bit easier.
>
>
> --------------------------
> Any ideas on this subject?
> This is all still globally in my head, but I think it should prove a usefull
> thing.. Some of my other plans are to go into real war with Flash, already
> formed some ideas about how to tackle it.. but there for I need to see a
> real development-like DynAPI environment, that is even more API then it is
> now. Hopefully these changes can achieve that .. and if to many people
> disagree, I most likely take the current dynapi code and turn it into the
> next release of dynacore, with these changes, but that's something I don't
> want to do right now.
>
>
> well, it isn't that long is it?
>
> Pascal Bestebroer
> [EMAIL PROTECTED]
> http://www.dynamic-core.net
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
