>
> Maybe functions like removeFromArray and splice can be attached to the
> Array prototype, then it would really js extensions. Also we could have
Agreed.
> 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.
This is a DAMNED good idea, then all widgets can simply have something like,
if (!IsRegistered("dynapi.gui.label")){
DynAPI.include("dynapi.gui.label");
}
This would be done in 'precreate' I would imagion.
> 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.
I'd be happy with DynAPI 2.5, and the acknowledged involvement of the team
in
preparing 2.5 for realease: this inludes bug hunting, yes, but does NOT
include adding anymore functionality, and MOST CERTAINLY would include
Documentation.
> 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
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
