[DHTML] Swiss Army Interactive Image slide show

[jscheuer1]

Quite a bit to respond to here, Twey. I think that for the most part I've already stated my view so will leave it at that and agree to disagree. One thing about the code that you may have missed as regards the parameters and setters is that all parameters are also properties of both the array and the instance of the function object. As properties of the array, they can easily be set just after declaring the array. I see this as the preferred method but, for folks who need a very basic implementation, they can use what I like to think of as the 'command line', the call in the body.

Incidentally, I've also included the ability to override some key properties for individual array items. None of this must concern the casual user but, comes in handy when customizing the script in an advanced manner.

There is a hierarchy of precedence for any given parameter/property. The array must be specified. If nothing else is specified, the defaults are used. If something is defined in the call, it overrides the default value. If something is set as a property of the array, it overrides the corresponding parameter (if any and if set) as well as the default value. Finally, if something is set for an individual array item, it overrides all other similar settings made at any of the previous levels but, only for that item.

The only other thing I want to add to the discussion at this point is about indenting code. The reason that I find it confusing is that different folks indent differently. Later edits to code not done by the original author or done when the original author is in a different mood may indent differently than the rest of the code.

I do like to follow some conventions in coding to keep it clearer than it might otherwise be but, have been increasingly abandoning even some of these for shortcut/shorthand methods. I do like, for the most part:

function(){
body of function
}

with a blank line between functions. I do not like curly brackets where none are needed, drives me up a wall for some reason. When I see an opening curly bracket, I think, "This is a condition that requires more than one instruction to respond to or, it is a function or collection of some sort." When these brackets are used unnecessarily, it slows down my reading of the code.

I think this stems from an old ambition of mine to be able read and write machine code - something I probably will never realize. However, with such a relatively simple language as javascript, I don't want to be slowed down by what I see as extra punctuation, indentation or spaces.

When I see something indented, I think, "What is that doing way over there? It belongs here with the code that it is associated with." Same thing with style. Much too much indenting is used with that at times. What could be clearer than:

selector {
property:value;
}

?

Gets down off of his soapbox.

[Twey]

I do not like curly brackets where none are needed, drives me up a wall for some reason. When I see an opening curly bracket, I think, "This is a condition that requires more than one instruction to respond to or, it is a function or collection of some sort." When these brackets are used unnecessarily, it slows down my reading of the code.

Agreed.

I think this stems from an old ambition of mine to be able read and write machine code

x86? An assembly language is a lot easier to read and can accomplish the same goals, honest

However, with such a relatively simple language as javascript

Au contraire. Any language based on the hardware (be it a mnemonic language or raw opcodes) will be intrinsically very simple. Keeping track of the logic behind it can be harder, though.

I don't want to be slowed down by what I see as extra punctuation, indentation or spaces.

But when extra information can be garnered from the level of indentation, doesn't it make sense? If I see:

}
}

... I have to scroll up through the code, looking at the end of each line, keeping count of how many braces are open for each statement, in order to find what the second brace actually contains. However, in a consistently indented script, no matter what the style, I can look at:

  }
}

and see that the latter brace has no further levels of nesting, and that everything outside it is in the global scope. I can even find out where it began much more easily, by simply scrolling up and looking for a line that starts in the same column.

[jscheuer1]

If I see:

}
}

... I have to scroll up through the code, looking at the end of each line, keeping count . . . in a consistently indented script, no matter what the style, I can look at:

  }
}

and see that the latter brace has no further levels of nesting

Emphasis added. Ah, and therein lies the rub. Each and every level of nesting must be consistently indented and very often aren't. Even if it is consistent, that's precious little information. This same sort of information can be yielded by a blank line after all currently relevant open braces are closed. It might be properly indented but, have a different logic than you think without really looking at the rest of the code. Where's the opener for the nested brace? It really should be here (at least relative to the margin):

{
   {
   }
}

But, often it is at the end of a line of other code that sets the condition or opens the function.

A syntax sensitive editor makes child's play of ferreting out these 'back-traces' in either situation but, with all code indented to the same 0 width left margin, it just looks neater and is easier to follow for me. There is a much greater chance that all lines will be visible even in a narrow editor window without wrapping and the flow of the code seems more fluid without all that indenting. This also relates to my distaste for needless curly brackets. When you combine that with indented nesting, you get needless indentations, which just compounds the problem.

For me it may be a matter of trust. I don't trust anyone to write their code in a manner that will be easier for me to read than is yielded by one instruction/test per line and, many coders don't even keep it that simple. If I see nesting indents I think, "This may be an indication of the flow of the code or, it may not be."

As I said at the outset, to each their own - it is a matter of personal preference. Mine is tending toward even more 'obscure' code, for example - I now prefer:

iss[this.issid=iss.length]=this;

to:

iss[iss.length]=this;
this.issid=iss.length-1;

But, there was a time when I would have viewed the former as too obscure.

[Twey]

Each and every level of nesting must be consistently indented and very often aren't.

If you've written it, you can be reasonably sure that they will be

This also relates to my distaste for needless curly brackets. When you combine that with indented nesting, you get needless indentations, which just compounds the problem.

There are two styles for this too: same line

if(condition) statement;

and indented:

if(condition)
  statement;

I prefer the former, which seems to read more logically (as we do indeed say in English, "if condition statement") but there is the problem of longer lines, which the latter solves.

But, often it is at the end of a line of other code that sets the condition or opens the function.

Yes, there are two styles, sometimes called Java-like and C-like, after the languages in which they are/were predominant. Java-like block statements look like:

keyword {
  code;
}

... whereas C-like block statements look like:

keyword
{
  code;
}

Personally, I favour the former for sheer brevity. With either style, all one must do to locate a matching brace is look up or down the column until one hits some code.

Mine is tending toward even more 'obscure' code, for example - I now prefer:

iss[this.issid=iss.length]=this;

to:

iss[iss.length]=this; this.issid=iss.length-1;

Ah, yes. I must try to keep this tendency in check: I have a habit of cramming as much into one statement as I can, which is all very fine and good, but especially in Python, I find myself compressing

def containsGreaterThanFive(mylist):
  for x in mylist:
    if x > 4:
      print "yes"
      return
    print "no"

into

def containsGreaterThanFive(mylist):
  print (len([x for x in mylist if x > 4]) > 0 and "yes" or "no")

There were worse examples (one particular statement took up five lines in my editor) but none I can recall from memory.

[ddadmin]

One advantage of using document.write() I find is that you don't have to wait for the entire document to have loaded before you can invoke and start working with the output. Going through the DOM (ie: appendChild()) requires that extra step of checking and waiting for the body onload event before proceeding.

Regarding indenting, firstly, I'm sure everyone knows I belong to the same camp as John's I haven't indented mainly due to laziness, and that when I do, I find it quite time consuming keeping track of all the various levels of containerships, plus the extra bytes it adds to the script. Lately I have began making an effort to be considerate to people who may study the source, by commenting and using blank lines to separate various methods of, say, a custom object. I may start indenting next, you never know.

Back to the original topic, I don't have access to a Mac unfortunately, so can't test the script out in that platform. But whenever you think it's ready John, I can put it up.

Thanks,

[jscheuer1]

I will update for Safari if I can get a reliable test in that browser and there are any correctable issues. I've updated the properties post and the demo and have added another demo. The script is now external:

http://home.comcast.net/~jscheuer1/side/files/sai_ss.js

The two demos are now:

http://home.comcast.net/~jscheuer1/s...opcity_hvr.htm

and:

http://home.comcast.net/~jscheuer1/s...es/iss_ext.htm

As far as I am concerned, you can put it up.

[djr33]

I say indendation is crucial for long scripts, but fine if not present for short bits.
Certainly it's nice, as twey said, to be able to see the root level by having at least the overall brackets at the right spot, with everything else indented a bit.

[jscheuer1]

Well, I know I said this was ready, and it was. However I just added some capabilities. Just one for the array properties and I've updated that post to reflect the addition (border_style). I've also added a way to override for individual images the background color, and a way for individual images to have no border, even if one is set for images using the array properties.

I did this because I was playing with the script and the second demo, comparing it to the way these images are displayed on the site that has given permission for their inclusion in the demo. Then I got a little creative as well. There is very little added code to the script itself and these overrides can remain undocumented for simplicity's sake on the demo page.

[jscheuer1]

News Flash!! A major minor bug has surfaced in dial-up simulations. The text can get ahead of the images in certain cases. I think the fix will be to populate the text along with the images into the rotating canvasses but, need to work out the details.

Please hold off posting the script to the DD library until I can get this ironed out.

[djr33]

You could already have had a look at it in that browser and the others, if you were so inclined.

I've been away and just had my laptop (windows) available.

Now that I'm back to my mac, here ya go:

Safari seems just fine. No problems I can see. Tested all examples on all pages (quickly, but, I think, thoroughly).
Anything particular I should look for?

Firefox (mac) is fine. No surprise there.

IE 5 mac has big issues. The controls for the most part work. Hitting the stop or next buttons does the right behaviour for the buttons, such as enabling/disabling buttons. However, that's just about it. The images do NOT appear, the image numbers do not appear or change on clicking, the background doesn't change on the second example, and, basically, I just get a large blank white area. What's particularly interesting, though, is that the image number doesn't even show up. That might imply that there's something incompatible with the overall code to set/change the image, rather than displaying the image itself.

No big surprise with IE5mac, either, since it always has javascript issues.
But... if you could get that working, probably a good idea, since it's the secondary browser (comes installed) with OSX (and some use it due to familiarity and don't use safari 'cause it looks different), and it's the primary browser with OS9- (though I am testing on OSX at the moment, but I will say that I'd assume the javascript parser is the same, since it's the same version and such, though I can't comment. If anything, OSX would be improved, since it is newer).
(I also remember that back in the days of OS9 I had netscape, but I think that was installed with some program, for the help files, I believe, and didn't come with the system. But that's probably irrelevant, since I can't test anyway. However, would be nice if I could test, since I'm curious if it's just as bad as IE5.)