Code Samples

[Delta]

Drop Down Menu

Mozilla : work well widowed elements such as drop downs, except for flash
movies
IE : work well so far

http://pwp.netcabo.pt/falmartins/index.htm

[David Dorward]

Delta wrote:

You need a better server setup then if your server dictates that you
abuse tables for layout.

And how do you do a ASP.NET drop-down menu with Web Forms Links that you
can enable/disable ? where some of the menu items should be disabled by
checking users privileges ?

If there isn't a library built it that gives sane output, then I'd find a
third party library or write my own from scratch. Rendering a menu with
some options dependent on the uid isn't exactly a complicated task!

--
David Dorward <http://blog.dorward.me .uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[David Dorward]

Delta wrote:

* Breaks in Opera
* Breaks in Konqueror

don't have all browsers of the world installed on my PC
.... and now you know that it breaks in two fairly major ones (Konqueror is
related to Safari BTW). There's no reason for a web developer not to have
Opera installed for testing, its available on most major platforms.
* Abuses tables for layout just because I want it full compatible with VB.NET/ASP.NET
If .NET enforces awful markup (which I doubt), then it isn't suitable for
generating said markup and you should use it. (Again, I doubt that .NET
does enforce this).
* Appears to be immune to keyboard control.

My mouse does everything

Its faster not to take my hands off the keyboard.

Some people suffer from RSI and find a keyboard better then a mouse

Some people are physically incapable of using a pointing device, but can use
a linear navigation device (like the tab key).
for beginners should be helpful, not for experts

I disagree, an expert is more likely to be able to fix the problems with it
then a beginner.

--
David Dorward <http://blog.dorward.me .uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Dr Clue]

Richard Cornford wrote:

Dr Clue wrote:

Richard Cornford wrote:

It doesn't cope that well if/when the user increases the
font size.

<snip>It's almost too much to do so on a single load , much less a
multiple size change in a single session.

<snip> I have seen enough menus that do take account of the user
configurability of web browsers to be fairly sure it can be done (at
least on modern dynamic visual browsers, and viable clean degradation
provided for the others). It might be worth going into the perceived
issues that make you think it difficult.

Sure , I don't mind at all discussing the challenges, as
while I know a great deal ,there is always more to discover.

The basic problem is that the menu system is designed to work without
knowing in advance what it's working with, and to be reasonably
tolerant of third party content while allowing same to be possibly less
than valid.

Since different browsers rendering the same random content will tend
to produce variably sized results, the menu system renders and measures
at page load. Needless to say this does present some overhead, which
at load time just sqeaks in to the realm of acceptable delay.
To do so post load tends to make for a rather obvious thunk.

My current task is to finish the part that allows the javascript code
to read stylesheets in Opera, which as you are probably aware
is less than straight forward. (but doable).

Again keep in mind that the design requires that the menu system
have no for knowledge of the content and that it be tolerent of same
being far less than valid.

--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML/CSS,Javascript, TCP ...
--`

[Richard Cornford]

Dr Clue wrote:

Richard Cornford wrote:

Dr Clue wrote: <snip>

It's almost too much to do so on a single load , much
less a multiple size change in a single session.

<snip> ... . It might be worth going into the perceived
issues that make you think it difficult.
Sure , I don't mind at all discussing the challenges,
as while I know a great deal ,there is always more
to discover.

The basic problem is that the menu system is designed to
work without knowing in advance what it's working with,
and to be reasonably tolerant of third party content while
allowing same to be possibly less than valid.

Since different browsers rendering the same random content will
tend to produce variably sized results, the menu system renders
and measures at page load. Needless to say this does present
some overhead, which at load time just sqeaks in to the realm
of acceptable delay.
To do so post load tends to make for a rather obvious thunk.

Of course every real application of browser scripting has a specific
context and so does not need to be truly general. So, given that no
script needs to be truly general, when the act of trying to be general
starts to get in the way of viable performance that might flag the need
for a design re-think.

But it is not necessarily the attempt to be general that results in your
code running like cold treacle, more the strategy taken in achieving
that generality. You have chosen a style of "meta" scripting, where you
are continually constructing strings of javascript source code (mostly
dot-notation property accessors) and then using - eval - to execute
them. Eval use introduces considerable overheads, varying in its impact
by as much as a factor of 20, depending on the execution environment.
The same applies to string concatenation, which is an area where some
common implementations perform particularly badly.

This "meta" style is entirely avoidable, and a more normal strategy of
coping whit attempting to interact with multiple documents in a frameset
through switching object references would certainly perform considerably
better (and be easier to understand), though only a small proportion of
applications actually use a frameset.

However, the entire design stile is not entirely responsible for the
sluggish performance. Much of the actual code is significantly
sup-optimal. Taking a random function as an example:-

| function DCcssApply(pL,s zClass,oD)
| {
| oL=DCok(pL)
| if(typeof oD=='undefined' )oD=DCgetParent Window(pL).docu ment;
| var oCSS =DCgetCSSclass( oD,szClass)
| szSkipTypes = ":function:unde fined:"
| szSkipped = ""
| var oV;
| for(i in oCSS)
| {
| if(String("0123 456789").indexO f(i.substring(0 ,1))>-1)continue;
| oV=eval("oCSS." +i);
| oT=typeof oV;//eval("oCSS."+i) ;
| if(szSkipTypes. indexOf(oT) > 0)continue;
| if(oDC.szCopy.i ndexOf(":"+i+": ") == -1)
| {
| szSkipped+=i+"\ n"; continue;
| }
| if(oV.indexOf(" url(")>-1)
| {
| oV=oV.split("'" ).join("").spli t("(").join("(' ")
| .split(")").joi n("')")
| }
| szE='oL.style.' +i+'=oV'
|
| try { eval(szE)
| }catch(e)
| { DCdebug("Sucks "+szE) }
| }// End For{}
| }

The - oL - variable appears to have some role as a global variable but -
szSkipTypes - and - szSkipped - do not appear to be referenced by any
other code, and the - i - used in the for loop looks like it really is a
bad choice for a global variable. The scope chain resolution of
Identifiers will take longer the further down the scope chain an object
is found with the corresponding property name. The Variable/Activation
object, with property names corresponding with the local variables, is
at the top of the scope chain, while the global object, which property
names corresponding with the global variables, is always the last item
on the scope chain. So, apart form the questionable wisdom of allowing
variables that appear to only be useful within a single function leak
out into the global scope, using local variables in their place will
result in better performance.

The line:-

if(typeof oD=='undefined' )oD=DCgetParent Window(pL).docu ment;

would execute faster as:-

if(oD)oD=DCgetP arentWindow(pL) .document;

- because it avoids the typeof and comparisons operations, and it is
safer because some non-undefined values would be just as erroneous as an
undefined argument.

if(String("0123 456789").indexO f(i.substring(0 ,1))>-1)continue;

- includes String("0123456 789"), where the string "0123456789 " is
unambiguously a string primitive, making the call to the - String -
function to type-convert its argument into a string primitive is
redundant, and so pure overhead. The whole statement would probably be
faster if replaced with a regular expression test to see whether the
fist character in - i - is a decimal digit.

oV=eval("oCSS." +i);

- is just plain silly as - oCSS - is a local variable that refers to a
CSS rule's - style - property and - i - is one of its property names (as
acquired with for-in). The - eval - call is unnecessary to resolve the
value referred to by the property name - i -, instead a bracket notation
property accessor should be used, i.e:- oV = oCSS[ i ];

oT=typeof oV;//eval("oCSS."+i) ;
if(szSkipTypes. indexOf(oT) > 0)continue;

- are a couple of odd statements. The global string - szSkipTypes -
could just as easily be a globally declared object such as:- szSkipTypes
= {'fucntion':tru e,'undefined':t rue); -, allowing:-

if(szSkipTypes[(typeof oV)]){
continue;
}

But given the - oV - is a property of a - style - object, and may be a
method of that object, the key 'object' should probably be added to that
set as some hosts report 'object' as the result of a - typeof - test
applied to a method of a host object. It is also questionable whether
any type other than 'string' should be allowed past this test as the
value will be subject to the - indexOf - method, with which boolean and
numeric values would error-out, though excluding numbers would suffer
from excluding zIndex.

Note, however that:- szSkipTypes = ":function:unde fined:" - means that
the - indexOf - method will have to examine and skip the colon character
at the start of the string, and the second colon if its argument happens
to be "undefined" . There is no reason to have any of the colons in that
string.

The following:-

if(oDC.szCopy.i ndexOf(":"+i+": ") == -1)
{
szSkipped+=i+"\ n"; continue;
}

- would also benefit form indexing an object reference, avoiding the
need for the two concatenation operations and the comparison, and almost
certainly resolving faster. The following - szSkipped+=i+"\ n"; - seems a
bit pointless as there do not appear to be any other references to the
global szSkipped variable, or much point in recording the enumerated
methods and properties with undefined values every time the function is
executed.

if(oV.indexOf(" url(")>-1)

- will, as I have said, error-out in the event that - oV - is numeric,
as it may be for the -zIndex - property of a style object. There is also
an implicit assumption that enumerated properties of a style object will
never include object references, null values and boolean values, making
this code risky to expose to any browsers outside of a limited known set
(so not even attempting to be cross-browser).

oV=oV.split("'" ).join("").spli t("(").join("(' ")
.split(")").joi n("')")

- assumes - oV - is a string, creates an Array, turns it into a string,
creates another Array, turns that into a string, creates a third Array,
and turns that into a string. The whole process could probably be
replaced with a single String.prototyp e.replace call, and be
considerably faster in doing so.

In:-

szE='oL.style.' +i+'=oV'

try { eval(szE)

- oL - has not been verified as an object reference with a 'style'
property that refers to an object, but assuming it is , the eval call
can again be replaced with a much more efficient bracket notation
property accessor:-

try{
o.style[ i ] = oV;

It is also a little perverse to find:-

oDC.NS =(document.laye rs )?true:false

- and code that then branches based on the value of - oDC.NS -,
suggesting an attempt (if flawed) to accommodate Netscape 4, when
Netscape 4 will generate a syntax-error when it encounters the try-catch
in the source code, and so never even attempt to execute the script.

While all of these small changes are mostly only going to make a tiny
contribution to the performance of the script, the fact that a small
optimisation is available for nearly every line of code used would add
up. But in the end getting rid of the "meta" scripting, and all of the
consequent - eval - uses, would make a bigger contribution to solving
the performance problem. Abandoning the generalised monolithic library
concept in favour of targeting code re-use at a lower, more single task
specific, level would allow efficient tailoring to the context of
application and so largely avoid the overheads involved in using general
code in a specific context.
My current task is to finish the part that allows the
javascript code to read stylesheets in Opera,
Then which, Konqueror, Safari, IceBrowser, NetFront?
which as you are probably aware is
less than straight forward. (but doable).
I don't understand why you are doing this at all as it appears to
pre-suppose that all styles are applied with classes (rather than with
ID and elements selectors or context related and mixed selectors), but
it is unclear why an assignment to an element's - className - property
would not equally satisfy the requirement and considerably less effort
and trouble.
Again keep in mind that the design requires that the
menu system have no for knowledge of the content and
that it be tolerent of same being far less than valid.

While in the context in which you use the script you have total control
over the contents of the menu, as would anyone else using it.

Richard.

[Dr Clue]

Richard Cornford wrote:

While in the context in which you use the script you have total control
over the contents of the menu, as would anyone else using it.

Your assuming again :)

Well Richard , that was an incredibly long response to read,
so I'll save some bandwidth by saying that anyone who wants to read it
should fix a pot of coffee and hit their version of
the [prev message] button.

As to eval(). Most of the use of same is for browser object patching
which only occurs once in the lifespan of most objects. As a benefit
the library ditches all those "if browserA else if BrowserB else...."
constructs that get executed over and over and bulk up code.

One should also look closer at the execution paths as relates to
pL (Parameter ) could be either szL or oL
szL (String meta) most often passed in to become a patched oL
oL (object ) The most common object passed

Typically the goal is to rise from the meta szL to a patched oL
and then to simply use the oL. This means an oL has a style, and if
it is an oL it has been verified.

As to frames being rare, I tend to differ with you. Most of my
appplications work great in frames be they my frames or someone
framing my application remotely like the examples at guru.com and other
places that frame my apps. There are still plenty of pre-XMLHTTP
browsers that need a hidden frame to do thin-client and an iframe
won't do.

As to regex , this and several of your other suggestions
would decrease the number of supported browsers. Remember, not everyone
is in a position to keep the browser they surf on up to date,
and believe it or not some folks are installing older browsers
intentionally

As to some of my odd syntax choices, it comes from the quirky nature
of browser versions over time. array['foo'] dont always work
nor do a lot of your alternatives.

I'm always reluctant to kill off a browser without a good reason
annd in this descussion we have not raised such a "good reason".

Anyway there are some ribs calling me. Thanks for the extensive reading
material , I feel much more secure in my position as a result.
--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML/CSS,Javascript, TCP ...
--`

[Delta]

"David Dorward" <do*****@yahoo. com> wrote in message
news:df******** ***********@new s.demon.co.uk.. .

If there isn't a library built it that gives sane output, then I'd find a
third party library or write my own from scratch. Rendering a menu with
some options dependent on the uid isn't exactly a complicated task!

Do you know that almost every good looking professional menus, like this one
:

http://www.sothink.com/webtools/dhtmlmenu/

has a very peculiar feature :

Auto hide window elements, including Flash, Selected box, IFRAME, and etc.

Did you saw that my sample doesn't have that problem ?

so it isn't that so bad and useless for people, and a uid full intregated
with menus isn't exactly a simple task

[Richard Cornford]

Dr Clue wrote:

Richard Cornford wrote:

While in the context in which you use the script you
have total control over the contents of the menu, as
would anyone else using it.
Your assuming again :)

Yes, I am assuming that people are at least capable of exercising some
control over what they do. Obviously you are better informed as to
whether that assumption applies to you.
Well Richard , that was an incredibly long response to read,
And still hardly scratched the surface.

<snip> As to eval(). Most of the use of same is for browser
object patching which only occurs once in the lifespan
of most objects.
That is hardly a justification for using - eval -.
As a benefit the library ditches all those "if browserA
else if BrowserB else...." constructs that get executed
over and over and bulk up code.
If you only perceive two alternatives heading off down the Goodmanesque
blind-ally may seem like a good idea, but javascript is so flexible and
dynamic in nature that many alternatives exist.
One should also look closer at the execution paths as
relates to
Is this "one" intended to be me? It is in the nature of "meta" scripting
that the results are intrinsically hard to follow, as there are two
levels of simultaneous scripting to be followed. This makes the results
difficult to understand, difficult to maintain and difficult to modify
(with very little return for all of that extra effort). Having observed
serious structural and logical flaws on nearly every line of code there
is little point going into the script in any greater depth than I
already have.
pL (Parameter ) could be either szL or oL
szL (String meta) most often passed in to become a patched oL
oL (object ) The most common object passed

Typically the goal is to rise from the meta szL to a
patched oL and then to simply use the oL. This means an
oL has a style, and if it is an oL it has been verified.
No it hasn't been verified. The - oL - value is provided by a call to a
function called - DCok - which has two - return null - statements and a
statement that returns the function's argument when that argument
type-converts to false.

Unless you are saying that those lines of code in the - DCok - function
are never executed, and so utterly redundant, and raising the question
of why they have been included in the function, then the returned value
may be of any type.

And no host objects have - style - properties in the older scriptable
browsers (e.g. Netscape <= 4).
As to frames being rare, I tend to differ with you.
The vast majority of current web sites do not use frames, and HTML
authoring advice tends to favour avoiding the use of frames (while the
strict versions of HTML 4+ and XHTML 1+ have eliminated the FRAME,
FRAMESET and IFRAME elements).

<snip> ... . There are still plenty of pre-XMLHTTP browsers
that need a hidden frame to do thin-client and an iframe
won't do.
If you are using a hidden frame for background loading data you are not
also using it for showing DHTML.
As to regex , this and several of your other suggestions
would decrease the number of supported browsers.
Unlikely as your try-catch use has already eliminate version 4 era
browsers and earlier and all browsers implementing ECMA 262 2nd edition
and earlier.

Once you are up to version 5+ browsers and ECMA 262 3rd edition
implementations regular expression support is standardised and
consistent enough for the required tasks.
Remember, not everyone is in a position to keep the
browser they surf on up to date, and believe it
or not some folks are installing older browsers
intentionally
There always comes a point where an ancient browser becomes non-viable
for use on the Internet, regardless of the efforts of those who can to
provide the maximum support possible. These days the version 4 era
browsers are about the oldest that are still usable, and new commercial
projects do not tend to demand additional effort to be put into their
active support.

But if you write code that requires Jscript 5+, JavaScript 1.4+ or an
ECMA 262 3rd edition implementation it is hypocritical to try to lecture
others on supporting 'older' browsers.
As to some of my odd syntax choices, it comes from the
quirky nature of browser versions over time.
Don't expect anyone to take that seriously without specific examples
(and for reason's sake examples that are demonstrable on browsers that
support try-catch)
array['foo'] dont always work
Bracket notation property accessors are a fundamental language feature
and do work on all objects. If you have problems with the alternatives
state what they are.
nor do a lot of your alternatives.
Hearsay reports of unspecified issues in unnamed environments are not of
much use to anyone (and I don't believe you. Though I will believe that
you have perceived problems where none exist, trying "meta" scripting
produces that sort of impression).
I'm always reluctant to kill off a browser without
a good reason annd in this descussion we have not
raised such a "good reason".
Yes, in the DHTML library there is no apparent reason for the use of
try-catch, except that the chaotic nature of "meta" scripting means that
defensive coding is unusually difficult. So having the code syntax-error
and fail to execute at all on older browsers seems unnecessary (at least
on the ones still in use).
... . Thanks for the extensive reading material ,
I feel much more secure in my position as a result.

Which means that when I point out specific technical problems with
nearly every line of code in just one of your functions you just dismiss
them all out of hand. Of course you have no real defence, as is evident
in your not making any specific responses to my points, but instead
resorting to hypocritical appeals to support for 'older' browsers and
vague, unsubstantiated claims of inconsistent language implementations .

That is taking self-confidence to the point of blind arrogance. I wonder
how long it will take you to see the light, or whether you ever will.

Just to make my opinion completely clear; of the DHTML libraries that I
have seen (which is quite a few but not every one ever offered for
consideration by its author on this group) yours is easily the worst
implemented to date. Your apparent pride in it speaks of your lack of
experience in javascript authoring.

Richard.

[Dr Clue]

Richard Cornford wrote:
<snip>

Just to make my opinion completely clear; of the DHTML libraries that I
have seen (which is quite a few but not every one ever offered for
consideration by its author on this group) yours is easily the worst
implemented to date. Your apparent pride in it speaks of your lack of
experience in javascript authoring.

Thankyou for your opinion.

I'm sure it's backed by a wonderful libray that
you wrote which you are now going to shows us
so that we might learn from your example right ?

There always new things to discover :)

--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML/CSS,Javascript, TCP ...
--`

[Richard Cornford]

Dr Clue wrote:

Richard Cornford wrote:
<snip>

Just to make my opinion completely clear; of the DHTML
libraries that I have seen (which is quite a few but not
every one ever offered for consideration by its author on
this group) yours is easily the worst implemented to date.
Your apparent pride in it speaks of your lack of experience
in javascript authoring.
Thankyou for your opinion.

I'm sure it's backed by a wonderful libray that
you wrote which you are now going to shows us
so that we might learn from your example right ?

And of course if I have never written a 'wonderful library' my opinions
on javascript authoring must necessarily be invalid. Though if you
re-read my comments in the earlier post you will find me questioning the
conceptual appropriateness of monolithic general script libraries to web
browser scripting. And given that belief on my part it would be
unreasonable to expect me to have written one (or if I had, in ignorance
and naivety in the distant past, to be interested in bringing that code
to anyone's attention).

It is an awareness of the dubious worth of such libraries that
encourages me to not bother examining every single example presented to
the group for consideration.
There always new things to discover :)

Yes, and searching the archives at google groups can often be a good
rout to discovery.

Richard.

[Dr Clue]

Dear Richard , I have indeed read your responses.
I once again thank you for your opinion(s).

Good day.

--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML/CSS,Javascript, TCP ...
--`