I haven't thought it throuhg with any great intensity,
but it seems sound.
> 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
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
