> myLayer._isDynLayer <- private
> myLayer._x <- readonly
> myLayer._y <- readonly
This would mean re-writing everything, almost every widget or webpage,
wouldn't a comment in the code be enough?
>Some of my other plans are to go into real war with Flash
Is this being realistic? If you mean taking DynAPI to the next level of
professional acceptance I agree, but there's a place for Flash, a place for
Dreamweaver, and a place for DynAPI.
I think we should build on the qualities of DynAPI, build serverside
interaction, and promote it (in as far as we do) as a professional package
for businesses to build web apps, not for animations or movies for which
Flash is better suited. Not for lightweight sites where Dreamweaver is
quicker, and not for MSDN type of things, where frames and asp or php are
more efficient.
Know our strengths, but recognize the weaknesses too, and find our place in
the market. Show what is possible, and create the need for DynAPI in it's
own right.
I know how you like discussing these things at length ;O)
Richard
----- Original Message -----
From: "Pascal Bestebroer" <[EMAIL PROTECTED]>
To: "Dev" <[EMAIL PROTECTED]>
Sent: Wednesday, March 28, 2001 7:19 PM
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
