It seems that Encytemedia was successful in their "Call for Prototype Documentation" blog posted in the old year.

The site lives at prototypejs.org and should help new and experienced users alike master the popular JavaScript library.

Features

• API of all extended and new objects with examples
• Tips/Tutorials section that includes how prototype works
• Easy method for users to contribute

Good work guys!

Looks like Joe Hewitt has been busy.

Firebug now has it's own site at getfirebug.com. The new site shows the features for Firebug 1.0 which seem like a giant leap in functionality from the current 0.4.1. My favorites look to be the new profiler and the network activity view (shown right).

The catch? According to Hewitt's blog, it might not be free. I know I would pay $15-$25, what about you?

Javascript particle Engine

I was at the No Fluff Just Stuff Software Symposium in Reston, VA this past weekend and had some time in between sessions to work on something. As most of the people I work with know, I rarely code things that might actually be useful to someone in my spare time. So, I had no reason to attempt to rationalize the use for a particle engine in Javascript.

I think I've written a particle engine in almost every language I've used for an extended period of time. This includes python, java, objective-c, and c. What's surprising is that it has taken me this long to write a particle engine in the language I probably spend the most time coding in -- Javascript.

By the way, this is probably the worst particle engine ever created (TM), but it is written in Javascript, so give me a break. It doesn't support colors yet as I couldn't think of an efficient way to change the color of a png. I've only tested it in Firefox and Safari because I'm on a Powerbook. It's also pretty slow, in that it can handle only a dozen or so particles.

Let me know what you think!

features

• Create multiple particle emitters per page
• Emitters have individual configurations
  • Velocity Range
  • Life Decrement Range (opacity)
  • Maximum particles to use
  • Particle re-spawn number
  • Event type to trigger particles
  • Individual X, Y forces applied to particles
  • Size of particles

demo

html configuration

1. import prototype, scriptaculous, and particle.js
2. add emitter class to element
3. add options to configure emitter

download

Here's an interesting bug in Internet Explorer I ran across today:

When using window.location to go to a named anchor inside of an iframe, using a String object versus a string primitive produces different results.

main.html

iframe.html

When main.html is opened in Internet Explorer 6 (try it), the iframe doesn't move to the anchor, instead it refreshes itself with the contents of it's containing html page -- main.html. Huh? If we change set window.location to "#here" instead of instantiating a new String object, it works as expected (try it). What is going on here? Let us try to break down the line in question.

Javascript's string primitives and String Objects

Javascript provides both string primitives and String objects¹. A string object is created by new String(""), whereas a primitive is declared by quotes. The object contains methods like charAt and properties like length and is automatically instantiated anonymously if you write something like: "hello world!".length.

window.location

The location object is special. Isn't it? You can set it to a string, or any of it's properties. Could IE be confused when objects are being passed in? Maybe confusing a string object with a location object?

Anyone have any other ideas?

Of, course, the better way to go to an anchor on the current page is setting the hash property of the location object. Using a string primitive versus a String object both work equally well. Here's an example.

¹Mozilla's page on Strings

the waiting game

No matter what apple says about Java development on the Mac, I always hated the waiting game before I could use some new Java API. First, it was Java 5 Tiger, which because apple ports it themselves to the platform, lagged considerably behind the Sun release. Then, it was Java3D and the JAI API. Even now, the Java3D API on OSX is at 1.3. I'm just glad that the JOGL and Java3d folks found a way to bypass Apple's porting process this time with Java3D 1.5.

Java3D is currently at 1.4.0 stable and has a 1.5 dev version out. The key to all of this is that the 1.5 branch includes the ability to use JOGL to bind the Java3D API to the native OpenGL implementation. What does this provide? Well, since JOGL is already ported to OSX, we can install Java3D 1.5 and JOGL and upgrade our outdated Java3D!

how to do it

Prerequisites

• Java 1.5
• Mac OS 10.4

Procedure

1. Download the windows binary of Java3D 1.5 from the Java 3D site
2. Replace the three jars (j3dcore.jar, j3dutils.jar, vecmath.jar) located in /System/Library/Java/Extensions with the ones in the java3d download. You can back up your old jars to easily revert.
3. Download JOGL (now called Java Bindings for the OpenGL API). They have a PPC and universal download, as it's a JNI library
4. Extract the jogl-natives-macosx-[ppc|universal].jar and copy libjogl.jnilib, libjogl_awt.jnilib, and libjogl_cg.jnilib to /System/Library/Java/Extensions. Make sure to copy jogl.jar here also.
5. Optional: Test out your install by downloading the j3d-examples

Have fun with all the new features!

Posted by jharwig Jun 28 2006, 08:19:45 PM EDT
Permalink Comments [5]

The problem..

If I had been allocated one Firefox extension to use, without hesitation it would be Joe Hewitt's Firebug. But, eventually, I have to test my code in IE (and Safari¹), and need to debug some DOM or css scripting. Many times I would use the url field to execute Javascript in the page using this method...

javascript:function(){ /* some code */ }()

Wrapping the code in a function will prevent variable name collisions. The problem is that this method can get messy and time consuming when trying to inspect elements nested deep within the DOM.

An answer?

I created a bookmarklet that allows you to inspect DOM elements, just like Firebug². Using a bookmarklet allows it to run in any javascript browser, including Firefox. After inspection, a console can be used to modify and query the object. How does it work? The bookmarklet is just a stub that loads the external javascript file³. It adds a click and mouseover handler to the document body object. The mouseover handler adds a window status message with the highlighted DOM tree, and the click attribute opens the inspector.

The inspector has a console with the variable clicked_element pointing to the element. Common attributes like id, class and innerHTML can be edited live. All other attributes can be viewed (or changed using the console) and the computed style is also available.

Download

Save the bookmarklet archive, or try it out on this page. (You can also bookmark this link directly)

Screenshots

• DOM tree
• Editing Attributes
• Console

Todo

• Allow inspecting of active elements - buttons, links
• Improve inspector look
• Editing innerHTML containing ' breaks

³IE 6 has huge limitation in that the url is only parsed to 512 characters. The external javascript is also much easier to maintain.