From Joe: Tony Parisi authored the original AjaX3D examples then published them on ajax3d.org as a great community service. Showing reliable DOM and extension httprequest performance in major html/xhtml host browsers, the set is a great and easily accessible proof that the X3D SAI is up to the job of living in DOM web pages. I think every good X3Der must consider capabiites and preferences of the host. For html/xhtml web browser hosts, so far as these examples are concerned, the good news is that when you scratch just below the surface, everything we need is fine.
I am hooked on using the X3D SAI along with DOM and extension XMLHttpRequest client/server interface, and toward working to standardize usable functionality to be included as a logical extension to the X3D SAI. Who can tell? There may be web applications where presence of an html/xhtml host web browser is not actually required to fulfill the need.
These examples started with me wanting to
"learn from the Master" and "make them my own".
Actual minor recoding commenced when I refused
to use the old html
Sure it probably works to a limited extent in
most web browsers, but is ultimately doomed for
use in the wild - especially when the time finally
comes that browser coders agree
how to handle the html/xhtml
element, attributes, and params.
The fact that I had to make a big deal out of
object element led to Tutorial 0,
cross-browser, standard-chasing code to get
one favorite web3D X3D browser SAI, Flux Player™, going in at least
two different html/xhtml DOM host web browsers.
When I say 'make a big deal out the object tag'
I just mean that i just happen to see the future where
various security and capability measures may just
produce at least a 'de-facto' standard that makes it
simple by not allowing
to interact directly with the containing host DOM,
or its host, for that matter. Several examples are
presently available to show this trend. AjaX3D requires
detailed interaction with the containing DOM.
All X3D 'internal' scripting is available,
but none of the 'external' scripting required by AjaX3D
is available in this vision of the
So I want to avoid this forcasted obsolecence by
having these work using only the
element in a couple of key html/xhtml web browsers.
As the standards-track resolves present web3D X3D browser
differences, it is expected that other web3D X3D browsers
can be used in these simple, basic examples.
More to come, especially showing X3D standard SAI
interfaces, as they become available.
Of course further changes to each of Tony's original
examples are just to make them seem a bit more reliable
or readable for me.
My advice? Go see Tony's original examples at: http://www.ajax3d.org/content.html Tutorials including Tony's fine White Paper: Ajax3D: The Open Platform for Rich 3D Web Applications , then check these out to see what I learned.
One objective of this particular tutorial is to use a specific X3D 'browser' to show interactivity between the scene and the host html document. At this time, this is simply a matter of convenience to this author due to the current stage of X3D development. If you are using IE and you press launch, , IE will attempt to use Flux Player™. In the future, other choices will identify other web3D X3D tools that can use these examples. If you are using Firefox or Opera, scene loading will probably always default to the last X3D player you installed. If you do not have an X3D player installed, then you will be prompted to install Flux.
X3D SAI exchanges data with host HTML DOM and http Server using standards-track interfaces. Like any other active media component, your actual html/xhtml/ecmascript code used to embed and control your scene must consider the host browser capabilities and preferences.
Next step: Tut0. X3D in HTML