Maybe functions like removeFromArray and splice can be attached to the
Array prototype, then it would really js extensions. Also we could have
something like registerFile, that is called at the top of every dynapi file is
included. Then requireFile(), can be used to make sure that all of
the right packages/files are included.
I'm not sure if we should/could do this with the next release. Then,
it would not really be DynAPI 2, but really DynAPI 2 and 3/4. That
would mean a lot of restructuring. No problem for me, but for others
it may be. Plus all of the documentation would need to be changed as
well. If enough people want to get involved and help out that would
be fine, but if not then it would be difficult to update all of the
info.
Perhaps, now would be a good time to move on to DynAPI 3. Maybe
DynAPI 3 will be the first release that truly supports the dom and
Mozilla 1.0 (NS 6).
I'll save my judgement until I see it :)
--
Robert Rainwater
On 3/28/2001, 12:19:09 PM EST, Pascal wrote about "[Dynapi-Dev] structure change
ideas":
> 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
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
