dynapi-dev

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

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