I'll do the changes this time :) I'll try to do the main stuff this
weekend..
Pascal Bestebroer
[EMAIL PROTECTED]
http://www.dynamic-core.net
> -----Oorspronkelijk bericht-----
> Van: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]Namens Jordi - IlMaestro
> - Ministral
> Verzonden: woensdag 28 maart 2001 20:09
> Aan: [EMAIL PROTECTED]
> Onderwerp: Re: [Dynapi-Dev] structure change ideas
>
>
> Not that it makes me specially happy having to rename lots of
> things again,
> creating typos and so, and then receiving lots of mails about .created not
> existing anymore, but I think it is a good idea to have such thing.
>
> Ok, I agree. Just give me some rest first :)
>
> Jack_Speranza wrote:
>
> > I'm not a developer on this project, but it sure makes eminent
> sense to me!
> > No rocks being flung from this little spot on my side of the
> Atlantic ;-)
> >
> > -----Original Message-----
> > From: Pascal Bestebroer [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 28, 2001 12:19 PM
> > To: Dev
> > Subject: [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
>
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
