Finally got of my thinking-plane, and here's the result..
I'm gonna try and make this as short as possible:
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 :)
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
