dynapi-dev — List related to the current DynAPI Core development

RE: [Dynapi-Dev] DynAPI build, Splitting files

[Darin K. <dka...@ef...>]

Amen.

-----Original Message-----
From: Scott Andrew LePera [mailto:sc...@sc...]
Sent: Wednesday, December 06, 2000 3:21 PM
To: dyn...@li...
Subject: Re: [Dynapi-Dev] DynAPI build, Splitting files


If there's going to be any splitting, I think it should only be done in
the core files and maybe some of the heavier extensions.  I'd rather not
have to create split versions of a widget; at that point, it stops being
cross-browser, so why bother having an API? It would be difficult enough
just to maintain the core files for all browsers.

-- 
scott andrew lepera
-----------------------------------
web stuff:     www.scottandrew.com
music stuff:   www.walkingbirds.com
_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: SV: [Dynapi-Dev] DynAPI "require" method?

[Scott A. L. <sc...@sc...>]

I once tried doing exactly this by placing DynAPI.include statements at
the top of my widget scripts, but Brandon is right -- after a certain
point, the browser hangs up (primarily in IE), and it was very
unpredictable.

-- 
scott andrew lepera
-----------------------------------
web stuff:     www.scottandrew.com
music stuff:   www.walkingbirds.com

Re: [Dynapi-Dev] DynAPI build, Splitting files

[Scott A. L. <sc...@sc...>]

If there's going to be any splitting, I think it should only be done in
the core files and maybe some of the heavier extensions.  I'd rather not
have to create split versions of a widget; at that point, it stops being
cross-browser, so why bother having an API? It would be difficult enough
just to maintain the core files for all browsers.

-- 
scott andrew lepera
-----------------------------------
web stuff:     www.scottandrew.com
music stuff:   www.walkingbirds.com

SV: [Dynapi-Dev] DynAPI build, Splitting files

[Bart B. <ba...@ho...>]

True.. I don't see how people can miss the obvious advantages of having browser specific code.
Yes, it might be a hassle if you only have to do a couple of browser flagging here and there... but DynAPI is pretty complex... and growing.
Don't want to be a parrot .. but here goes anyway:

1. Speed - you can implement more browser specific solutions that will increase speed:execution of code and rendering (such as perhaps VB code... actually some things you CANNOT do without VB.. printing frames from another frame in IE4, for instance)
2. Clarity - doing the above mentioned in the current library would make it even more obscure than it already is.
3. Size - the code the end user will have to dowload will be very optimized and will not contain reduntant code.
4. Modularity - right now everything depends on browser.js. And a lot more of the code is inter-dependant quite extensivly. This could more easily be improved upon through separating general and browser-specific functionality.
5. Just for the hell of it - Which I believe to be the most important reason...  ;-)

/ Bart


-----Ursprungligt meddelande-----
Från: Brandon Myers <bnd...@ho...>
Till: dyn...@li... <dyn...@li...>
Datum: den 6 december 2000 23:11
Ämne: Re: [Dynapi-Dev] DynAPI build, Splitting files


>(Oh.. and Dan.. not only do DynLayer/DynDocument and LoadPanel have specific
>code, DragEvent and several other extentions have much browser specific
>code.)
>Drag event code could really be improved by splitting it. IE could use VB
>enhancements (I know.. it's not JS..) to give it better performance.
>
>----- Original Message -----
>From: "Dan Steinman" <dy...@fu...>
>To: <dyn...@li...>
>Sent: Wednesday, December 06, 2000 3:44 PM
>Subject: Re: [Dynapi-Dev] DynAPI build, Splitting files
>
>
>> The only files in the DynAPI that are browser related are DynLayer,
>DynDocument, and Loadpanel.  So if everyone feels we should have nn4,ie, and
>dom.js separations we can certainly do this.  For the rest of the files it's
>completely unnecessary.  For the time being I'd not worry about it too much.
>Everythings working fine, I'd prefer on concentrating on building more
>widgets.  After we have a larger codebase we can better decide what changes
>are really necessary (at this point I don't think such a change is crutial
>for continued developement).
>>
>> Dan
>>
>> On Wed, Dec 06, 2000 at 07:58:53AM -0600, Dougal Campbell wrote:
>> > On 5 Dec 2000, Bill Wheaton wrote:
>> >
>> > > What I meant (can't say about Cameron), was that it would be nice to
>have all
>> > > of the functionality of the API without even worrying if it is cross
>browser
>> > > compatible.
>> > > Quite often, I have to write intranet apps where my customer can and
>> > > absolutely does control which ua their users use. (via SMS or
>whatever).  It
>> > > doesn't matter as much over a lan, but for their remote sales people
>dialing
>> > > up from his customer's pots line to check product allocation during
>the lunch
>> > > break, it can be slow.  If I could _only_ include IE code when I knew
>it was
>> > > the standard, then I could speed things up some.... maybe even a lot.
>> > > maybe I'm dreaming
>> > > -bw
>> >
>> > Those of you interested in browser-targeted code might want to take a
>> > look at <URL:http://www.dx0.org/>. This is a cross-browser library with
>> > a difference: it uses server-side technology to detect which browser is
>> > making the connection, then it delivers JavaScript targeted to that
>> > particular browser.
>> >
>> > In other words, if you view the site with Netscape 4.x, you only receive
>> > JavaScript for NS4 (there's no "if is.ie" conditionals). If you browse
>> > in with IE5, you get Javascript specifically for IE5 (no "if
>> > is.ns4"). Or Mozilla, or NS6, or whatever (they might be supporting
>> > Opera, if the new release has decent DOM).
>> >
>> > The project is still in heavy development, but there are already a few
>> > skinnable widgets built and working (a menu, a floating toolbar, and a
>> > viewBox (a scrollbar/window).
>> >
>> > You build your DHTML code in PHP, Perl, or Python. The server then
>> > delivers appropriate JS to the browser.
>> >
>> > Also check out <URL:http://deathstar.eng.utah.edu/~kroford/930/dx0/>
>> >
>> > Keep in mind that the library and the site are still under development,
>> > and there are sections of the web site that aren't complete yet. But
>> > from what I've seen on the mailing list, it looks like a few people are
>> > using it in production already.
>> >
>> > --
>> > Ernest MacDougal Campbell III, MCP <do...@gu...>
>> > http://www.gunters.org/~dougal/
>> > Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/
>> > "The medium is not the message. The *message* is the message."
>> >
>> > _______________________________________________
>> > Dynapi-Dev mailing list
>> > Dyn...@li...
>> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>> _______________________________________________
>> Dynapi-Dev mailing list
>> Dyn...@li...
>> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

RE: Re[2]: [Dynapi-Dev] CVS in WIndows

[Darin K. <dka...@ef...>]

guys, this is starting to drive me nuts.
i'm pretty sure i've set wincvs up correctly.
I have an environment var named "HOME" set to "c:\home". I'm using nt4 sp5.

when i just load the app, right-click on the project and select "checkout
module"  (and then typing in "dynapi"), my message window looks like this:

CVSROOT: :ext:to...@cv...:/cvsroot/dynapi (ssh
authentication)
TCL is *not* available, shell is disabled
cvs -d :ext:to...@cv...:/cvsroot/dynapi checkout -P -d
dynapi dynapi (in directory C:\home)
cvs [checkout aborted]: cannot start server via rsh: No such file or
directory

*****CVS exited normally with code 1*****


am i the only one who can't get this to work? 

-----Original Message-----
From: Robert Rainwater [mailto:rra...@ya...]
Sent: Monday, December 04, 2000 4:39 PM
To: DynAPI Development List
Subject: Re[2]: [Dynapi-Dev] CVS in WIndows



I believe that is correct. With the method I showed, you can not use
the login options. It will prompt for a login when you do a
checkout/checkin. However, there is not a module to check out yet.
Hopefully, they will reset CVS today. I will post when the module has
been imported. Then you can just checkout the module.

-- 
// Robert Rainwater

On 12/4/2000, 1:55:33 PM EST, Darin wrote about "[Dynapi-Dev] CVS in
WIndows":


> after installing and using the settings outlined below (on NT4), i get a
> message saying :

> CVSROOT: :ext:to...@cv...:/cvsroot/dynapi (ssh
> authentication)
> TCL is *not* available, shell is disabled


> i can't seem to get any further.
> "torgo" is my username on sourceforge.

> any idea what i am doing wrong?



> -----Original Message-----
> From: Robert Rainwater [mailto:rra...@ya...]
> Sent: Sunday, December 03, 2000 3:02 PM
> To: DynAPI Development List
> Subject: [Dynapi-Dev] CVS in WIndows



> Here are some quick and dirty instructions for setting up CVS on
> windows.

> Files
> -----

> WinCVS:
> ftp://sunsite.cnlab-switch.ch/mirror/cvsgui/WinCvs11b17.zip

> SSH:
> ftp://ftp.dei.uc.pt/.disk2/Crypto/SSH/contrib/ssh-1.2.14-win32bin.zip

> Installation
> ------------
> Install WinCVS as per the instructions provided.

> - Unzip ssh-1.2.14-win32bin.zip to a directory (ex. c:\ssh).
> - Add c:\ssh to the PATH variable.
> - Create a HOME directory (ex. c:\home).
> - Create environment variable HOME with value c:\home
> - Restart

> - Start WinCVS.
> - It should prompt to enter your CVS Root.  (if not, choose
> Admin|Preferences).  Enter the cvs root as:
> ":ext:<username>@cvs.dynapi.sourceforge.net:/cvsroot/dynapi"
> Below CVSRoot, choose SSH Server for authentication.  Then click the
> Ports tab and click "Check for alternate rsh name" to enable it.  Then
> choose OK and your set.

> Also, you can choose View|Browse Location|Change to change to a
> working directory, so you will not see your whole hard drive in the
> view.  Choose c:\home for example.

> Now your set.

> To checkout a module, Right click Home and choose checkout and then
> you would enter the name of the module.  A DOS box will pop up that
> will require your sourceforge password.

> Currently, there is no module yet to checkout, but you would normally
> checkout "dynapi" to get the latest version.

> For more info checkout:
> https://sourceforge.net/docman/display_doc.php?docid=766&group_id=1


_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

SV: [Dynapi-Dev] DynAPI "require" method?

[Bart B. <ba...@ho...>]

Yup.. this totally makes sense.
But I guess you would have to have some sort of array keeping track of the files already loaded, as I think was mentioned inn a post some weeks ago.
But at any rate .. this sounds very sound :)
I mean .. it would definetly simplify for the web guru trying to implement that particular widget or whatever.
I can't even remember how many times I've searched in vain for an error which turned out to be a missing file....
even before using DynAPI2 ...heh

/ Bart


-----Ursprungligt meddelande-----
Från: Bill Wheaton <bil...@us...>
Till: Dyn...@li... <Dyn...@li...>
Datum: den 6 december 2000 22:08
Ämne: [Dynapi-Dev] DynAPI "require" method?


>You know how Perl has "require"?
>Wouldn't it be useful to have DynAPI have a require method.
>That way, at the top of a widget that has to have a Button, LoadPanel and
>ScrollPanel, I could say:
>  DynAPI.require('Button', 'LoadPanel', 'ScrollPanel')
>and it would make sure that I got the modules, even if I didn't proclaim it in
>the HTML file with:
>  <script language=javascript>
>    DynAPI.setLibraryPath('../js/lib')
>    DynAPI.include('Button.js')
>    DynAPI.include('LoadPanel.js')
>    DynAPI.include('ScrollPanel.js')
>    DynAPI.include('MenuBoxWidget.js')
>  </script>
>Instead I could use:
>  <script language=javascript>
>    DynAPI.setLibraryPath('../js/lib')
>    DynAPI.include('MenuBoxWidget.js')
>  </script>
>which would automatically include the right things.
>Maybe this is what that loadLibrary thing is?
>I wouldn't even know how to go about it at this point.
>-bw
>
>____________________________________________________________________
>Get free email and a permanent address at http://www.netaddress.com/?N=1
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] Scrollpane Problems

[Dan S. <dy...@fu...>]

The event names during slide's have changed, they are "pathstart", "pathrun", and "pathstop".  So this would be the first thing to look at.  If no one else finds the problem I will get around to it.

Dan 

On Wed, Dec 06, 2000 at 03:31:33PM -0500, Robert Rainwater wrote:
> 
> Using the latest from CVS, the scroll buttons do not work as they
> should.  By clicking the down arrow and releasing, the object will
> continue to scroll until it reaches the bottom, even if you release
> the button.
> 
> It appears scrollpane does not catch the onscrollend.  I don't know if
> it needs to, but the cancelScroll() is obviously not working right in
> the scrollpane.
> 
> Also, the pushpanel, is having a similar problem, when the buttons do
> not disappear until you click then again after scrolling all the way
> to the top or bottom.
> 
> -- 
> // Robert Rainwater
> 
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] DynAPI build, Splitting files

[Brandon M. <bnd...@ho...>]

(Oh.. and Dan.. not only do DynLayer/DynDocument and LoadPanel have specific
code, DragEvent and several other extentions have much browser specific
code.)
Drag event code could really be improved by splitting it. IE could use VB
enhancements (I know.. it's not JS..) to give it better performance.

----- Original Message -----
From: "Dan Steinman" <dy...@fu...>
To: <dyn...@li...>
Sent: Wednesday, December 06, 2000 3:44 PM
Subject: Re: [Dynapi-Dev] DynAPI build, Splitting files


> The only files in the DynAPI that are browser related are DynLayer,
DynDocument, and Loadpanel.  So if everyone feels we should have nn4,ie, and
dom.js separations we can certainly do this.  For the rest of the files it's
completely unnecessary.  For the time being I'd not worry about it too much.
Everythings working fine, I'd prefer on concentrating on building more
widgets.  After we have a larger codebase we can better decide what changes
are really necessary (at this point I don't think such a change is crutial
for continued developement).
>
> Dan
>
> On Wed, Dec 06, 2000 at 07:58:53AM -0600, Dougal Campbell wrote:
> > On 5 Dec 2000, Bill Wheaton wrote:
> >
> > > What I meant (can't say about Cameron), was that it would be nice to
have all
> > > of the functionality of the API without even worrying if it is cross
browser
> > > compatible.
> > > Quite often, I have to write intranet apps where my customer can and
> > > absolutely does control which ua their users use. (via SMS or
whatever).  It
> > > doesn't matter as much over a lan, but for their remote sales people
dialing
> > > up from his customer's pots line to check product allocation during
the lunch
> > > break, it can be slow.  If I could _only_ include IE code when I knew
it was
> > > the standard, then I could speed things up some.... maybe even a lot.
> > > maybe I'm dreaming
> > > -bw
> >
> > Those of you interested in browser-targeted code might want to take a
> > look at <URL:http://www.dx0.org/>. This is a cross-browser library with
> > a difference: it uses server-side technology to detect which browser is
> > making the connection, then it delivers JavaScript targeted to that
> > particular browser.
> >
> > In other words, if you view the site with Netscape 4.x, you only receive
> > JavaScript for NS4 (there's no "if is.ie" conditionals). If you browse
> > in with IE5, you get Javascript specifically for IE5 (no "if
> > is.ns4"). Or Mozilla, or NS6, or whatever (they might be supporting
> > Opera, if the new release has decent DOM).
> >
> > The project is still in heavy development, but there are already a few
> > skinnable widgets built and working (a menu, a floating toolbar, and a
> > viewBox (a scrollbar/window).
> >
> > You build your DHTML code in PHP, Perl, or Python. The server then
> > delivers appropriate JS to the browser.
> >
> > Also check out <URL:http://deathstar.eng.utah.edu/~kroford/930/dx0/>
> >
> > Keep in mind that the library and the site are still under development,
> > and there are sections of the web site that aren't complete yet. But
> > from what I've seen on the mailing list, it looks like a few people are
> > using it in production already.
> >
> > --
> > Ernest MacDougal Campbell III, MCP <do...@gu...>
> > http://www.gunters.org/~dougal/
> > Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/
> > "The medium is not the message. The *message* is the message."
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] DynAPI "require" method?

[Brandon M. <bnd...@ho...>]

Ohh.. boy.. here we go again on this subject. This has been a big issue..
and that there are problems when including external javascript after a
certain level deep. What is the max level? I don't know. I just know that
there have been problems doing this. And the widgets would have to not
require anything in those external files untill AFTER the onLoad event. I
know this much from experience.

I do, however, rely on this method to allow external JS files to specify
what files are in each browser specific library.

----- Original Message -----
From: "Bill Wheaton" <bil...@us...>
To: <Dyn...@li...>
Sent: Wednesday, December 06, 2000 3:28 PM
Subject: [Dynapi-Dev] DynAPI "require" method?


> You know how Perl has "require"?
> Wouldn't it be useful to have DynAPI have a require method.
> That way, at the top of a widget that has to have a Button, LoadPanel and
> ScrollPanel, I could say:
>   DynAPI.require('Button', 'LoadPanel', 'ScrollPanel')
> and it would make sure that I got the modules, even if I didn't proclaim
it in
> the HTML file with:
>   <script language=javascript>
>     DynAPI.setLibraryPath('../js/lib')
>     DynAPI.include('Button.js')
>     DynAPI.include('LoadPanel.js')
>     DynAPI.include('ScrollPanel.js')
>     DynAPI.include('MenuBoxWidget.js')
>   </script>
> Instead I could use:
>   <script language=javascript>
>     DynAPI.setLibraryPath('../js/lib')
>     DynAPI.include('MenuBoxWidget.js')
>   </script>
> which would automatically include the right things.
> Maybe this is what that loadLibrary thing is?
> I wouldn't even know how to go about it at this point.
> -bw
>
> ____________________________________________________________________
> Get free email and a permanent address at http://www.netaddress.com/?N=1
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

RE: [Dynapi-Dev] DynAPI build, Splitting files

[Pascal B. <pa...@dy...>]

according to my websites traffice.. the study is incorrect :)

Anyway, when you split things up you still have way to much to load within
7seconds, but compressions should give you that extra, and splitting things
up should not be done to gain size only speed.. which can actually be done
in an easier way in most cases.

the  is  variable is declared before anything loads, so you can use that in
the code at a few places that are "speed-critical".

I changed my moveTo method to this:

if (is.ns) {
	DynLayer.prototype._setX=function(x){ this.css.left=this.x=x }
	DynLayer.prototype._setY=function(y){	this.css.top=this.y=y }
} else {
	DynLayer.prototype._setX=function(x){	this.css.pixelLeft=this.x=x }
	DynLayer.prototype._setY=function(y){	this.css.pixelTop=this.y=y }
}
DynLayer.prototype.moveTo=function(x,y) {
	if (x!=null) this._setX(x)
	if (y!=null) this._setY(y)
	this.invokeEvent('move')
}


which makes the correct method for the correct browser before running
things, so it's only called once without creating complete seperate files..
just moving the if statement out of the loop.




Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Doug Melvin
> Verzonden: woensdag 6 december 2000 22:33
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] DynAPI build, Splitting files
>
>
> I don't know what you consider crucial.. but, a recent study suggests that
> if your page takes more than 7 seconds to load (that's right, 7 seconds)
> then more than half of your viewer will get board and leave
> before they get
> to see all of the 'cool' and 'clever' stuff you have put on or
> done to your
> site
>
> Doug Melvin
>
> > The only files in the DynAPI that are browser related are DynLayer,
> DynDocument, and Loadpanel.  So if everyone feels we should have
> nn4,ie, and
> dom.js separations we can certainly do this.  For the rest of the
> files it's
> completely unnecessary.  For the time being I'd not worry about
> it too much.
> Everythings working fine, I'd prefer on concentrating on building more
> widgets.  After we have a larger codebase we can better decide
> what changes
> are really necessary (at this point I don't think such a change is crutial
> for continued developement).
> >
> > Dan
> >
> > On Wed, Dec 06, 2000 at 07:58:53AM -0600, Dougal Campbell wrote:
> > > On 5 Dec 2000, Bill Wheaton wrote:
> > >
> > > > What I meant (can't say about Cameron), was that it would be nice to
> have all
> > > > of the functionality of the API without even worrying if it is cross
> browser
> > > > compatible.
> > > > Quite often, I have to write intranet apps where my customer can and
> > > > absolutely does control which ua their users use. (via SMS or
> whatever).  It
> > > > doesn't matter as much over a lan, but for their remote sales people
> dialing
> > > > up from his customer's pots line to check product allocation during
> the lunch
> > > > break, it can be slow.  If I could _only_ include IE code
> when I knew
> it was
> > > > the standard, then I could speed things up some.... maybe
> even a lot.
> > > > maybe I'm dreaming
> > > > -bw
> > >
> > > Those of you interested in browser-targeted code might want to take a
> > > look at <URL:http://www.dx0.org/>. This is a cross-browser
> library with
> > > a difference: it uses server-side technology to detect which
> browser is
> > > making the connection, then it delivers JavaScript targeted to that
> > > particular browser.
> > >
> > > In other words, if you view the site with Netscape 4.x, you
> only receive
> > > JavaScript for NS4 (there's no "if is.ie" conditionals). If you browse
> > > in with IE5, you get Javascript specifically for IE5 (no "if
> > > is.ns4"). Or Mozilla, or NS6, or whatever (they might be supporting
> > > Opera, if the new release has decent DOM).
> > >
> > > The project is still in heavy development, but there are already a few
> > > skinnable widgets built and working (a menu, a floating toolbar, and a
> > > viewBox (a scrollbar/window).
> > >
> > > You build your DHTML code in PHP, Perl, or Python. The server then
> > > delivers appropriate JS to the browser.
> > >
> > > Also check out <URL:http://deathstar.eng.utah.edu/~kroford/930/dx0/>
> > >
> > > Keep in mind that the library and the site are still under
> development,
> > > and there are sections of the web site that aren't complete yet. But
> > > from what I've seen on the mailing list, it looks like a few
> people are
> > > using it in production already.
> > >
> > > --
> > > Ernest MacDougal Campbell III, MCP <do...@gu...>
> > > http://www.gunters.org/~dougal/
> > > Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/
> > > "The medium is not the message. The *message* is the message."
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

[Dynapi-Dev] Scrollpane Problems

[Robert R. <rra...@ya...>]

Using the latest from CVS, the scroll buttons do not work as they
should.  By clicking the down arrow and releasing, the object will
continue to scroll until it reaches the bottom, even if you release
the button.

It appears scrollpane does not catch the onscrollend.  I don't know if
it needs to, but the cancelScroll() is obviously not working right in
the scrollpane.

Also, the pushpanel, is having a similar problem, when the buttons do
not disappear until you click then again after scrolling all the way
to the top or bottom.

-- 
// Robert Rainwater

[Dynapi-Dev] DynAPI "require" method?

[Bill W. <bil...@us...>]

You know how Perl has "require"?
Wouldn't it be useful to have DynAPI have a require method.
That way, at the top of a widget that has to have a Button, LoadPanel and
ScrollPanel, I could say:
  DynAPI.require('Button', 'LoadPanel', 'ScrollPanel')
and it would make sure that I got the modules, even if I didn't proclaim it in
the HTML file with:
  <script language=javascript>
    DynAPI.setLibraryPath('../js/lib')
    DynAPI.include('Button.js')
    DynAPI.include('LoadPanel.js')
    DynAPI.include('ScrollPanel.js')
    DynAPI.include('MenuBoxWidget.js')
  </script>
Instead I could use:
  <script language=javascript>
    DynAPI.setLibraryPath('../js/lib')
    DynAPI.include('MenuBoxWidget.js')
  </script>
which would automatically include the right things.
Maybe this is what that loadLibrary thing is?
I wouldn't even know how to go about it at this point.
-bw

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

[Dynapi-Dev] Doug...

[Raymond S. <dst...@or...>]

Doug,

Get some sleep man.  The brain does wonderous things when you let it rest.
40+hours and all your doing now is staying at your e-mail editor in between
sudden flights of dillusion and unfounded laughing for no apparent reason.

RE: Re[2]: [Dynapi-Dev] Label Cover Bug

[Simon D. M. <di...@bi...>]

> > It looks like in IE (I haven't tested NS), that these events are not
> > fired:
> >
> > this.selectListener.onmousemove, etc.
> >
> > These should be fired when you say setSelectable(false).
> >
> > This could be one of the problems with IE not working.
> >
> The onmousemove event is not fired because it is not registered
> for DynLayer
> in the event.js.
>
> I posted a patch for the label, containing event.js and label.js based on
> 12.01 beta in a zip file, a few days ago. It should be fixed in the patch.

I tested you your patch and it worked fine.

I guess the IE specific method that Dan was mentioning was
document.selection.clear() but your patched code worked fine without it.

I did notice that cancelling the mousemove was enough to turn of selection
for ns4 and ie5 while ns6 needed the mousedown cancelled as well.
Not sure why.

Dicon

Re: [Dynapi-Dev] DynAPI build, Splitting files

[Doug M. <do...@cr...>]

I don't know what you consider crucial.. but, a recent study suggests that
if your page takes more than 7 seconds to load (that's right, 7 seconds)
then more than half of your viewer will get board and leave before they get
to see all of the 'cool' and 'clever' stuff you have put on or done to your
site

Doug Melvin

> The only files in the DynAPI that are browser related are DynLayer,
DynDocument, and Loadpanel.  So if everyone feels we should have nn4,ie, and
dom.js separations we can certainly do this.  For the rest of the files it's
completely unnecessary.  For the time being I'd not worry about it too much.
Everythings working fine, I'd prefer on concentrating on building more
widgets.  After we have a larger codebase we can better decide what changes
are really necessary (at this point I don't think such a change is crutial
for continued developement).
>
> Dan
>
> On Wed, Dec 06, 2000 at 07:58:53AM -0600, Dougal Campbell wrote:
> > On 5 Dec 2000, Bill Wheaton wrote:
> >
> > > What I meant (can't say about Cameron), was that it would be nice to
have all
> > > of the functionality of the API without even worrying if it is cross
browser
> > > compatible.
> > > Quite often, I have to write intranet apps where my customer can and
> > > absolutely does control which ua their users use. (via SMS or
whatever).  It
> > > doesn't matter as much over a lan, but for their remote sales people
dialing
> > > up from his customer's pots line to check product allocation during
the lunch
> > > break, it can be slow.  If I could _only_ include IE code when I knew
it was
> > > the standard, then I could speed things up some.... maybe even a lot.
> > > maybe I'm dreaming
> > > -bw
> >
> > Those of you interested in browser-targeted code might want to take a
> > look at <URL:http://www.dx0.org/>. This is a cross-browser library with
> > a difference: it uses server-side technology to detect which browser is
> > making the connection, then it delivers JavaScript targeted to that
> > particular browser.
> >
> > In other words, if you view the site with Netscape 4.x, you only receive
> > JavaScript for NS4 (there's no "if is.ie" conditionals). If you browse
> > in with IE5, you get Javascript specifically for IE5 (no "if
> > is.ns4"). Or Mozilla, or NS6, or whatever (they might be supporting
> > Opera, if the new release has decent DOM).
> >
> > The project is still in heavy development, but there are already a few
> > skinnable widgets built and working (a menu, a floating toolbar, and a
> > viewBox (a scrollbar/window).
> >
> > You build your DHTML code in PHP, Perl, or Python. The server then
> > delivers appropriate JS to the browser.
> >
> > Also check out <URL:http://deathstar.eng.utah.edu/~kroford/930/dx0/>
> >
> > Keep in mind that the library and the site are still under development,
> > and there are sections of the web site that aren't complete yet. But
> > from what I've seen on the mailing list, it looks like a few people are
> > using it in production already.
> >
> > --
> > Ernest MacDougal Campbell III, MCP <do...@gu...>
> > http://www.gunters.org/~dougal/
> > Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/
> > "The medium is not the message. The *message* is the message."
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

Re: [Re: [Dynapi-Dev] DynAPI Makefile/code compression almost complete]

[Doug M. <do...@cr...>]

> Although there are a lot interesting or important things to do, splitting
> code into browser and version specific seems to be the hotest theme. :)

there is a very simple reason for that, dynapi is inherantly SLOW..
www.zara.com takes soo long to run on my computer
(Duron 600 with 128 megs ram) that I have yet to see any of their products..
(they sell clothes don't they? :-) )

Doug Melvin

Re: [Re: [Dynapi-Dev] DynAPI Makefile/code compression almost complete]

[Doug M. <do...@cr...>]

I second the humble opinions stated in this preceeding message..
:-)
----- Original Message -----
From: "Cameron Hart" <ca...@bi...>
To: <dyn...@li...>
Sent: Wednesday, December 06, 2000 4:56 AM
Subject: RE: [Re: [Dynapi-Dev] DynAPI Makefile/code compression almost
complete]


> > What I meant (can't say about Cameron), was that it would be nice
> > to have all of the functionality of the API without even worrying if it
is
> > cross browser compatible.
> <snip>
> > If I could _only_ include IE code when I
> > knew it was the standard, then I could speed things up some.... maybe
even
> a lot.
> > maybe I'm dreaming
>
> It would be smaller and faster in all cases because the client would only
> load and run code specific to
> their browser. for example, if (is.ie) ... would only get executed once
when
> the client needed to select the ie specific version of the API to load at
> run time.
>
> That's pretty much the rational behind my suggestion. I'd seen a bit of
> discussion on the list about splitting the API source into different .js
> files for different browsers, the right one being imported when the user
> visits the page. IMHO splitting the API into browser specific .js files
> sounds like a bad idea, keeping the source together and letting a Makefile
> split it would be safer. Of course none of the developers have said they
> were going to split the API in this fashion. I imagine that doing this
would
> be a hell of a lot of work, and you probably all have more important
things
> to do :-)
>
> However if it ever did happen, I think a Makefile solution with #define
and
> #ifdef style macros would be a good way of acheiving this.
>
>

Re: [Dynapi-Dev] CVS Partially Updated with Makefile

[Robert R. <rra...@ya...>]

I added semicolons to the rest of the files.  However, there could be
mistakes.  Please get the latest snapshot at
http://dynapi.sourceforge.net/snapshot/dynapi.zip, and post to the
list if you find errors in semicolon placement.

-- 
// Robert Rainwater

On 12/6/2000, 4:57:54 AM EST, Dan wrote about "[Dynapi-Dev] CVS Partially Updated with Makefile":

> I've contributed my Makefile into the CVS, along with updating the /api/ and /util/ files with semi colons (that's enough ;'s for one night).

> The JSPack util that is needed to build the compressed DynAPI is released separately:

> http://www.dansteinman.com/jspack/

> Also, I SERIOUSLY recommend removing the /js/ directory altogether.  We don't want people submitting changes to the files in /js/ because that is the directory that is automatically created by the
> makefile.

> The examples need to be updated to point to /src/.  Also it would be good to ensure that all the examples use the DynAPI include() so that the switch from /src/ to /js/ is a one line change.

> The DynAPI packages that are created by the makefile/jspack will not work correctly yet.  If there is even one line that does not have a semi colon in the right spot nothing will work.

> The Makefile produces a duplicate copy of the /src/ tree with all the .js files compressed.  It also creates .js packages of all the files in the subdirectories(eg /lib/dynapi.api.js) as well a
> "all" package which contains everything.  It goes one step further to Jar and Gzip those package files.

> As I mentioned earlier the significant semi colon to look for is in this case:

> method = function() {

> };  // it occurs in event listeners and every prototype in the DynAPI

> Also it's better now to never do one line methods like:

> obj.prototype.method=function() {code}

> Just because it's not easy to spot where the ;'s go:

> obj.prototype.method=function() {code;}; // better to unwrap this

> The files that need to be updated with semi colons are in /gui/ and /ext/.  At that point we should be able to build and a working compressed DynAPI.  It's really quite a dramatic compression. 
> From 100Kb of code down to 15Kb Jar and Gzip = 85%.  Pretty darned cool if I say so.

> Robert will you be able to use jspack on the sourceforge server for cron jobs?

> Let me know of any problems,
> Dan
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re[4]: [Dynapi-Dev] Label Cover Bug

[Robert R. <rra...@ya...>]

Somehow I missed your post before.  Anyway, I got your fixes for IE to
work, but a do have one question.  What is this for:
if (is.ie) {
   if (evt.browserReturn==false) e.returnValue=false
}

I did not apply this, and your patch still works.

Also, the cursor for IE needs to be set oncreate as well, because if
you do setSelectable before the create it will never be set.

I updated it in CVS.  I did not include the fixes for NS yet, as I
have not tested it.

-- 
// Robert Rainwater

On 12/6/2000, 4:24:08 AM EST, Guangyi wrote about "[Dynapi-Dev] Label Cover Bug":

>> 
>> It looks like in IE (I haven't tested NS), that these events are not
>> fired:
>> 
>> this.selectListener.onmousemove, etc.
>> 
>> These should be fired when you say setSelectable(false).
>> 
>> This could be one of the problems with IE not working.
>> 
> The onmousemove event is not fired because it is not registered for DynLayer
> in the event.js.

> I posted a patch for the label, containing event.js and label.js based on
> 12.01 beta in a zip file, a few days ago. It should be fixed in the patch.

> br
> George
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] small typo

[Jared N. <ja...@aa...>]

sorry about that. Line 14 of dynapi.js of Version 2000.11.07. is what I =
was refering to... that was pretty vague :o)

wasDraging should be wasDragging

Re: [Dynapi-Dev] DynAPI build, Splitting files

[Dan S. <dy...@fu...>]

The only files in the DynAPI that are browser related are DynLayer, DynDocument, and Loadpanel.  So if everyone feels we should have nn4,ie, and dom.js separations we can certainly do this.  For the rest of the files it's completely unnecessary.  For the time being I'd not worry about it too much.  Everythings working fine, I'd prefer on concentrating on building more widgets.  After we have a larger codebase we can better decide what changes are really necessary (at this point I don't think such a change is crutial for continued developement).

Dan

On Wed, Dec 06, 2000 at 07:58:53AM -0600, Dougal Campbell wrote:
> On 5 Dec 2000, Bill Wheaton wrote:
> 
> > What I meant (can't say about Cameron), was that it would be nice to have all
> > of the functionality of the API without even worrying if it is cross browser
> > compatible.  
> > Quite often, I have to write intranet apps where my customer can and
> > absolutely does control which ua their users use. (via SMS or whatever).  It
> > doesn't matter as much over a lan, but for their remote sales people dialing
> > up from his customer's pots line to check product allocation during the lunch
> > break, it can be slow.  If I could _only_ include IE code when I knew it was
> > the standard, then I could speed things up some.... maybe even a lot.
> > maybe I'm dreaming
> > -bw
> 
> Those of you interested in browser-targeted code might want to take a
> look at <URL:http://www.dx0.org/>. This is a cross-browser library with
> a difference: it uses server-side technology to detect which browser is
> making the connection, then it delivers JavaScript targeted to that
> particular browser.
> 
> In other words, if you view the site with Netscape 4.x, you only receive
> JavaScript for NS4 (there's no "if is.ie" conditionals). If you browse
> in with IE5, you get Javascript specifically for IE5 (no "if
> is.ns4"). Or Mozilla, or NS6, or whatever (they might be supporting
> Opera, if the new release has decent DOM).
> 
> The project is still in heavy development, but there are already a few
> skinnable widgets built and working (a menu, a floating toolbar, and a
> viewBox (a scrollbar/window). 
> 
> You build your DHTML code in PHP, Perl, or Python. The server then
> delivers appropriate JS to the browser.
> 
> Also check out <URL:http://deathstar.eng.utah.edu/~kroford/930/dx0/>
> 
> Keep in mind that the library and the site are still under development,
> and there are sections of the web site that aren't complete yet. But
> from what I've seen on the mailing list, it looks like a few people are
> using it in production already.
> 
> -- 
> Ernest MacDougal Campbell III, MCP <do...@gu...>
> http://www.gunters.org/~dougal/
> Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/
> "The medium is not the message. The *message* is the message."
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] DynAPI Releases

[Peter C. <pc...@ca...>]

With all this CVS stuff, are there still going to be releases DynAPI? I 
just want to get some periodic releases of reasonable stable versions of 
the package, not every minor change that happens. I don't want to have to 
pick up new stuff every day, with a "random" set of changes. And most 
important - I really need to know what has changed from one version to the 
next (not every minor bug fix - new features, changed features, etc.) Is 
anything like this being done now?

I am reading the mailing lists, but I can't possibly keep up with all the 
traffic, or understand all the comments about areas that I'm not working 
with at the moment, etc.

--
Peter Curran     Software Developer    Casebank Technologies Inc.

RE: [Re: [Dynapi-Dev] DynAPI Makefile/code compression almost com plete]

[Guangyi Wu <gua...@al...>]

> Those of you interested in browser-targeted code might want to take a
> look at <URL:http://www.dx0.org/>. This is a cross-browser 
> library with
> a difference: it uses server-side technology to detect which 
> browser is
> making the connection, then it delivers JavaScript targeted to that
> particular browser.

It can be done with server side technology, but a client side solution seems
to me better. It only waste server time to produce specific JavaScript file.

If the files are split, we can also keep in an OO way. For example, we can
use Factory pattern: the DynLayer with all code same for all browsers and
versions; DynLayerNN and DynLayerIE inherit DynLayer and with general code
for all version; and DynLayerNN_4, ... with NN4 specific code. A
DynLayerFactory object detects browser and version, return the corresponding
sub-class object of DynLayer and it is transparent to the user of DynLayer.

Although there are a lot interesting or important things to do, splitting
code into browser and version specific seems to be the hotest theme. :)

Re: [Re: [Dynapi-Dev] DynAPI Makefile/code compression almost complete]

[Dougal C. <do...@gu...>]

On 5 Dec 2000, Bill Wheaton wrote:

> What I meant (can't say about Cameron), was that it would be nice to have all
> of the functionality of the API without even worrying if it is cross browser
> compatible.  
> Quite often, I have to write intranet apps where my customer can and
> absolutely does control which ua their users use. (via SMS or whatever).  It
> doesn't matter as much over a lan, but for their remote sales people dialing
> up from his customer's pots line to check product allocation during the lunch
> break, it can be slow.  If I could _only_ include IE code when I knew it was
> the standard, then I could speed things up some.... maybe even a lot.
> maybe I'm dreaming
> -bw

Those of you interested in browser-targeted code might want to take a
look at <URL:http://www.dx0.org/>. This is a cross-browser library with
a difference: it uses server-side technology to detect which browser is
making the connection, then it delivers JavaScript targeted to that
particular browser.

In other words, if you view the site with Netscape 4.x, you only receive
JavaScript for NS4 (there's no "if is.ie" conditionals). If you browse
in with IE5, you get Javascript specifically for IE5 (no "if
is.ns4"). Or Mozilla, or NS6, or whatever (they might be supporting
Opera, if the new release has decent DOM).

The project is still in heavy development, but there are already a few
skinnable widgets built and working (a menu, a floating toolbar, and a
viewBox (a scrollbar/window). 

You build your DHTML code in PHP, Perl, or Python. The server then
delivers appropriate JS to the browser.

Also check out <URL:http://deathstar.eng.utah.edu/~kroford/930/dx0/>

Keep in mind that the library and the site are still under development,
and there are sections of the web site that aren't complete yet. But
from what I've seen on the mailing list, it looks like a few people are
using it in production already.

-- 
Ernest MacDougal Campbell III, MCP <do...@gu...>
http://www.gunters.org/~dougal/
Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/
"The medium is not the message. The *message* is the message."

RE: [Re: [Dynapi-Dev] DynAPI Makefile/code compression almost complete]

[Cameron H. <ca...@bi...>]

> What I meant (can't say about Cameron), was that it would be nice
> to have all of the functionality of the API without even worrying if it is
> cross browser compatible.
<snip>
> If I could _only_ include IE code when I
> knew it was the standard, then I could speed things up some.... maybe even
a lot.
> maybe I'm dreaming

It would be smaller and faster in all cases because the client would only
load and run code specific to
their browser. for example, if (is.ie) ... would only get executed once when
the client needed to select the ie specific version of the API to load at
run time.

That's pretty much the rational behind my suggestion. I'd seen a bit of
discussion on the list about splitting the API source into different .js
files for different browsers, the right one being imported when the user
visits the page. IMHO splitting the API into browser specific .js files
sounds like a bad idea, keeping the source together and letting a Makefile
split it would be safer. Of course none of the developers have said they
were going to split the API in this fashion. I imagine that doing this would
be a hell of a lot of work, and you probably all have more important things
to do :-)

However if it ever did happen, I think a Makefile solution with #define and
#ifdef style macros would be a good way of acheiving this.