In my opinion I would say that only the DynLayer and MouseEvent files needs to be split into separate files for supported browsers as they differ from browser to browser:
dynlayer_ie.js, mouse_ie.js dynlayer_ns4.js, mouse_ns4.js dynlayer_dom.js, mouse_dom.js I've looked into the idea for having a "Common set of Methods" for each object that is to be branched, but this proved difficult to maintain. For example: let's say we have dynlayer.js containing the common set of methods, while dynlayer_ie dynlayer_ns4, etc contains browser specific codes. A bug was then later detected in a DOM browser with the setTextSelectable() method which is inside the common methods file. The developer would have to do one of two things: 1) move setTextSelectable() out of the common library and add it into the branched files (dynlayer_ie, dynlayer_ns4, etc) 2) leave setTextSelectable() inside the common methods file but add setTextSelectable() inside the dynlayer_dom file to over write setTextSelectable() inside the common library. Can you imagine the amount time it would take to compare the branched file with the common file to see what functions exist within the common file? I think it's much easier to have all the methods for a desired object inside it's branched file. This way we could target specific methods and not have to worry about it affecting other browsers, or whether or not it should be placed into branched files or stay inside the common file. Adding a new method would simply require that the deveolper updates all the branches, but would give room for him or her to add browser specific code for the new method in each branch without conflicts or duplicating methods. I don't think it's necessary for us to brach the files by platform due to the following reasons: 1) Platform differences are minimal and often time would require a very small change to a method. 2) Too many files for developers to work with: for example: dynlayer.js dynlayer_ie_pc.js dynlayer_ie_ppc.js dynlayer_ie_mac.js dynlayer_ns4_pc.js dynlayer_ns4_mac.js dynlayer_ns4_linux.js dynlayer_opera_pc.js dynlayer_opera_mac.js dynlayer_opera_linux.js dynlayer_dom_pc.js dynlayer_dom_mac.js dynlayer_dom_linux.js dynlayer_dom_other.js ... and that's only for dynlayer! Most of these branched files would however be very small (estimated under 500 bytes) but it's probably be easier to do a simple if (dynapi.ua.mac) for one or two lines as oppose to creating a completly new file just to add those two lines of code. As discussed earlier it's best that we look at making dynapi more DOM compliant as more and more browsers are been developed to be DOM compliant. DynAPI will still continue to support ns4,ie4 and other non-dynamic (or non-DOM) browsers. But when a new browser is been release that's DOM compliant DynAPI should work with that browser (e.g. Safari) without modifications. The idea is that we use ua.dom instead of ua.ns6 or ua.opera when creating widgets or libraries. Only in cases where browser specific functions are required then ua.ns6, ua.opera, etc be should used: ua.ns4 - for ns4 specific functions ua.ie - for ie specific functions (ie4+) ua.dom - for DOM browsers (ns6,moz,opera,safari,etc) ua.opera - for opera specific functions (opera6/7) ua.safari - for safari specific functions. I believe that ua.ns4, ua.ie and ua.dom will be the three main variables used when creating widgets. -- Raymond Irving --- Joy Ride <[EMAIL PROTECTED]> wrote: > Hello, > > There has been some discussion about how browser > support for DynAPI3 should > be branched. We would use the "sum of largest > common" -method for that. > Based on our tests and knowledge base branching > would look like this (some > of you have allready suggested similar tree to > ours): > > Common > | > |__DOM > | | > | |__MSIE5/6 > | | | > | | |__MAC > | | | > | | |__PC > | | > | |__NS6/7 > | | | > | | |__PC > | | | > | | |__Linux/MAC*** > | | > | |__Opera 7*/**** > | | > | |__Mozilla*/**** > | > |__NS4 > | > |__MSIE4 > | > |__Opera5/6 > | > |__PocketPC MSIE 2002** > > Some explanations > * It maybe possible to combine this branch with > NS6/7 branch > ** Needs more consideration and documentation before > it can be decided if > it's possible to support Pocket PC MSIE, basically > Pocket PC MSIE 2002 is > MSIE5 without some features > *** There maybe need to separate MAC and Linux > branches, they are prety > close to each other, but there may be some > differences > **** At this point we do not have information if > these browsers need > separate platform branches to be fully supported. > > By branching I do not mean that everything should be > coded for each branch. > Just the parts, which do need either optimization or > extran compability. In > our opinion this way we could create the maximun set > of features for each > browser and optimize the performance for each > browser enough. > > What do you think about this approach? > > > - Juho Risku > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months > FREE*. > http://join.msn.com/?page=features/featuredemail > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Dynapi-Dev mailing list > [EMAIL PROTECTED] > http://www.mail-archive.com/[email protected]/ __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/[email protected]/
