sundew wrote:
I am developing an open source DHTML project named
Wednus Window.
http://wednus.com
Wednus Window is a DHTML Web-Application Windowing
System. It shells websites/web-applications with fully
customizable DHTML window objects, and users also can
change its skin, so it can goes well with any website
layouts.
I have just released v0.3.5 beta1 and working on beta2
now, and hope to get your sugestions or any ideas on
improving it.
My first impression is of code that is massively more complex and
convoluted than it needs to be. That alone will place a significant
barrier in the way of the code being used in web applications as any
experienced web application developer would take one look at the source
and see a development/maintenance nightmare. Good documentation might
elevate that concern, if it revealed the system as having a small and
simple public interface, but my impression is that that isn't true so
complete documentation would not give such an impression.
In browser window systems are a problem crying out for an OO solution,
and a design separating responsibilitie s into easily identified units.
For example, a window manager object and a window instance object,
responsible for behaviour related to the state of the individual
windows, while the manager co-ordinates the windows, handling things
like z-index stacking. While that sort of concept may be buried
somewhere in the code it is a long way from being apparent.
A second impression is of code authored by individuals who don't
understand why they are doing what they are doing. An example might be
the line:-
| WS.load = function(cat,na me){document.wr ite('<scr'+
| 'ipt type="text/javascript" src="'+
| WS.path.root+ca t+'/'+name+
| '/'+name+'.js"><\/scr'+'ipt>');};
- form webnus.js, where the voodoo of splitting up and then
concatenating the script elements is combined with the escaping of the
slash in the closing '</' sequence, but both in a file that was designed
to be imported, and so not subject to that related issue at all.
Similar examples include code that branches to accommodate Natescape 4's
object model features, while other code assumes dynamic support for -
document.create Element -.
That impression of unskilled implementation is re-enforced by the
occurrence of both of the "dismiss this code out of hand" criteria for
javascript; browser detection by UA string, and using eval to resolve
property accessors. From dom.js:-
| WS.func.thisDiv OnTop = function(id){
| var t = 0;
| var z = (document.layer s) ? ".zIndex" : ".style.zIndex" ;
| var fun = (document.getEl ementById) ? "document.getEl ementById":
| "MM_findObj ";
| var arr = (document.layer s) ? document.layers : (document.all) ?
| document.all.ta gs("DIV") :
| document.getEle mentsByTagName( "DIV");
| for(var i = 0; i < arr.length; i++){
| var oz = eval("arr["+ i +"]" + z);
| if(oz > t){
| t = oz;
| }
| }
| var obj = eval(fun + "(id)");
| if(obj) eval(fun +"('"+ id +"')"+ z +" = parseInt("+ t +")+ 1");
| };
|
|
| //Detect the browser vendor and version number
| WS.cvar.agt = navigator.userA gent.toLowerCas e();
| WS.cvar.is_nav = ((WS.cvar.agt.i ndexOf('mozilla ')!=-1) &&
| (WS.cvar.agt.in dexOf('spoofer' )==-1) &&
| (WS.cvar.agt.in dexOf('compatib le') == -1) &&
| (WS.cvar.agt.in dexOf('opera')= =-1) &&
| (WS.cvar.agt.in dexOf('webtv')= =-1) &&
| (WS.cvar.agt.in dexOf('hotjava' )==-1));
| WS.cvar.is_geck o = (WS.cvar.agt.in dexOf('gecko') != -1);
| WS.cvar.is_ie = ((WS.cvar.agt.i ndexOf("msie") != -1) &&
| (WS.cvar.agt.in dexOf("opera") == -1));
| WS.cvar.is_oper a = (WS.cvar.agt.in dexOf("opera") != -1);
The examples all use invalid HTML, and there are examples of the use of
deprecated mark-up within the script. This deficiency on the part of the
author appears to have resulted in the impression that modern browsers
only operate in quirks mode. In the event that the script be exposed to
formally valid HTML it will significantly malfunction. In code written
for a specific context that might be acceptable but code aimed at
general use in a web application should really be written so that
aspects of browser behaviour that are influenced by factors external to
the script are taken into account and coped with.
The system as a whole does not have any facility to negate the IE
browser SELECT element burn-through problem. It is difficult to imagine
a web application that does not feature at least one SELECT element.
Being able to drag a window out of the top of the page in the browser
window is not a good idea as it risks rendering the title bar and button
of that window inaccessible (making continued use of that window
problematic).
Clicking the minimise buttons on the window appears to result in them
disappearing forever.
A web application using an in-browser window system will likely want to
react to the user's interactions with those windows. That would probably
be best facilitated by allowing external code to attach event handlers
to aspects of the window objects. That is, conceptually at the window
object level, not reaching into the HTML DOM for the window and
attaching browser event handlers to the contained elements. Being able
to attach arbitrary code to be executed when the window loads its
contents, is re-sized, scrolled and closed, would probably be the
minimum an in-browser widow system should facilitate.
Richard.
