I'm a little confused. A user developer of DynAPI would want to pick and
choose which modules he'd/she'd want to include. What modules whould
jsextend include? And wouldn't people just modify to suite thier needs? In
which case, wouldn't it be better as a suggestion opposed to a new file part
of the DynAPI distribution?
On a slightly related topic, I had an issue/problem coordinating different
parts of my site. I'm using server side scripts to assemble pages. As
such, different areas of my page that used DynAPI weren't "allowed" to know
about each other. This caused some grief which I solved with the following
code:
DynAPI.addOnLoad = function (code) {
if (!DynAPI.onLoadRoutines)
DynAPI.onLoadRoutines = new Array()
DynAPI.onLoadRoutines[DynAPI.onLoadRoutines.length] = code;
}
DynAPI.onLoad=function() {
for (var i=DynAPI.onLoadRoutines.length -1; i>=0; i--)
DynAPI.onLoadRoutines[i](this)
}
So, each independent DynAPI module could call addOnLoad(). I think I'll
needed something similar for resizing. Not sure if there was a better way
to handle it.
Ken
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Pascal
> Bestebroer
> Sent: Wednesday, March 28, 2001 1:47 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Dynapi-Dev] structure change ideas
>
>
> 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
>
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
