I don't think I could have said that any more elegantly.
:-)
> > 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
>
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
