Re: [Dynapi-Dev] structure change ideas

[Jordi - IlMaestro - Ministral]

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