Singleton desing patter approach without function expressions...

[Luke Matuszewski]

I am designing the library, which will hidden all its functions within
singleton object ... So for clients
they will use it like [functional_pref ix].[function_name] eg.

system.getEleme ntWithId('ruler ');
At library side, i will use constructs like follows (at global scope)
eg.

function System() {

function _getElementWith Id(id) {
/*
GENERIC CODE (using first DOM getElementById( id) and if not
successful
using document.all with some checks...)
*/
}

/*
MORE UTIL FUNCS
*/

this.getElement WithId = _getElementWith Id;
/*
MORE ASSIGMENTS like
this.[util_method] = _[util_method];
*/

}

var system = new System();

System = null; /* since System constructor is desinged to produce
singletons, and it
should not be visible after singleton
instantiation.. . */

My question is simple, can i use construct like:

System = null;

, to redefine constructor System reference to null ? If not, then how i
should do it ?
Also remember that i can't use function expressions like

function(...) { }

I will appreciate somebody knowlegable to lighten my problem...

Best regards
Luke Matuszewski

[Richard Cornford]

Luke Matuszewski wrote:

Matt Kruse wrote:

Luke Matuszewski wrote:

> Also remember that i can't use function expressions like
> function(...) { }
Oh, and what does that even mean?

Function expressions is expressions that returns function reference
(EcmaScript 3rd ed.- 13) like:

...
System.someFunc = function() {
/* CODE */
}
...

Function expressions where not present in EcmaScript 2nd
and 1st ed.(only function declarations where present).

I practice this is not an issue as anonymous function expressions were
implemented as an extension of ECMAScript in JavaScript 1.2 and JScript
3 (so Netscape 4 and IE 4 respectively). You won't find many older
environments still in use, and with assigning the result of an anonymous
function expression to a property of a function's prototype being the
most common method of specifying a custom object any browser not
implementing anonymous function expressions is not going to be of much
use executing Internet browser scripts.

<snip> var System.someFunc = function(...) { /* syntax allowed
since JavaScript 1.5(!) and JScript ?(do not remeber) */
}
Your version numbers are wrong. JavaScript 1.2 and JScript 3 would be
closer.
My only apprehension is question: can i null'yfi
the function identifier like:

function System() {
/* code */
}

var system = new System();
System = null; /* THIS */

, so System() constructor will not be visible after
THIS statement.
Assigning null to an Identifier will stop that Identifier from referring
to a function, and so being effectively used in a CallExpression.
However, given you want the function to only be callable once it would
be clearer to assign null to the function's Identifier from within the
function (as the last line). I.E.:-

function System() {
/* code */
System = null;
}

var system = new System();

(also see that if i can, there is only one object system,
so no memory leaks will happen in IE revelant to many
execution contexts...).

<snip>

IE's memory leak problem is caused by circular references that include
ActiveX/COM objects (which include IE's DOM nodes) not by closures.
Misidentifying the cause of the memory leaks will leave you avoiding
closures for no good reason and not seeing other circular reference
scenarios and so still having memory leaks.

It doesn't happen often but here I agree with Matt, your reasons for
excluding the function expression are not sound and there use seems
better suited to achieving your apparent goal.

Richard.

[Matt Kruse]

Thomas 'PointedEars' Lahn wrote:

Obviously you do not. Other people do because they care for
_interoperable_ markup, that is, markup that has the potential to
work everywhere and anytime (for the foreseeable future), not markup
that works only in a few versions of a few user agents.
Then you wouldn't use transitional, as the old deprecated markup may not be
supported in the future (unlikely, but possible).

Furthermore, I take your comments as almost humorous, considering the
example you set with your own site.

At least the browser is in standards mode.

Nonsense. Standards Compliance Mode does not require a Strict DTD.

However, to make sure your page isn't using any old markup it's good to have
a strict dtd and validate.
HTML
4.01 Transitional also triggers this mode and allows for the `iframe'
element. Furthermore, HTML 4.01 Strict provides the `object' element
as standards-compliant alternative to `iframe'.

I suppose a fine alternative would be to design in strict mode and validate
everything except the iframe tag. Then if the page has an iframe object,
change it to transitional.

Since the specific example given (my site) puts the doctype in using a
global include file, changing it for just a few pages that have iframes
makes no sense. Just because a document doesn't validate because of 1 tag
doesn't mean a browser isn't going to work correctly. In theory, everything
should validate. In practice, that's not always possible. And perfect
validation doesn't actually offer an value (unless you're working with xhtml
or something) except for the theoretical future case where a browser won't
display anything that doesn't validate - and that will never happen.

Validation is a tool. It is not a goal.

PS: The iframe pages like http://www.javascripttoolbox.com/lib/dragiframe/
show up as validating just fine in Firefox using the Html Validation 0.7.7
extension, which is what I use to validate my pages. I never even noticed
that iframes are not in the strict dtd, as I almost never use them. Checking
the same page using the W3C validator shows some discrepencies in the
results. I'll have to look into that, as I assumed the validator extension
would provide the same results as the W3C validator.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Thomas 'PointedEars' Lahn]

Matt Kruse wrote:

Thomas 'PointedEars' Lahn wrote:

Obviously you do not. Other people do because they care for
_interoperable_ markup, that is, markup that has the potential to
work everywhere and anytime (for the foreseeable future), not markup
that works only in a few versions of a few user agents.
Then you wouldn't use transitional, as the old deprecated markup may not
be supported in the future (unlikely, but possible).

Transitional document types are not going to be deprecated at all. It is
the features they declare that are deprecated in the overall language
concept which is why they are not included in the Strict DTDs; however, as
long as the Web in its current form (based on SGML-based markup languages)
exists, those document types must be supported.

In contrast, the development of user agents has a tendency to have them
become more standards compliant, not less. Therefore it is likely that a
(future) user agent for the Web in its current form will cease to support
elements that are not supported by the declared DOCTYPE of a markup
document and even error if they are encountered anyway. XHTML 1.0 as a
reformulation of HTML 4 in XML 1.0 is a sign of that; once XHTML becomes
the accepted standard document type on the Web (hopefully pushed with the
release of IE7 to support application/xhtml+xml and including an XML parser
to be triggered by XML document types, too), it will become more and more
important and eventually required for Web documents to be Valid.

Furthermore, and to be on topic again, it has been shown already that
scripts operating from within and on invalid markup are inherently
unreliable, which creates an even greater obligation, especially for
a script developers, to create Valid documents (unless they are not
responsible for the underlying markup; then that burden is shifted to
the people who are responsible for that, or to the people who want
their content to be reused).
Furthermore, I take your comments as almost humorous, considering the
example you set with your own site.
When running out of arguments, people tend to such ad hominem attacks.
AFAIK, my Web site (<URL:http://pointedears.de/>) consists of Valid markup
except of the index documents created automatically by the Web server and
the frameset documents (where I have to accomodate user agents that do not
adhere to the standards until I have a better solution).

In case you have any explicit hint as to whether something that looks
_finished_ is not Valid and/or does not work as it should (and a suggestion
to fix that), I am more than happy to read it _where that is appropriate_
and will make any attempt to make it better as soon as I can. Otherwise I
strongly suggest you stop such childish subtle attempts at discrediting
others; it is like you throwing stones in glass houses and will not do
anyone anything good.

At least the browser is in standards mode.

Nonsense. Standards Compliance Mode does not require a Strict DTD.

However, to make sure your page isn't using any old markup it's good to
have a strict dtd and validate.

True, but that is a different thing. Standards compliance is provided with
any recognized DTD and markup adhering to it; Standards Compliance Mode of
browsers does not require a Strict DTD to be triggered. You are wrong and
you do not admit it.

HTML 4.01 Transitional also triggers this mode and allows for the
`iframe' element. Furthermore, HTML 4.01 Strict provides the `object'
element as standards-compliant alternative to `iframe'.

I suppose a fine alternative would be to design in strict mode and
validate everything except the iframe tag. Then if the page has an
iframe object, change it to transitional.

ACK, and I would extend that to any deprecated language feature.
[...]
Validation is a tool. It is not a goal.
Valid documents are an important milestone towards interoperable content.
PS: The iframe pages like http://www.javascripttoolbox.com/lib/dragiframe/
show up as validating just fine in Firefox using the Html Validation 0.7.7
extension, which is what I use to validate my pages.
Obviously this extension is flawed. Try the Web Developer extension which
can use several online validators, or try HTML Tidy which recognizes at
least the DOCTYPE mismatch.
I never even noticed that iframes are not in the strict dtd, as I almost
never use them. Checking the same page using the W3C validator shows some
discrepencies in the results. I'll have to look into that, as I assumed
the validator extension would provide the same results as the W3C
validator.

Start with examining

<URL:http://www.w3.org/TR/html4/loose.dtd>
<URL:http://www.w3.org/TR/html4/strict.dtd>

and searching for "ELEMENT IFRAME" in each resource.
HTH

PointedEars

[Matt Kruse]

Thomas 'PointedEars' Lahn wrote:

PS: The iframe pages like
http://www.javascripttoolbox.com/lib/dragiframe/ show up as
validating just fine in Firefox using the Html Validation 0.7.7
extension, which is what I use to validate my pages.

Obviously this extension is flawed. Try the Web Developer extension
which can use several online validators, or try HTML Tidy which
recognizes at least the DOCTYPE mismatch.

The Html Validator extension is based off tidy.
*shrug*

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[VK]

Matt Kruse wrote:

The Html Validator extension is based off tidy.
*shrug*

You just need to look at the *date* of strict.dtd: 1999
This holy crap did not change for *6 years*

I will not paint the whole historical background of the year 1999
(doubt very much you need my help anyway), just few notes:

In the year 1999 the only browser supporting <iframe> is Internet
Explorer, so it is not an option for W3C to unclude it into standard.
All hopes are related with the <object>.

Year 2006: all more-or-less serious browsers support <iframe>.
<object> idea failed because it appeared to be an endless source of
security exploits.

Side note: some people suggested to use <object> instead of <iframe> to
display pages. Gentlemen, did you actually try it?

The only reasonnable action W3C could make right now is to add <iframe>
into the Strict schema. But they will never do it because it goes
against the fake image W3C builds up: "W3C cannot be wrong". Therefore
they never edit their mistakes, they just silently allow to disregard
them.

I'm sorry if I sound pathetic but DTD at the top of your page is a
*commitment*. It means that you act upon the declared standards even if
it's not convenient or even if forces you to change the whole solution.
If you don't want to go for such troubles then simply do not sign the
commitment.
I never use Strict or even Loose because the rent is too high and
overall it's not my bank :-)
IMHO standard-wise it is more correct and fair rather then declare some
standard schema and break it right away. IMHO

Firefox validator is *forcely* adjusted to the real world, because
Mozilla Foundation doesn't have the W3C's opportunity to spit on the
reality and live in an abstract Ivory Tower. I bet 100:1 for another
difference between W3C validator and Mozilla validator:

<textarea wrap="physical" >Test</textarea>
<textarea wrap="hard">Tes t</textarea>

Try both samples (inside a page of course) in both validator.

[Matt Kruse]

VK wrote:

I'm sorry if I sound pathetic but DTD at the top of your page is a
*commitment*. It means that you act upon the declared standards even
if it's not convenient or even if forces you to change the whole
solution.
Says who? W3C Dogma?
I never use Strict or even Loose because the rent is too high and
overall it's not my bank :-)
Considering IE's box model "problem" (in quotes because its original box
model sizing logic is actually superior to the W3C model, IMO) it makes no
sense to design pages without putting IE into standards mode by using at one
of the standards-mode-triggering DTD's.
IMHO standard-wise it is more correct and fair rather then declare

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[VK]

Matt Kruse wrote:

Considering IE's box model "problem" (in quotes because its original box
model sizing logic is actually superior to the W3C model, IMO) it makes no
sense to design pages without putting IE into standards mode by using at one
of the standards-mode-triggering DTD's.

It is not a wise decision especially if you're making distiributable
libraries. On the real world run most of the time the page will either
don't have DTD declaration at all or it will have URL-less loose
declaration
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
which doesn't switch IE to the W3C mode.

It is much more secure to have two algorithms and check read-only
compatMode property for the needed one:

if (document.compa tMode) { // this is IE
if (document.compa tMode == 'BackCompat') {
// IE in its own mode
}
else {
// compatMode is set to 'CSS1Compat'
// IE will act upon W3C (or at least it will try :-)
}
}

[VK]

VK wrote:

It is much more secure to have two algorithms and check read-only
compatMode property for the needed one:

if (document.compa tMode) { // this is IE
if (document.compa tMode == 'BackCompat') {
// IE in its own mode
}
else {
// compatMode is set to 'CSS1Compat'
// IE will act upon W3C (or at least it will try :-)
}
}

And for debugging purposes you can always use Transitional schema with
URL indication which does switch IE to the W3C mode:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html401/loose.dtd">

(note the proper path for dtd file)

[Thomas 'PointedEars' Lahn]

Matt Kruse wrote:

Thomas 'PointedEars' Lahn wrote:

PS: The iframe pages like
http://www.javascripttoolbox.com/lib/dragiframe/ show up as
validating just fine in Firefox using the Html Validation 0.7.7
extension, which is what I use to validate my pages.

Obviously this extension is flawed. Try the Web Developer extension
which can use several online validators, or try HTML Tidy which
recognizes at least the DOCTYPE mismatch.

The Html Validator extension is based off tidy.
*shrug*

So they are using it wrong or the extension is based on a buggy version of
HTML Tidy.

----------------------------------------------------------------------------
$ cat iframe.html
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>HTML Tidy Test File: iframe</title>
</head>

<body>
<iframe src="/">
</iframe>
</body>
</html>

$ tidy -i --indent-attributes yes iframe.html
Info: Doctype given is "-//W3C//DTD HTML 4.01//EN"
Info: Document content looks like HTML 4.01 Transitional
No warnings or errors were found.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<html>
<head>
<meta name="generator "
content=
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
<meta http-equiv="Content-Type"
content="text/html; charset=us-ascii">

<title>HTML Tidy Test File: iframe</title>
</head>

<body>
<iframe src="/"></iframe>
</body>
</html>

To learn more about HTML Tidy see http://tidy.sourceforge.net
Please send bug reports to ht*******@w3.or g
HTML and CSS specifications are available from http://www.w3.org/
Lobby your company to join W3C, see http://www.w3.org/Consortium
----------------------------------------------------------------------------

PointedEars

[VK]

For hell of it I filed bug report with request to update HTML schema to
HTML 4.02 Strict:

<http://www.w3.org/Bugs/Public/show_bug.cgi?id =2812>

At least they cannot say that they did not know.