shortcoming is not extanly the best word when describing some of the "problems"
I have been having.
With the memory problems, I wanted to develop a mehod of removing the individual
widgets from memory during unloading. This is only possible if we attach all of
the widgets to the window object. This is just one example.
There are also a lot of small coding irregularities that have become annoying
when updating the dynapi. There is still no single syntax for creation of
widgets. There are too many widgets that still create a new listener for each
widget. I am still to find a specific widget that requires a separate listener
for each widget.
I als don't like the current feeling that "if it ain't broke, don't fix it".
The move to reduce expansion until we have all the bugs out of the way is a
valid one. but it is also holding back some of the coding.
Examples:
- Thread should not use a method called "sleep" to alter the frame
rate. Sleep should be use solely for freezing the thread.
- We should still place many of the GUI base methods in a separate file
that is not loaded unless needed. I have successfully split the code so that
the dynapi.js file is as small as the pre 'X' original.
- The event structure is still too confusing. the DynEvent object
should be considered bart of the api and the key / mouse / listener code should
then extend the dynevent object. We should be moving towards a java-like
package code structure. I have been doing this for a few months now and have
had no problems.
I have raised a few of these problems in the past but there has been little if
any support and I didn't feel like devoting the time to convincing people to
take notice.
Richard Bennett wrote:
> Hi,
> > I currently believe that there are too many shortcoming in the dynapi that
> have not been adressed.
> Maybe it would be a good idea if we kept a list of these shortcomings.
> Many of them will have been addressed in peoples own work, but might not be
> publicly known.
>
> I should mention that version 2.5 was a great leap forward, especially the
> events handling. On the sites I updated little bugs like wrong mouse
> pointers, and strange events bubbling were gone!
>
> The shortcomings I find irritating are:
> * An unusable list widget. Probably best to drop it from the API, and let
> people develop their own. (Irritating because people keep trying to use it
> with 500 items, while it can only handle 10.)
> * Memory issues if you use to many layers. This might improve slightly
> still, but I think it's important to avoid it, by coding economically, not
> going overboard with a coverlayer, four border layers, a contentlayer, and a
> caption layer. Just use one layer, decorate it with css, and give it child
> <div>s for headings, captions etc. The css won't show in NS4, but I think if
> a widget remains usable, if less pretty, on NS4 that's fine.
> * A nice improvement would be that we could attach a css class directly to a
> DynLayer, like:
> myLayer.setClass('greenborder')
> That would save a lot of time, and we could keep a library of css classes.
> Again not 100% compatible with NS4, but degrading gracefully.
> * I still have some problems with mouse events on links in widgets with NS4.
> It's a lot better, but not 100% ok yet.
>
> What I like about the API:
> * The control. You can make things predictably, they show where you want,
> and do what they should.
> * The coding style. For the user I mean, it's flexible, and you can do what
> you want in you're widgets.
> I like "one line" compact coding, so I prefer:
> this.document.addChild(myLayer= new
> DynLayer(0,0,50,50,'red')).setHTML('hello');
> to:
> myLayer= new DynLayer()
> myLayer.setSize(50,50)
> myLayer.moveTo(0,0)
> myLayer.setBgColor('red')
> myLayer.setHTML('hello')
> this.document.addChild(myLayer)
>
> In DynAPI(javascript) you have a choice.
> * Dynamic loading. Yes, I like loadpanel. I've recently managed to get
> loadpanel to dynamically load and execute my javascript, and this has opened
> a lot of possibilities. Great.
> * The people! All of you who take time and interest to share your work for
> meager rewards, it gives hope in these days of ever commercializing of the
> internet.
>
> Cheers,
> Richard Bennett
>
> [EMAIL PROTECTED]
> www.richardinfo.com
> (Everything running on, and ported to DynAPI2.51)
> visit the DynAPI homepage (and FAQ) ::
> http://dynapi.sourceforge.net/dynapi/index.php?menu=1
> Browse (and search) the mailinglist here:
> http://www.mail-archive.com/index.php3?hunt=dynapi
>
> ----- Original Message -----
> From: "Michael Pemberton" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, May 03, 2001 6:38 AM
> Subject: Re: [Dynapi-Help] Forms on layers
>
> > I did not notice that there was a link to that page in the cods. I
> corrected
> > another reference but am having problems with my host.
> >
> > The code is almost ready for release. The code is NOT able to be directly
> > included in the dynapi. there has been to much extension for it to be
> just
> > inserted.
> >
> > If you want, I can email you the most recent version of the afroapi.
> There is
> > NO ns6 support do to java related problems. if you are willing to convert
> the
> > code back to being compatible with the dynapi, I'd be willing to give you
> a all
> > the assitance you need.
> >
> > I currently believe that there are too many shortcoming in the dynapi that
> have
> > not been adressed and am not developing code to be compatible with it.
> >
> > Again, if you want any of the most recent code, please email me as the web
> site
> > has not been developed to the point of being useful yet.
> >
> > Barbie wrote:
> >
> > > Firstly, a request to Michael Pemberton. Tried to use the FormWidget
> > > suggested in the Documentation pages on Source Forge
> > >
> (http://dynapi.sourceforge.net/doccenter/index.php?Is%20There%20a%20Form%20W
> > > idget), but nothing works, even your home page fails! In the index file
> > > within the zip I changed the setLibraryPath to the correct path ("src/"
> not
> > > "js/") and it still throws up errors. What else is required to get this
> to
> > > work?
> > >
> > > Secondly, I'm trying to access hidden fields within a form, which is
> within
> > > a label, which is within a scrolling pane. Unfortunately the form object
> > > seems to disappear! Any idea where it would be located. I had thought
> > > document.forms["myForm"] would work, or trolling through each layer's
> > > document.forms to find it, but to no avail. Anyone have any ideas?
> > >
> > > Barbie
> > >
> > > _______________________________________________
> > > Dynapi-Help mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-help
> >
> > --
> > Michael Pemberton
> > [EMAIL PROTECTED]
> > ICQ: 12107010
> >
> >
> >
> >
> > _______________________________________________
> > Dynapi-Help mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/dynapi-help
> >
>
> _______________________________________________
> Dynapi-Help mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-help
--
Michael Pemberton
[EMAIL PROTECTED]
ICQ: 12107010
_______________________________________________
Dynapi-Help mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-help
