GregS said:
Randy, the approach I just described (the one of using object
oriented JS classes) is very effective from developer's point
of view.
It certainly can be, though it can also be over the top if the context
of its application is sufficiently simple.
If someone wants to learn more about this technique,
they are welcome to our forums.
Maybe they are, but anyone reading the suggestion has already discovered
comp.lang.javascript, where they may get the attention of quite a number
of contributors, some of whom specialise in OO javascript.
I'm sorry that you got the wrong impression; I do
not see anything wrong in inviting people to our forums.
You do not have to go there if you do not want to.
That question is probably best addressed by considering what would be
best for the OP. A small private forum with maybe a couple of (more or
less) knowledgeable contributors or a public newsgroup where any
responses given will be subject to critical peer-review, and a diversity
of opinions expressed and debated? If the OP is happy to comply with
Usenet conventions the latter is likely to be the more productive
activity.
As far as HTML/script on the main page is concerned,
I do not see anything wrong with it.
You don't? You have mark-up like:-
| <P> </P>
| <P> </P>
| <P> </P>
| <P> </P>
| <P> </P>
| <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
| <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
| <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
| <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
| <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
| <P align=left> </P></BLOCKQUOTE></BLOCKQUOTE>
| </BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>
| <P> </P>
| <P> </P>
| <P> </P>
| <P> </P>
- and you don't see anything wrong with that? And why does a page that
imports no less than 14 stylesheets need so many inline style
attributes?
This site was created in IAB Studio, and pages
are created in its WYSIWYG editors; what you actually
see in the browser is HTML generated on the fly.
And doesn't it take an age to load? (Not surprising given the mark-up
bloat, but it also feels like the image optimisation leaves a lot to be
desired.)
Our approach is different what the usual web site would
use, but it's more productive in many ways.
We also use a lot of advanced JS techniques, if you are interested
to learn more about it, you are welcome to visit our site.
"advanced JS techniques"; not an easy claim to quantify. One person's
advanced technique is old-hat to another, and a bad idea to a third. A
few months ago I looked at a javascript book that featured the work
"advanced" in its title, and found a collection of techniques so bad
that many would qualify as dangerous. I recall Jim Ley suggesting that
the most advanced javascript in the world was to be found in posts to
comp.lang.javascript, and I find that a reasonable assertion when I
monitor javascript blogs and find individuals enthusing about 'new'
techniques that have been being posted to this group on and off for a
couple of years. That is just a consequence of the group having a
reasonable core of enthusiastic contributors interested in trying out
new ideas (newly invented or just new to them) and doing so under the
critical scrutiny of their fellows. (the bad ideas, and the poor
implementations, get pointed out very quickly)
Still, without getting into how advance any particular technique may be,
the code on <URL:
http://www.worcsnet.com > is not without relevance in
this context. Taking just one file at random:-
| <SCRIPT LANGUAGE="JavaScript1.2"
| SRC="/js/Common/HttpRequest.js"></SCRIPT>
-, and disregarding the invalid HTML 4.01 markup with its deprecated
(and inadvisable) language attribute, We find the script:-
<quote>
var QueryType = { SqlQuery:0};
var DataRequestType = {
SQL : 0,
/*Regular SQL Query*/
Search : 1,
/*Search query; SearchClass tells the Java class name, the rest
is search-specific*/
Lookup : 2,
Update : 3,
Validate:4,
UDCLayout : 5,
FormUpdate : 6,
DewUpdate:7,
PageUpdate : 8,
PageContentUpdate : 9,
ReloadLookup : 10
};
function HttpRequest (id, docObj) {
this.id = id;
this.docObj=docObj;
if(typeof (this.constructor.prototype.PrototypeFinishedHttpRequest)
== 'undefined'){
this.constructor.prototype.prepareDataRequest=prepareDataRequest;
this.constructor.prototype.PrototypeFinishedHttpRequest=true;
};
function prepareFormDOM(targetFrameId, docObj, id, action,
method, params){
var formObj = docObj.document.createElement ("FORM");
docObj.document.body.appendChild (formObj);
formObj.id = id;
formObj.action = action;
formObj.method = method;
formObj.target = "_self";
for (var i = 0; i < params.length; i ++){
for (j in params
){
var paramName = j;
var paramValue = params [j];
var inputDef = "INPUT";
var inputHidden = docObj.document.createElement(inputDef);
inputHidden.setAttribute ("name", paramName);
inputHidden.setAttribute ("type", "hidden");
inputHidden.setAttribute ("value", paramValue);
formObj.appendChild (inputHidden);
}
}
return formObj;
};
function prepareDataRequest(targetFrameId, queryType,
requestType, params){
var returnObj = null;
switch (queryType){
case QueryType.SqlQuery:
params.push ({QT:"SQL"});
break;
}
var requestHost = GetIABBaseURL() + '/DataRequestHandler';
switch (requestType){
case DataRequestType.SQL:
params.push ({RT:"SQL"});
break;
case DataRequestType.Search:
params.push ({RT:"Search"});
break;
case DataRequestType.Lookup:
params.push ({RT:"Lookup"});
break;
case DataRequestType.Update:
params.push ({RT:"Update"});
break;
case DataRequestType.Validate:
params.push ({RT:"Validate"});
break;
case DataRequestType.UDCLayout:
params.push ({RT:"UDCLayout"});
break;
case DataRequestType.FormUpdate:
params.push ({RT:"FormUpdate"});
break;
case DataRequestType.DewUpdate:
params.push ({RT:"DewUpdate"});
break;
case DataRequestType.PageUpdate:
params.push ({RT:"PageUpdate"});
break;
case DataRequestType.PageContentUpdate:
params.push ({RT:"PageContentUpdate"});
break;
case DataRequestType.ReloadLookup:
params.push ({RT:"reloadLookup"});
break;
}
returnObj = prepareFormDOM (targetFrameId, this.docObj, this.id,
requestHost, "POST", params);
return returnObj;
};
}
</quote>
Where apparent misconceptions about the nature of javascript, its OO
application, and a disregard for OO general principles, has resulted in
an implementation that is approaching being perverse.
The mistake of making the - j - variable in - prepareFormDOM - global is
obvious and easily rectified. The main faults lie in the design of the -
HttpRequest - 'class'. First the data objects - QueryType - and -
DataRequestType - are clearly bound with the 'class' in their
employment, but both are created as global variables. OO design would
have suggested both be contained by the 'class'; so static, preferably
private static as they should not be needed outside of the 'class' and
its instances, but public static would have been satisfactory (and
simpler to implement with javascript).
The - HttpRequest - constructor features two inner function definitions
(both followed by empty statements for some unknown reason), neither
make any use of the fact that they are inner functions, and indeed only
the function object instances created during the instantiation of the
first - HttpRequest - object are ever used. The function objects created
during subsequent executions of the - HttpRequest - do no more than
consume clock cycles being created and memory space while they are
awaiting garbage collection.
The first instance of the - prepareDataRequest - function created will
be assigned to the prototype of the - HttpRequest - function, but the
test for that assignment is repeated on all subsequent executions of -
HttpRequest -. This is certainly a case where the normal practice of
assigning a function reference to a property of the function's prototype
would be simpler, and more efficient.
Of course it is the closure formed with the instantiation of the first -
HttpRequest -, by assigning the - prepareDataRequest - function to the
constructor's prototype, that allows the - prepareDataRequest - function
to access the first instance of the - prepareFormDOM -, but that
particular closure (with its consequential needless overheads on
subsequent - HttpRequest - object instantiations) is not the only means
of making that function available. Indeed it is questionable whether it
makes any sense for - prepareFormDOM - to be a separate function as it
is always called form - prepareDataRequest - and unavailable to any
other code. But the fact that - prepareFormDOM - is only interested in
its parameters (has no interest in - HttpRequest - object instances,
even the first instance with which it is bound by the closure formed)
suggest that - prepareFormDOM - should be static in addition to the two
data structures (or at least more explicitly static).
So one implementation pattern that provides all of the encapsulation
called for the OO, and avoids the inefficiencies in the original might
go:-
var HttpRequest = (fucntion(){
var QueryType = { SqlQuery:0};
var DataRequestType = {
SQL : 0,
... //etc.
ReloadLookup : 10
};
function prepareFormDOM(targetFrameId, docObj, id, action,
method, params){
var formObj = docObj.document.createElement ("FORM");
... //etc.
return formObj;
}
function constr(id, docObj){
this.id = id;
this.docObj=docObj;
}
constr.prototype.prepareDataRequest = function(targetFrameId,
queryType, requestType, params){
switch (queryType){
case QueryType.SqlQuery:
params.push ({QT:"SQL"});
break;
}
... //etc.
return prepareFormDOM(targetFrameId, this.docObj, this.id,
requestHost, "POST", params);
};
return constr;
})();
So where would be the best place to go if you wanted to understand how
and why that formulation works?
Randy Webb <
[email protected]> wrote in message
<snip>
Please do not top-post to comp.lang.javascript.
Richard.
range;}