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

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

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

Alreigth then, how about a suggestion made earlier (don't recall by whom)..
Put some code into dynapi.js which will
'complie' the code for the specific browser in use?
we can use place-holder vars (constants) and have dynapi.js set them
according to
what browser/platform is in use..

Doug Melvin
----- Original Message -----
From: "Pascal Bestebroer" <pa...@dy...>
To: <dyn...@li...>
Sent: Sunday, December 10, 2000 2:51 AM
Subject: RE: [Dynapi-Dev] DynAPI build, Splitting files


>
> Once you split up parts of the API for every browser (that could
eventually
> include Opera, and other flavours) it means that people will start
focusing
> on a single browser because that's the browser they'll be using.  Ofcourse
> this is already being done on a smaller scale (Dan's main focus seems to
be
> Netscape, and my focus is more IE5+) but at this point because of the code
> being one , we know that what ever we do should also work Netscape.. once
> you split things up I think this "awareness" will disappear and people
will
> just enhance the code for that single browser and let someone else worry
> about the other browsers files.
>
> "All this is done only to define two basic paisr of vars. Terrible. And
> impossible just to skip the nn stuff, becoause it's not clear, what refers
> to nn but only what is not for ie. I have to go through it and to
> learn the"
>
> that's correct, just two basic pairs of vars, so you want to split all
code
> up for simple things like these? And the fact that you have to go thru it
> and learn the differences is exactly my point, if you have the chance to
> only do your coding for IE, you will forget about NS and this might cause
> you to implement things in IE that are not possible in NS.  Ofcourse this
> means we're holding back one browser because of the incompatibilities with
> the other, but that's the problem with cross-browser coding, and if you
need
> that extra functionality you should added it in your own code, not in the
> general API.
>
> The problem with speed that everybody talks about is not such a big issue,
> we're not developing for 386 or 486 machines anymore, Pentium machines
don't
> take 2 or 3 clock-cycles to do a simple IF statement. Besides the IF
> statements are only called at initialisation and when changing styles, the
> main bottle-neck is not the IF statement but the time it takes browsers to
> redo the style sheet (and rerender things).  This is just a browser
problem,
> not a code problem.
>
> And ofcourse size isn't such a big issue neither, seeing that most of the
> differences (I know, not all) are done on single lines as you pointed out:
>
> is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
>
> this will only be a few bytes difference once you split it up:
>
> e.x+document.body.scrollLeft
>
> so maybe you save some bytes with the split but you have to include all
> files multiple times and maintain all files multiple times for your site
to
> look good on all browsers.
>
>
> apologies for the long post :)
>
> cya,
>
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
>
> > -----Oorspronkelijk bericht-----
> > Van: dyn...@li...
> > [mailto:dyn...@li...]Namens SReindl
> > Verzonden: zaterdag 9 december 2000 9:14
> > Aan: dyn...@li...
> > Onderwerp: AW: [Dynapi-Dev] DynAPI build, Splitting files
> >
> >
> > Well, call it as you like: Lib ode API, ... An API has the task to
supply
> > you with a unique set of functions in order to perform some development
> > tasks. In this case this is cross browser compatible programming of web
> > sites (btw, an API can be stored in a lib ;-))
> > I agree, that the API is not meant to be a play ground for fancy
> > stuff which
> > may be possible only for one particular browser.
> > But I don't see why the "streaming of the project" should be more work
for
> > separate files than for monolithic ones.
> > It's the definition of the basis of functions which is important, and
this
> > task has already been done, since the DynAPI is up and running.
> >
> > Look at this piece (from events.js):
> >
> > this.pageX=is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
> >
> > this.pageY=is.ie?e.y+document.body.scrollTop:e.pageY-window.pageYOffset
> > this.x=is.ie?e.offsetX:e.layerX
> > this.y=is.ie?e.offsetY:e.layerY
> > var b = is.ie?e.button:e.which
> > if (is.ie){
> > if (b==2) b = 3
> > else if (b==4) b = 2
> > } else { }
> > All this is done only to define two basic paisr of vars. Terrible. And
> > impossible just to skip the nn stuff, becoause it's not clear, what
refers
> > to nn but only what is not for ie. I have to go through it and to
> > learn the
> > syntax of several browsers (document.body.scrollLeft vs
> > window.pageXOffset,
> > etc., and do not forget the sign).
> >
> > My
> > > "I mean, I want to develop mainly for IE and am not interested in the
nn
> > > specifics at all. I am satisfied when it works."
> > if of course *an example* only and not the goal of my programs.
> >
> > last not least, in addition to decrease in loading and rendering
> > time there
> > is one more feature which speaks for a split: control over
> > completeness. If
> > you have to assure that your implementation is complete you will have to
> > code all the functions. The chance just to forget an if branch is
smaller.
> >
> > I do not say that cross browser compatibility should be given up,
> > I think of
> > how this task can be done in a more transparent way.
> > Stephan
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] Dynacore preview release

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

I haven't messed with your new release much, but I did notice this
problem with subclassing similar to yours.

When you use that technique to subclass DynLayers and such, it causes
a problem when in the Object you add each id to the DynAPI.unassigned
array.  Lets say you have 5 DynLayers that have been initialized, then
the unassigned array will have 6 DynLayer entries because of this
line:
DynLayer.prototype = new DynObject();

I don't know if it will ever be a problem, but I think you might be
better off adding to the unassigned array in the DynLayer, etc
themselves. Of course that would mess up some other stuff too (like
toString), so maybe its not worth it.

-- 
// Robert Rainwater

On 12/10/2000, 7:41:28 AM EST, Pascal wrote about "[Dynapi-Dev] Dynacore preview release":

> I just uploaded a preview release of my Dynacore distribution, this is
> mainly interesting for the other developers. I think some of the ideas I
> added could be very good implementations for the official version. The most
> important change is the making of the DynObject.

> you can find it here http://www.dynamic-core.net/dynacore.zip

> This object is now the base class of the DynLayer and DynDocument, and it
> implements all the child-parent functionality shared by these objects. The
> idea is that you could use the DynObject as a base class for management
> widgets like  FocusManager, ThreadManager, LayoutManager, etc.. These
> widgets are not using any visible components, but do need the
> add/delete/remove functionality.

> The current event code is mainly extending the DynObject, but my goal is to
> have it only extend this object and not the DynLayer/DynDocuments.. so that
> it is really a seperate object/extension.

> Another important addition is the manual part, this contains the full
> tutorial, and the developers reference. Somebody should update the reference
> for the official DynAPI (unless the dynobject code is also copied into the
> official release, this would make it almost 100% correct).

> For more info on the changes you can read the "changes" part of the manual.

> cya,

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

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

Re: [Dynapi-Dev] Label text selection

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

Yeah, that's something I overlooked.  setText needs to be called in order to
see an immediate change, but there's no reason to call setText every time
you change a label property.  Doesn't setHTML also fire a load event, too?

An addition boolean passed to each of the setter method could determine if
the text is to be re-rendered.  or optionally, we could just require that
setText should be invoked manually, rather than automatically from within
another setter method.


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


-----Original Message-----
From: Robert Rainwater <rra...@ya...>
To: DynAPI Development List <dyn...@li...>
Date: Friday, December 08, 2000 9:05 PM
Subject: Re: [Dynapi-Dev] Label text selection


>
>Another problem witht the list/label widgets is the many calls to
>setText.  In ListItem, the onmouseout and mousemouse over makes to
>different calls to change the font (forecolor, textcolor).  Each one
>of these calls, calls setText which sets the html.
>
>Maybe we should pass a boolean to the font change functions, that
>decides whether or not to call setText.
>
>--
>// Robert Rainwater
>
>On 12/8/2000, 6:37:49 PM EST, Scott wrote about "[Dynapi-Dev] Label text
selection":
>
>> There's a small snag in Label.  In IE, when you use setSelectable to
>> prevent text from being selected with the mouse, you're also cancelling
>> the browser event.  This can also cancel events on the label itself.
>> For example, if you build a list item out of a label with rollover color
>> change events, sometimes the label text will cancel the onmouseout
>> event.  If you mouseover the list fast enough you may end up with
>> several items stuck in the rollover position.  This could cause problems
>> with other widgets that use Label.
>
>> In light of this, I'm wondering if we should restore the optional
>> addCover() method that uses a physical layer to cover text.  If you
>> don't need it, just use setSelectable.
>
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

RE: [Dynapi-Dev] DynAPI2 Ke(board) events

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

Damn, didn't know about this line being possible:

String.fromCharCode(this.which).toLowerCase()

Great work!

Mind if I include it into Dynacore aswell :-)

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

  -----Oorspronkelijk bericht-----
  Van: dyn...@li...
[mailto:dyn...@li...]Namens Henrik Våglin
  Verzonden: zondag 10 december 2000 19:59
  Aan: dyn...@li...
  Onderwerp: [Dynapi-Dev] DynAPI2 Ke(board) events


  Hello developers

  I have put together a keyevents extension for DynAPI2 - as of release
2000.11.07, which is the latest official to my knowledge. I've made it for a
project called ComicCreation, which is the project I'm working on
implementing the DynAPI2 into.

  The keyevents are meant to be the same type of alternative UI
functionality to mouseevents as keyboard shortcuts is to mousemanouveres in
regular applications (windowbased interfaces). They should be essential for
the serious webapp developer, who takes care of the fact that sometimes
users rather uses the keyboard or simply don't have a mouse but still need a
way to reach the feature (without hazzle). If no other, most developers are
more often to use the keyboard than the mouse - so probably for most in
here.

  Now, I set the ALT key to be working as controller key, since using single
keys are already assigned for text input. I chose to limit one key as the
only valid modifier, since I'm aware that too many key-combos are already
assigned to application functionality. I'm far from sure this is a wise
choice though, since I've got a hunch that ALT-combos won't work in every
enviroment either. If somebody have any experience or would care to try out
what modifier key works crossbrowser on different systems I'd most apprieate
to be notified so that I can set the correct controller key or combo for
char keys to work as function keys.

  thanks all for your time and efforts with dynAPI

  Henrik Våglin

Re: [Dynapi-Dev] DynAPI2 Ke(board) events

[Richard :o <ma...@ri...>]

Thanks for sharing it, let us know when the site is up.
cheers,
Richard:)
  ----- Original Message -----=20
  From: Henrik V=E5glin=20
  To: dyn...@li...=20
  Sent: Sunday, December 10, 2000 7:58 PM
  Subject: [Dynapi-Dev] DynAPI2 Ke(board) events


  Hello developers

  I have put together a keyevents extension for DynAPI2 - as of release =
2000.11.07, which is the latest official to my knowledge. I've made it =
for a project called ComicCreation, which is the project I'm working on =
implementing the DynAPI2 into.

  The keyevents are meant to be the same type of alternative UI =
functionality to mouseevents as keyboard shortcuts is to mousemanouveres =
in regular applications (windowbased interfaces). They should be =
essential for the serious webapp developer, who takes care of the fact =
that sometimes users rather uses the keyboard or simply don't have a =
mouse but still need a way to reach the feature (without hazzle). If no =
other, most developers are more often to use the keyboard than the mouse =
- so probably for most in here.

  Now, I set the ALT key to be working as controller key, since using =
single keys are already assigned for text input. I chose to limit one =
key as the only valid modifier, since I'm aware that too many key-combos =
are already assigned to application functionality. I'm far from sure =
this is a wise choice though, since I've got a hunch that ALT-combos =
won't work in every enviroment either. If somebody have any experience =
or would care to try out what modifier key works crossbrowser on =
different systems I'd most apprieate to be notified so that I can set =
the correct controller key or combo for char keys to work as function =
keys.

  thanks all for your time and efforts with dynAPI

  Henrik V=E5glin=20

RE: [Dynapi-Dev] Dynacore preview release

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

There are still bugs in there,because I haven't cleaned everything up yet
(that's why there's preview in the name ;-)

ofcourse your free to use the widget and examples, just give me a line of
credit :)


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

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Richard :o
> Verzonden: zaterdag 9 december 2000 17:13
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Dynacore preview release
>
>
> hi,
> a bug found in the examples on ie5.5 WinMe:
> * dynacore.api.frames.htm        error message:
>             line24 char 2 object doesn't support this property or method.
> Cheers,
> Richard.
>
> Ps I'm planning on grouping as many as possible examples, as
> included in the
> examples directory (like Dan's
> http://www.dansteinman.com/dynapi/docs/examples-summary.html , but for
> DynAPI2) on my DynAPI info page (under construction).
> May I include/adapt your examples & examples of widgets (ie
> skinwindow etc)
> with the official DynAPI release, or rather not?
>
>
> ----- Original Message -----
> From: "Pascal Bestebroer" <pa...@dy...>
> To: "Dev" <dyn...@li...>
> Sent: Sunday, December 10, 2000 1:41 PM
> Subject: [Dynapi-Dev] Dynacore preview release
>
>
> > I just uploaded a preview release of my Dynacore distribution, this is
> > mainly interesting for the other developers. I think some of the ideas I
> > added could be very good implementations for the official version. The
> most
> > important change is the making of the DynObject.
> >
> > you can find it here http://www.dynamic-core.net/dynacore.zip
> >
> > This object is now the base class of the DynLayer and
> DynDocument, and it
> > implements all the child-parent functionality shared by these
> objects. The
> > idea is that you could use the DynObject as a base class for management
> > widgets like  FocusManager, ThreadManager, LayoutManager, etc.. These
> > widgets are not using any visible components, but do need the
> > add/delete/remove functionality.
> >
> > The current event code is mainly extending the DynObject, but my goal is
> to
> > have it only extend this object and not the DynLayer/DynDocuments.. so
> that
> > it is really a seperate object/extension.
> >
> > Another important addition is the manual part, this contains the full
> > tutorial, and the developers reference. Somebody should update the
> reference
> > for the official DynAPI (unless the dynobject code is also
> copied into the
> > official release, this would make it almost 100% correct).
> >
> > For more info on the changes you can read the "changes" part of the
> manual.
> >
> > cya,
> >
> > Pascal Bestebroer
> > pa...@dy...
> > http://www.dynamic-core.net
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > ____________________________________________________________
> > Get your FREE personal .com domain name and
> > NAMEzero Personal Portal at: http://www.namezero.com.
> > For customer service, mailto:cus...@na....
> >
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] general inheritence question

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

Ok, here are the 'troublesome' code artifacts.

CASE 1

this.popevent=3Dnew EventListener(this)
     this.popevent.ondblclick=3Dfunction(e) {
          var lyr=3De.getSource()
          o=3De.getTarget()
          if (o.isVert&&o.y!=3D130) {o.moveTo(o.x+50,o.y-20)}
          if (!o.isVert&&o.y!=3D130) {o.moveTo(o.x+60,o.y+40)}
          if (o.y!=3D130) {
          o.setZIndex(o.z+12)
          o.winRoEnabled=3Dfalse
          DragEvent.enabledDragEvents(o)
      }
      if (o.y=3D=3D130) {
      alert('This position can not be popped.')
      }
 }

I've seen 'DragEvent.enabledDragEvents(o)' used in an onCreate.  This =
one causes a method alert.  Works fine with that line // out.

CASE 2

SkinWinRotator.prototype.enableRotate=3Dfunction() {
     var thing =3D arguments[0];
     if(thing.constructor!=3DDynDocument)
      =
thing.getComponent().addEventListener(SkinWinRotator.rotevents.rotatevent=
)
     for (var i=3D1;i<arguments.length;i++) {
      var lyr=3Darguments[i].getComponent()
      =
lyr.rotevents.addEventListener(SkinWinRotator.rotevents.rotatevent)
     }
}
    SkinWinRotator.prototype.disableRotate=3Dfunction() {
     for (var i=3D0;i<arguments.length;i++) {
      var lyr=3Darguments[i].getComponent()
      =
lyr.rotevents.removeEventListener(SkinWinRotator.rotevents.rotatevent)
      }
}

I've created extensions (simular to DragEvent) that do various things =
for window/widget management.  This was an attempt at building simular =
on/off behavior inside of the widget itself, related to eventlisteners =
used within the same widget.

Hope this clears the mud some.

DS

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

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

This is a repost (previous one seems to have gotten lost :)

Once you split up parts of the API for every browser (that could eventually
include Opera, and other flavours) it means that people will start focusing
on a single browser because that's the browser they'll be using.  Ofcourse
this is already being done on a smaller scale (Dan's main focus seems to be
Netscape, and my focus is more IE5+) but at this point because of the code
being one , we know that what ever we do should also work Netscape.. once
you split things up I think this "awareness" will disappear and people will
just enhance the code for that single browser and let someone else worry
about the other browsers files.

"All this is done only to define two basic paisr of vars. Terrible. And
impossible just to skip the nn stuff, becoause it's not clear, what refers
to nn but only what is not for ie. I have to go through it and to
learn the"

that's correct, just two basic pairs of vars, so you want to split all code
up for simple things like these? And the fact that you have to go thru it
and learn the differences is exactly my point, if you have the chance to
only do your coding for IE, you will forget about NS and this might cause
you to implement things in IE that are not possible in NS.  Ofcourse this
means we're holding back one browser because of the incompatibilities with
the other, but that's the problem with cross-browser coding, and if you need
that extra functionality you should added it in your own code, not in the
general API.

The problem with speed that everybody talks about is not such a big issue,
we're not developing for 386 or 486 machines anymore, Pentium machines don't
take 2 or 3 clock-cycles to do a simple IF statement. Besides the IF
statements are only called at initialisation and when changing styles, the
main bottle-neck is not the IF statement but the time it takes browsers to
redo the style sheet (and rerender things).  This is just a browser problem,
not a code problem.

And ofcourse size isn't such a big issue neither, seeing that most of the
differences (I know, not all) are done on single lines as you pointed out:

is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset

this will only be a few bytes difference once you split it up:

e.x+document.body.scrollLeft

so maybe you save some bytes with the split but you have to include all
files multiple times and maintain all files multiple times for your site to
look good on all browsers.


apologies for the long post :)

cya,


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

RE: [Dynapi-Dev] general inheritence question

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

You don't really turn eventlisteners on and off, you add or remove them.
Adding listeners is obviously known to you.. and to turn them off you simply
use the   myLayer.removeEventListener(listener).   That would turn it off.
This ofcourse means you have to have a handle (or variable) to the
eventListener. So you can reattach it later.

I'm not sure what you mean with  "assigning dragability". Maybe if you show
us some code we can help you further (and it becomes clearer to us ;-)

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

  -----Oorspronkelijk bericht-----
  Van: dyn...@li...
[mailto:dyn...@li...]Namens Raymond Smith
  Verzonden: zondag 10 december 2000 17:45
  Aan: dyn...@li...
  Onderwerp: [Dynapi-Dev] general inheritence question


  I've been actively coding JavaScript about 3 months now.  And realizing
that:

  1)  That I know little.
  2)   Sweat is the greatest teacher of all.

  I have generally kept my questions to myself, allowing them to fuel
macabre nights of sleepless frustration till I figured it out myself.  The
value has been immeasurable.

  But... I appear to struggle the most with object method inheritance and
recently find myself staring at (Doesn't allow this method) alerts.  I've
been attempting to assign "dragablity" within a eventhandler of a widget and
also disabling/enabling other event handlers (that have nothing to do with
dragging, I just want to dynamically turn them off and on..  I worked with
Rainwater's post a bit and got to see more (Doesn't allow this method)
alerts.

  A short tutorial form an old-timer would be appreciated..

  DS

Re: [Dynapi-Dev] Dynacore preview release

[Richard :o <ma...@ri...>]

hi,
a bug found in the examples on ie5.5 WinMe:
* dynacore.api.frames.htm        error message:
            line24 char 2 object doesn't support this property or method.
Cheers,
Richard.

Ps I'm planning on grouping as many as possible examples, as included in the
examples directory (like Dan's
http://www.dansteinman.com/dynapi/docs/examples-summary.html , but for
DynAPI2) on my DynAPI info page (under construction).
May I include/adapt your examples & examples of widgets (ie skinwindow etc)
with the official DynAPI release, or rather not?


----- Original Message -----
From: "Pascal Bestebroer" <pa...@dy...>
To: "Dev" <dyn...@li...>
Sent: Sunday, December 10, 2000 1:41 PM
Subject: [Dynapi-Dev] Dynacore preview release


> I just uploaded a preview release of my Dynacore distribution, this is
> mainly interesting for the other developers. I think some of the ideas I
> added could be very good implementations for the official version. The
most
> important change is the making of the DynObject.
>
> you can find it here http://www.dynamic-core.net/dynacore.zip
>
> This object is now the base class of the DynLayer and DynDocument, and it
> implements all the child-parent functionality shared by these objects. The
> idea is that you could use the DynObject as a base class for management
> widgets like  FocusManager, ThreadManager, LayoutManager, etc.. These
> widgets are not using any visible components, but do need the
> add/delete/remove functionality.
>
> The current event code is mainly extending the DynObject, but my goal is
to
> have it only extend this object and not the DynLayer/DynDocuments.. so
that
> it is really a seperate object/extension.
>
> Another important addition is the manual part, this contains the full
> tutorial, and the developers reference. Somebody should update the
reference
> for the official DynAPI (unless the dynobject code is also copied into the
> official release, this would make it almost 100% correct).
>
> For more info on the changes you can read the "changes" part of the
manual.
>
> cya,
>
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> ____________________________________________________________
> Get your FREE personal .com domain name and
> NAMEzero Personal Portal at: http://www.namezero.com.
> For customer service, mailto:cus...@na....
>
>

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

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

What advantage would you gain by splitting up your example?  Speed
wise, that is not the reason for loading taking a long time.  The
speed problems are due to DynLayer creation.  If you haven't seen yet,
Dan is creating a new inline dynlayer creation system that will speed
up this process.  While splitting up the core files may seem nice, it
offers no real advantage.  Especially with the new jspack files, the
file sizes are going to be small anyways.

-- 
// Robert Rainwater

On 12/9/2000, 3:13:32 AM EST, SReindl wrote about "AW: [Dynapi-Dev] DynAPI build, Splitting files":

> Well, call it as you like: Lib ode API, ... An API has the task to supply
> you with a unique set of functions in order to perform some development
> tasks. In this case this is cross browser compatible programming of web
> sites (btw, an API can be stored in a lib ;-))
> I agree, that the API is not meant to be a play ground for fancy stuff which
> may be possible only for one particular browser.
> But I don't see why the "streaming of the project" should be more work for
> separate files than for monolithic ones.
> It's the definition of the basis of functions which is important, and this
> task has already been done, since the DynAPI is up and running.

> Look at this piece (from events.js):
>         this.pageX=is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
>         this.pageY=is.ie?e.y+document.body.scrollTop:e.pageY-window.pageYOffset
>         this.x=is.ie?e.offsetX:e.layerX
>         this.y=is.ie?e.offsetY:e.layerY
>         var b = is.ie?e.button:e.which
>         if (is.ie){
>                 if (b==2) b = 3
>                 else if (b==4) b = 2
>         } else { }
> All this is done only to define two basic paisr of vars. Terrible. And
> impossible just to skip the nn stuff, becoause it's not clear, what refers
> to nn but only what is not for ie. I have to go through it and to learn the
> syntax of several browsers (document.body.scrollLeft vs window.pageXOffset,
> etc., and do not forget the sign).

> My
>> "I mean, I want to develop mainly for IE and am not interested in the nn
>> specifics at all. I am satisfied when it works."
> if of course *an example* only and not the goal of my programs.

> last not least, in addition to decrease in loading and rendering time there
> is one more feature which speaks for a split: control over completeness. If
> you have to assure that your implementation is complete you will have to
> code all the functions. The chance just to forget an if branch is smaller.

> I do not say that cross browser compatibility should be given up, I think of
> how this task can be done in a more transparent way.
> Stephan





>> An API is a middle-layer between the code and the "environment"  seeing as
>> you want to have cross-browser code it sounds better to see one single api
>> file that takes care of all browsers.. not having seperate files for every
>> browser (that would create a DHTML library, not an API.. simple solution
>> change the name to DynLib :)
>>
>> Developing in seperate files for seperate browsers WILL create seperate
>> things, even though there is talk about setting "rules" for the
>> development,
>> we have to face it that streaming this whole project is not
>> something any of
>> us is good at.. so sticking to the development rules (even when
>> you could do
>> cool things like using behaviours in IE5 for filter effects and
>> stuff) will
>> be, in my opinion, impossible to maintain.  Almost the same as asking
>> Netscape and Microsoft to stick to the W3C standard.. (and then
>> making sure
>> that the W3C doesn't change everything every year :-)
>>
>> Someone debugging NN code should just skip the part that says  if
>> (is.ie) ..
>> that's not a hard thing to do.
>>
>> Also I don't see where you could make the speed advantages? the
>> slowness of
>> it all is within the browsers.. try changing a single stylesheet property,
>> in IE it looks like it's rerendering everything on screen and I believe
>> that's the main problem, so how can you increase speed when
>> splitting things
>> up?
>>
>> "I mean, I want to develop mainly for IE and am not interested in the nn
>> specifics at all. I am satisfied when it works."
>>
>> Then why use a cross-browser API (or library for that matter)?
>>
>>
>> Pascal Bestebroer
>> pa...@dy...
>> http://www.dynamic-core.net
>>
>>
>> >
>> > Can someone pls explain me the mneaning of this whole discussion?
>> > An API is a set of uniquely defined functions to perform a given
>> > task, isn't
>> > it?
>> > What do the widgets have to do with the API?
>> > Why should it be so difficult to develop the API in separate files?
>> > The discussion would be which function of the API should be added
>> > / removed
>> > / corrected / ...
>> > The rest will be done by the respective browser gurus.
>> > The charme of the split file version is that a nn specialist
>> > doesn't have to
>> > analyze a bulk of ie code in order to do his task.
>> > The increase in speed an code transparency should overweigh the
>> > difficulties
>> > of a split version by far.
>> > If a solution fullfills the defined function, who cares about
>> the details?
>> > I mean, I want to develop mainly for IE and am not interested in the nn
>> > specifics at all. I am satisfied when it works.
>> >
>> > Stephan
>> >


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

[Dynapi-Dev] general inheritence question

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

I've been actively coding JavaScript about 3 months now.  And realizing =
that:

1)  That I know little.=20
2)   Sweat is the greatest teacher of all.

I have generally kept my questions to myself, allowing them to fuel =
macabre nights of sleepless frustration till I figured it out myself.  =
The value has been immeasurable.

But... I appear to struggle the most with object method inheritance and =
recently find myself staring at (Doesn't allow this method) alerts.  =
I've been attempting to assign "dragablity" within a eventhandler of a =
widget and also disabling/enabling other event handlers (that have =
nothing to do with dragging, I just want to dynamically turn them off =
and on..  I worked with Rainwater's post a bit and got to see more =
(Doesn't allow this method) alerts.

A short tutorial form an old-timer would be appreciated..

DS

[Dynapi-Dev] Dynacore preview release

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

I just uploaded a preview release of my Dynacore distribution, this is
mainly interesting for the other developers. I think some of the ideas I
added could be very good implementations for the official version. The most
important change is the making of the DynObject.

you can find it here http://www.dynamic-core.net/dynacore.zip

This object is now the base class of the DynLayer and DynDocument, and it
implements all the child-parent functionality shared by these objects. The
idea is that you could use the DynObject as a base class for management
widgets like  FocusManager, ThreadManager, LayoutManager, etc.. These
widgets are not using any visible components, but do need the
add/delete/remove functionality.

The current event code is mainly extending the DynObject, but my goal is to
have it only extend this object and not the DynLayer/DynDocuments.. so that
it is really a seperate object/extension.

Another important addition is the manual part, this contains the full
tutorial, and the developers reference. Somebody should update the reference
for the official DynAPI (unless the dynobject code is also copied into the
official release, this would make it almost 100% correct).

For more info on the changes you can read the "changes" part of the manual.

cya,

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

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

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

Clear and precise. My sentiments exactly.

-----Ursprungligt meddelande-----
Från: SReindl <SR...@la...>
Till: dyn...@li... <dyn...@li...>
Datum: den 10 december 2000 10:17
Ämne: AW: [Dynapi-Dev] DynAPI build, Splitting files


>Well, call it as you like: Lib ode API, ... An API has the task to supply
>you with a unique set of functions in order to perform some development
>tasks. In this case this is cross browser compatible programming of web
>sites (btw, an API can be stored in a lib ;-))
>I agree, that the API is not meant to be a play ground for fancy stuff which
>may be possible only for one particular browser.
>But I don't see why the "streaming of the project" should be more work for
>separate files than for monolithic ones.
>It's the definition of the basis of functions which is important, and this
>task has already been done, since the DynAPI is up and running.
>
>Look at this piece (from events.js):
> this.pageX=is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
> this.pageY=is.ie?e.y+document.body.scrollTop:e.pageY-window.pageYOffset
> this.x=is.ie?e.offsetX:e.layerX
> this.y=is.ie?e.offsetY:e.layerY
> var b = is.ie?e.button:e.which
> if (is.ie){
> if (b==2) b = 3
> else if (b==4) b = 2
> } else { }
>All this is done only to define two basic paisr of vars. Terrible. And
>impossible just to skip the nn stuff, becoause it's not clear, what refers
>to nn but only what is not for ie. I have to go through it and to learn the
>syntax of several browsers (document.body.scrollLeft vs window.pageXOffset,
>etc., and do not forget the sign).
>
>My
>> "I mean, I want to develop mainly for IE and am not interested in the nn
>> specifics at all. I am satisfied when it works."
>if of course *an example* only and not the goal of my programs.
>
>last not least, in addition to decrease in loading and rendering time there
>is one more feature which speaks for a split: control over completeness. If
>you have to assure that your implementation is complete you will have to
>code all the functions. The chance just to forget an if branch is smaller.
>
>I do not say that cross browser compatibility should be given up, I think of
>how this task can be done in a more transparent way.
>Stephan
>
>
>
>
>
>> An API is a middle-layer between the code and the "environment"  seeing as
>> you want to have cross-browser code it sounds better to see one single api
>> file that takes care of all browsers.. not having seperate files for every
>> browser (that would create a DHTML library, not an API.. simple solution
>> change the name to DynLib :)
>>
>> Developing in seperate files for seperate browsers WILL create seperate
>> things, even though there is talk about setting "rules" for the
>> development,
>> we have to face it that streaming this whole project is not
>> something any of
>> us is good at.. so sticking to the development rules (even when
>> you could do
>> cool things like using behaviours in IE5 for filter effects and
>> stuff) will
>> be, in my opinion, impossible to maintain.  Almost the same as asking
>> Netscape and Microsoft to stick to the W3C standard.. (and then
>> making sure
>> that the W3C doesn't change everything every year :-)
>>
>> Someone debugging NN code should just skip the part that says  if
>> (is.ie) ..
>> that's not a hard thing to do.
>>
>> Also I don't see where you could make the speed advantages? the
>> slowness of
>> it all is within the browsers.. try changing a single stylesheet property,
>> in IE it looks like it's rerendering everything on screen and I believe
>> that's the main problem, so how can you increase speed when
>> splitting things
>> up?
>>
>> "I mean, I want to develop mainly for IE and am not interested in the nn
>> specifics at all. I am satisfied when it works."
>>
>> Then why use a cross-browser API (or library for that matter)?
>>
>>
>> Pascal Bestebroer
>> pa...@dy...
>> http://www.dynamic-core.net
>>
>>
>> >
>> > Can someone pls explain me the mneaning of this whole discussion?
>> > An API is a set of uniquely defined functions to perform a given
>> > task, isn't
>> > it?
>> > What do the widgets have to do with the API?
>> > Why should it be so difficult to develop the API in separate files?
>> > The discussion would be which function of the API should be added
>> > / removed
>> > / corrected / ...
>> > The rest will be done by the respective browser gurus.
>> > The charme of the split file version is that a nn specialist
>> > doesn't have to
>> > analyze a bulk of ie code in order to do his task.
>> > The increase in speed an code transparency should overweigh the
>> > difficulties
>> > of a split version by far.
>> > If a solution fullfills the defined function, who cares about
>> the details?
>> > I mean, I want to develop mainly for IE and am not interested in the nn
>> > specifics at all. I am satisfied when it works.
>> >
>> > Stephan
>> >
>
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

RE: [Dynapi-Dev] group is undifined

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

Not sure which version you'r using but the filename   core.api....    is
probably
dynapi.api.... or
dynacore.api...

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

  -----Oorspronkelijk bericht-----
  Van: dyn...@li...
[mailto:dyn...@li...]Namens Eytan Heidingsfeld
  Verzonden: zondag 10 december 2000 11:33
  Aan: dyn...@li...
  Onderwerp: [Dynapi-Dev] group is undifined


  Hi guys,
  I'm trying to include the dyn api with the following code
  <script src="../../dynapi.js"></script>
  <script>
  DynAPI.setLibraryPath('../../lib2.0/')
  DynAPI.include('core.api.*');
  DynAPI.include('core.ext.*');
  </script>

  But before the page finishes loading a get an error "group undefined"



  Does anyone know whats going on?

  Eytan Heidingsfeld

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

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

Once you split up parts of the API for every browser (that could eventually
include Opera, and other flavours) it means that people will start focusing
on a single browser because that's the browser they'll be using.  Ofcourse
this is already being done on a smaller scale (Dan's main focus seems to be
Netscape, and my focus is more IE5+) but at this point because of the code
being one , we know that what ever we do should also work Netscape.. once
you split things up I think this "awareness" will disappear and people will
just enhance the code for that single browser and let someone else worry
about the other browsers files.

"All this is done only to define two basic paisr of vars. Terrible. And
impossible just to skip the nn stuff, becoause it's not clear, what refers
to nn but only what is not for ie. I have to go through it and to
learn the"

that's correct, just two basic pairs of vars, so you want to split all code
up for simple things like these? And the fact that you have to go thru it
and learn the differences is exactly my point, if you have the chance to
only do your coding for IE, you will forget about NS and this might cause
you to implement things in IE that are not possible in NS.  Ofcourse this
means we're holding back one browser because of the incompatibilities with
the other, but that's the problem with cross-browser coding, and if you need
that extra functionality you should added it in your own code, not in the
general API.

The problem with speed that everybody talks about is not such a big issue,
we're not developing for 386 or 486 machines anymore, Pentium machines don't
take 2 or 3 clock-cycles to do a simple IF statement. Besides the IF
statements are only called at initialisation and when changing styles, the
main bottle-neck is not the IF statement but the time it takes browsers to
redo the style sheet (and rerender things).  This is just a browser problem,
not a code problem.

And ofcourse size isn't such a big issue neither, seeing that most of the
differences (I know, not all) are done on single lines as you pointed out:

is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset

this will only be a few bytes difference once you split it up:

e.x+document.body.scrollLeft

so maybe you save some bytes with the split but you have to include all
files multiple times and maintain all files multiple times for your site to
look good on all browsers.


apologies for the long post :)

cya,

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

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens SReindl
> Verzonden: zaterdag 9 december 2000 9:14
> Aan: dyn...@li...
> Onderwerp: AW: [Dynapi-Dev] DynAPI build, Splitting files
>
>
> Well, call it as you like: Lib ode API, ... An API has the task to supply
> you with a unique set of functions in order to perform some development
> tasks. In this case this is cross browser compatible programming of web
> sites (btw, an API can be stored in a lib ;-))
> I agree, that the API is not meant to be a play ground for fancy
> stuff which
> may be possible only for one particular browser.
> But I don't see why the "streaming of the project" should be more work for
> separate files than for monolithic ones.
> It's the definition of the basis of functions which is important, and this
> task has already been done, since the DynAPI is up and running.
>
> Look at this piece (from events.js):
>
> this.pageX=is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
>
> this.pageY=is.ie?e.y+document.body.scrollTop:e.pageY-window.pageYOffset
> 	this.x=is.ie?e.offsetX:e.layerX
> 	this.y=is.ie?e.offsetY:e.layerY
> 	var b = is.ie?e.button:e.which
> 	if (is.ie){
> 		if (b==2) b = 3
> 		else if (b==4) b = 2
> 	} else { }
> All this is done only to define two basic paisr of vars. Terrible. And
> impossible just to skip the nn stuff, becoause it's not clear, what refers
> to nn but only what is not for ie. I have to go through it and to
> learn the
> syntax of several browsers (document.body.scrollLeft vs
> window.pageXOffset,
> etc., and do not forget the sign).
>
> My
> > "I mean, I want to develop mainly for IE and am not interested in the nn
> > specifics at all. I am satisfied when it works."
> if of course *an example* only and not the goal of my programs.
>
> last not least, in addition to decrease in loading and rendering
> time there
> is one more feature which speaks for a split: control over
> completeness. If
> you have to assure that your implementation is complete you will have to
> code all the functions. The chance just to forget an if branch is smaller.
>
> I do not say that cross browser compatibility should be given up,
> I think of
> how this task can be done in a more transparent way.
> Stephan

[Dynapi-Dev] group is undifined

[Eytan H. <ey...@tr...>]

Hi guys,
I'm trying to include the dyn api with the following code
<script src=3D"../../dynapi.js"></script>
<script>
DynAPI.setLibraryPath('../../lib2.0/')
DynAPI.include('core.api.*');
DynAPI.include('core.ext.*');
</script>

But before the page finishes loading a get an error "group undefined"



Does anyone know whats going on?

Eytan Heidingsfeld

Re: [Dynapi-Dev] Button/DynImage - I am fixing this

[Eytan H. <ey...@tr...>]

I have looked at how the images work. I have made somthing similair but I
find more simple. I created a TImage which in its constructor creates a
"real" image (as in an IMG tag) then I can play with it using function I
have created. Resizing would simply mean call ImgName.width and changing it.

8an

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

[SReindl <SR...@la...>]

Well, call it as you like: Lib ode API, ... An API has the task to supply
you with a unique set of functions in order to perform some development
tasks. In this case this is cross browser compatible programming of web
sites (btw, an API can be stored in a lib ;-))
I agree, that the API is not meant to be a play ground for fancy stuff which
may be possible only for one particular browser.
But I don't see why the "streaming of the project" should be more work for
separate files than for monolithic ones.
It's the definition of the basis of functions which is important, and this
task has already been done, since the DynAPI is up and running.

Look at this piece (from events.js):
	this.pageX=is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
	this.pageY=is.ie?e.y+document.body.scrollTop:e.pageY-window.pageYOffset
	this.x=is.ie?e.offsetX:e.layerX
	this.y=is.ie?e.offsetY:e.layerY
	var b = is.ie?e.button:e.which
	if (is.ie){
		if (b==2) b = 3
		else if (b==4) b = 2
	} else { }
All this is done only to define two basic paisr of vars. Terrible. And
impossible just to skip the nn stuff, becoause it's not clear, what refers
to nn but only what is not for ie. I have to go through it and to learn the
syntax of several browsers (document.body.scrollLeft vs window.pageXOffset,
etc., and do not forget the sign).

My
> "I mean, I want to develop mainly for IE and am not interested in the nn
> specifics at all. I am satisfied when it works."
if of course *an example* only and not the goal of my programs.

last not least, in addition to decrease in loading and rendering time there
is one more feature which speaks for a split: control over completeness. If
you have to assure that your implementation is complete you will have to
code all the functions. The chance just to forget an if branch is smaller.

I do not say that cross browser compatibility should be given up, I think of
how this task can be done in a more transparent way.
Stephan





> An API is a middle-layer between the code and the "environment"  seeing as
> you want to have cross-browser code it sounds better to see one single api
> file that takes care of all browsers.. not having seperate files for every
> browser (that would create a DHTML library, not an API.. simple solution
> change the name to DynLib :)
>
> Developing in seperate files for seperate browsers WILL create seperate
> things, even though there is talk about setting "rules" for the
> development,
> we have to face it that streaming this whole project is not
> something any of
> us is good at.. so sticking to the development rules (even when
> you could do
> cool things like using behaviours in IE5 for filter effects and
> stuff) will
> be, in my opinion, impossible to maintain.  Almost the same as asking
> Netscape and Microsoft to stick to the W3C standard.. (and then
> making sure
> that the W3C doesn't change everything every year :-)
>
> Someone debugging NN code should just skip the part that says  if
> (is.ie) ..
> that's not a hard thing to do.
>
> Also I don't see where you could make the speed advantages? the
> slowness of
> it all is within the browsers.. try changing a single stylesheet property,
> in IE it looks like it's rerendering everything on screen and I believe
> that's the main problem, so how can you increase speed when
> splitting things
> up?
>
> "I mean, I want to develop mainly for IE and am not interested in the nn
> specifics at all. I am satisfied when it works."
>
> Then why use a cross-browser API (or library for that matter)?
>
>
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
>
>
> >
> > Can someone pls explain me the mneaning of this whole discussion?
> > An API is a set of uniquely defined functions to perform a given
> > task, isn't
> > it?
> > What do the widgets have to do with the API?
> > Why should it be so difficult to develop the API in separate files?
> > The discussion would be which function of the API should be added
> > / removed
> > / corrected / ...
> > The rest will be done by the respective browser gurus.
> > The charme of the split file version is that a nn specialist
> > doesn't have to
> > analyze a bulk of ie code in order to do his task.
> > The increase in speed an code transparency should overweigh the
> > difficulties
> > of a split version by far.
> > If a solution fullfills the defined function, who cares about
> the details?
> > I mean, I want to develop mainly for IE and am not interested in the nn
> > specifics at all. I am satisfied when it works.
> >
> > Stephan
> >

Re: [Dynapi-Dev] Adding/Removing Event Layers

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

You need a reference to the eventlistener object and then you call
removeEventListener(listenerobj);

One way is something like:

MyWidget.listener = new EventListener()
MyWidget.oncreate = function(e) {
   var o = e.getSource(); ....
}
MyWidget.prototype.dosomething = function() {
   if (...) this.addEventListener(MyWidget.listener);
   else this.removeEventListener(MyWiget.Listener();
}

-- 
// Robert Rainwater

On 12/9/2000, 7:32:25 PM EST, Raymond wrote about "[Dynapi-Dev] Adding/Removing Event Layers":

> Bit stumped by this one.  Trying to emulate dragevent
> (attachable/unattachable behavior) within a Widget without having to write
> the eventhandler as a separate ext.  I've tried alot of different reference
> scenarios to remove a created dynevent events handler nested in a DynLayer
> attached to a parent layer.  How can I unattach and reattach this
> dynamically?

> Thanks

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

Re[6]: [Dynapi-Dev] compression?

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

Thats why I don't think the gzip and jars need to be in the release.
I tested a simple gzip file on Netscape Enterprise Server and it did
not work.

-- 
// Robert Rainwater

On 12/9/2000, 9:37:53 PM EST, Jorge wrote about "[Dynapi-Dev] compression?":

> Thats right.
> the server has to send content header telling the browser that it is gzip
> encoded.

> Best Regards,
> Jorge C.
> ----- Original Message -----
> From: Robert Rainwater <rra...@ya...>
> To: DynAPI Development List <dyn...@li...>
> Sent: Saturday, December 09, 2000 7:44 PM
> Subject: Re[4]: [Dynapi-Dev] compression?


>>
>> I don't think that totally correct.  It depends on how the server
>> handles gzip.  Try loading a gziped js file in IE 5 locally.  It
>> doesn't work.
>>
>> --
>> // Robert Rainwater
>>
>> On 12/9/2000, 8:11:42 PM EST, Jorge wrote about "[Dynapi-Dev]
> compression?":
>>
>> > Every HTTP 1.1 compliant browser can understand gzip encoding.
>>
>> > Best Regards,
>>
>> > Jorge C.
>>
>> > ----- Original Message -----
>> > From: Brandon Myers <bnd...@ho...>
>> > To: <dyn...@li...>
>> > Sent: Saturday, December 09, 2000 1:10 PM
>> > Subject: Re: Re[2]: [Dynapi-Dev] compression?
>>
>>
>> >> Will netscape understand it as well?
>> >>
>> >> ----- Original Message -----
>> >> From: "Alexey Medvedev" <ma...@ca...>
>> >> To: "DynAPI Development List" <dyn...@li...>
>> >> Sent: Saturday, December 09, 2000 6:23 AM
>> >> Subject: Re: Re[2]: [Dynapi-Dev] compression?
>> >>
>> >>
>> >> > > One thing I don't understand are the JAR and gzip compressed files.
> It
>> >> > > seems there are very little cases where you could use them. Most
> users
>> >> >
>> >> > Why?
>> >> >
>> >> > > that the gzipped files even work in IE 5 (they don't seem to).
> Aren't
>> >> >
>> >> > If you will put them to Apache Web Server (and other imho).
>> >> >   Server will send header:
>> >> > Content-Encoding: gzip
>> >> > IE5 understands it.
>> >> >
>> >> > Malx
>> >> >
>> >> > _______________________________________________
>> >> > 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
>>
>>
>> _______________________________________________
>> 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[4]: [Dynapi-Dev] compression?

[Jorge L. <jo...@ne...>]

Thats right.
the server has to send content header telling the browser that it is gzip
encoded.

Best Regards,
Jorge C.
----- Original Message -----
From: Robert Rainwater <rra...@ya...>
To: DynAPI Development List <dyn...@li...>
Sent: Saturday, December 09, 2000 7:44 PM
Subject: Re[4]: [Dynapi-Dev] compression?


>
> I don't think that totally correct.  It depends on how the server
> handles gzip.  Try loading a gziped js file in IE 5 locally.  It
> doesn't work.
>
> --
> // Robert Rainwater
>
> On 12/9/2000, 8:11:42 PM EST, Jorge wrote about "[Dynapi-Dev]
compression?":
>
> > Every HTTP 1.1 compliant browser can understand gzip encoding.
>
> > Best Regards,
>
> > Jorge C.
>
> > ----- Original Message -----
> > From: Brandon Myers <bnd...@ho...>
> > To: <dyn...@li...>
> > Sent: Saturday, December 09, 2000 1:10 PM
> > Subject: Re: Re[2]: [Dynapi-Dev] compression?
>
>
> >> Will netscape understand it as well?
> >>
> >> ----- Original Message -----
> >> From: "Alexey Medvedev" <ma...@ca...>
> >> To: "DynAPI Development List" <dyn...@li...>
> >> Sent: Saturday, December 09, 2000 6:23 AM
> >> Subject: Re: Re[2]: [Dynapi-Dev] compression?
> >>
> >>
> >> > > One thing I don't understand are the JAR and gzip compressed files.
It
> >> > > seems there are very little cases where you could use them. Most
users
> >> >
> >> > Why?
> >> >
> >> > > that the gzipped files even work in IE 5 (they don't seem to).
Aren't
> >> >
> >> > If you will put them to Apache Web Server (and other imho).
> >> >   Server will send header:
> >> > Content-Encoding: gzip
> >> > IE5 understands it.
> >> >
> >> > Malx
> >> >
> >> > _______________________________________________
> >> > 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
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
>

Re[4]: [Dynapi-Dev] compression?

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

I don't think that totally correct.  It depends on how the server
handles gzip.  Try loading a gziped js file in IE 5 locally.  It
doesn't work.

-- 
// Robert Rainwater

On 12/9/2000, 8:11:42 PM EST, Jorge wrote about "[Dynapi-Dev] compression?":

> Every HTTP 1.1 compliant browser can understand gzip encoding.

> Best Regards,

> Jorge C.

> ----- Original Message -----
> From: Brandon Myers <bnd...@ho...>
> To: <dyn...@li...>
> Sent: Saturday, December 09, 2000 1:10 PM
> Subject: Re: Re[2]: [Dynapi-Dev] compression?


>> Will netscape understand it as well?
>>
>> ----- Original Message -----
>> From: "Alexey Medvedev" <ma...@ca...>
>> To: "DynAPI Development List" <dyn...@li...>
>> Sent: Saturday, December 09, 2000 6:23 AM
>> Subject: Re: Re[2]: [Dynapi-Dev] compression?
>>
>>
>> > > One thing I don't understand are the JAR and gzip compressed files. It
>> > > seems there are very little cases where you could use them. Most users
>> >
>> > Why?
>> >
>> > > that the gzipped files even work in IE 5 (they don't seem to). Aren't
>> >
>> > If you will put them to Apache Web Server (and other imho).
>> >   Server will send header:
>> > Content-Encoding: gzip
>> > IE5 understands it.
>> >
>> > Malx
>> >
>> > _______________________________________________
>> > 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] compression?

[Jorge L. <jo...@ne...>]

Every HTTP 1.1 compliant browser can understand gzip encoding.

Best Regards,

Jorge C.

----- Original Message -----
From: Brandon Myers <bnd...@ho...>
To: <dyn...@li...>
Sent: Saturday, December 09, 2000 1:10 PM
Subject: Re: Re[2]: [Dynapi-Dev] compression?


> Will netscape understand it as well?
>
> ----- Original Message -----
> From: "Alexey Medvedev" <ma...@ca...>
> To: "DynAPI Development List" <dyn...@li...>
> Sent: Saturday, December 09, 2000 6:23 AM
> Subject: Re: Re[2]: [Dynapi-Dev] compression?
>
>
> > > One thing I don't understand are the JAR and gzip compressed files. It
> > > seems there are very little cases where you could use them. Most users
> >
> > Why?
> >
> > > that the gzipped files even work in IE 5 (they don't seem to). Aren't
> >
> > If you will put them to Apache Web Server (and other imho).
> >   Server will send header:
> > Content-Encoding: gzip
> > IE5 understands it.
> >
> > Malx
> >
> > _______________________________________________
> > 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] Adding/Removing Event Layers

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

Bit stumped by this one.  Trying to emulate dragevent
(attachable/unattachable behavior) within a Widget without having to write
the eventhandler as a separate ext.  I've tried alot of different reference
scenarios to remove a created dynevent events handler nested in a DynLayer
attached to a parent layer.  How can I unattach and reattach this
dynamically?

Thanks