Related to GC and destroy().
I see destroy being used in two ways.
1) The conventional method of "page based" navigation that requires
throwing more or less a DOM object tree of nodes in the trash.
and..
2) A more eloquent (like the arced flight of a well thrown rock) integrated
GUI that dynamically brings content "pods" (similar but not the same as a
rock, kinda like a softrock ala hardware/software) into a preconstructed
GUI. These "pod based" widgets would require two kinds of close buttons, of
which you would choose one of the two alternatives during widget
specification and design. One that is simply a setVisible(false) [keep me
around] and another that explicitly call a "nodal pod destroy()". This is
important because this "more eloquent and rather amazing" style of GUI
design has a greater potential for collecting "digital dust" in the form of
abandoned content pod viewing sub-windows.
I hope I made perfect sense.
In summary, we need the ability to call a destroy on an object by object
basis.
----- Original Message -----
From: "Jordi - IlMaestro - Ministral" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 12, 2001 11:50 AM
Subject: [Dynapi-Dev] DynAPI X
> ( Takes deep breath, puts helmet on, tells mom he loves her in case he
doesn't
> make it back )
>
> Seeing that this list has lately been a very boring and quiet lake of
peaceful
> coding, allow me to throw a new disturbance focus.
>
> For the last days/weeks we've been undergoing a very heavy rewrite of the
API.
> Since it was not a matter of lines but a very big rewriting, we decided to
keep
> it quiet and parallel. If we had started chaging stuff in CVS without
testing
> and warning, we might have been flooded with "what's going on" messages
and
> honestly that was the last thing I wanted. Not that other people's
opinions are
> not considered be we did want to have some consistent stuff before leting
it
> into the crude Arena of this forum.
>
> First of all: it is backwards compatible. As I will explain later, the
only
> thing which has changed is the event stuff, which is no longer in the api
> package but has its own, evnt. You will have to change one line in your
> includes.
>
> Second: this is work in progress. Expect things that have already been
fixed to
> reappear. However, you will notice that everything is now much much
cleaner,
> and if property .doc for your layer is not properly set, you won't have to
> search two or three methods.
>
> Third: there are a reasonable amount of comments. This makes files bigger,
but
> we want it clear this time.
>
> Fourth: an initial look at dynapi.js will make you thing that there's a
lot
> more code than it was. In fact the only file that increased in size was
> dynapi.js, allowing the specific files to me much smaller and cleaner.
>
> Fift: i have included a generic method that allows to add lines of code to
> already defined methods. So if you look at dynlayer.js and you can't see
any
> eventcapturing code, don't be puzzled. If you open mouse.js ( where the
> mouseevents are now ) you will see a call to
> addCode("createLayer","this.captureMouseEvents()"). This way of working
makes
> it possible for optional files ( mousevents ) to add stuff to already
defined
> methods, without having to have ugly if(mouseEvent)
this.captureMouseEvents()
> lines and such. Besides, this way we have eradicated crossreferences
between
> files.
>
> Sixth: I've tried to keep in mind all the suggestions that I could
remember
> going throught the list, as well as provide an structure that allows a
rational
> growth. To me this was more important than particular browser issues (
helmet
> on :) ) because once the structure is solid improvements are easier.
>
> Seventh: I'm sure there's lots of missing stuff. Not every extension has
been
> rewriten. If you can take it as a brave foolish effort of organization and
stay
> with the older code. What I don't want is people to expect this code to do
> better cross-browsing than the older does. It is an initial release.
>
> Eigth: Any feedback is welcome. Constructive and destructive. If I
couldn't
> take criticism or flaming I would be here in the first place :). I've got
some
> things pending ( a definitive DOM event bubbling fix, this time I've got
it by
> the balls, I promise ) that I would want to implement this week.
>
> That said, here goes a bit of description:
>
> DynObject: everything is now a dynobject. A DynObject is an object that
manages
> a list of children DynObjects, proving the addChild and delete stuff. A
destroy
> method has been provided. It doesn't work very well, but since now
EVERYTHING
> is a DynObject and there's one single hierarchy of DynObjects, once the
destroy
> method works then the memory issues should vanish.
>
> Identifiers. Each Dynbject automatically receives a unique identifier
during
> contruction. It is always available ( before and after creation ) and
should
> remove the need of explicity setting pointers to global variables an other
> reated tricks maily used in setTimeout animations.
>
> DynAPI: dynapi is the same it was ( with slight modifications allwing
> extensions to add custom code to the onload method ) but it inherits from
> DynObject. To the DynAPI you add Childs which are DynDocuments. To
DynDocuments
> you will add DynLayers, you get the point.
>
> DynDocument: more or less the same
>
> DynLayer: much nicer code, much faster creation code. The code that
changes
> properties is the same, still have to see that, only creation and deletion
has
> been rewriten.
>
> Events: now a separate module that is not manadatory. You can include the
> simple.js package and then when you do a invokevent("create")
object.oncreate()
> is executed. You can include listeners.js and then you've got the listener
> stuff. This does not provide mouse support but liustenrs to default events
such
> as create. Include mouse.js and then you've got mouse events. Include
> keyboard.js and you get keyboard events.
>
> Drag: still pending. Sorry
>
> GUI: included the buttonimage example as well as the images that go with
it.
> Hey Raymond, we hadn't forgotten after all.
>
> -- Where to find: available through CVS as module 'dynapix'
>
> Ok, there you go. Shall the battle begin.
>
> ( takes deep breath, looks around, panics and runs away )
>
>
>
> _______________________________________________
> 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
