Web Application Development

I’m going to follow up on my first blog, At Look At Spatial Labs, writing about the technology behind the web site, specifically how the AJAX design pattern was used to create a dynamic, 3D graphical viewport.

We knew when we first created the Spatial Labs site we wanted the graphics viewport to act and look like it would in a typical desktop application; not just in presentation (for example, a sophisticated coloring model, shadows, gridlines, view, pan, rotate, etc) but in its behavior upon user interaction with the model. We wanted to be able to select faces and edges on the model, perform modeling operations and update the viewport as smoothly and “flicker free” as possible. This, of course, meant that we needed to build an interactive (dynamic) web site as opposed to a simple site of static html pages. In the next blog I’ll discuss the array of options for the 3D graphics themselves but for now I would like to limit the discussion to the later, how can one make a graphics based website dynamic? - as if you are running a typical desktop application.

There is nothing new or Earth shocking here, dynamic web sites showed up years ago largely due to a concept called AJAX. Although this is not a blog about general web application development, a little introduction is needed (as AJAX is the key); and in order to save you from chasing the link, I’m going to shamelessly copy the first paragraph in Wikipedia which introduces AJAX.

Ajax (pronounced /ˈeɪdʒæks/; shorthand for Asynchronous JavaScript and XML) [1] is a group of interrelated web development methods used on the client-side to create interactive web applications. With Ajax, web applications can retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing page. Data is usually retrieved using the XMLHttpRequest object. Despite the name, the use of XML is not needed, and the requests need not be asynchronous. [2]

(I love Wikipedia. Cuts right to the chase. I own multiple AJAX books, not one has that clean and clear of an introduction.)

Along with the introduction from Wikipedia a little more detail is needed; the “presentation” (text, images, etc) of a typical website is provided to you by what’s called the browser’s DOM. (You’ll have to chase this link, if you want). Think of it as “a tree structure of HTML and a JavaScript interface in order to manipulate it”. AJAX works by having the browser contact the server asynchronously and the server returning information back (maybe little “updated” pieces of HTML). The browser, through the use of JavaScript, updates the DOM with this information. As the DOM is a tree structure, the browser might hack off a limb and replace it with this new bit of HTML just returned from the server. This updates the “presentation” in a dynamic way; one did not go back and reload the entire DOM when only a small part changed.

OK, anybody spending any time on the net should recognize AJAX at work all over the place. (Think of all those blue rotating circles in the middle of pages.) You’re hard-pressed these days to find a website that does not have some AJAX in it.

Enough with the basics of AJAX, how does this contribute to a dynamic (flicker-free) graphics based web-site? The key observation here is that the DOM is a tree structure that can be updated by the browser via JavaScript. Well, the scene graph of the viewport is a tree structure as well. Instead of text, button controls and images (as for HTML) - it’s a tree of polygons, polylines, color nodes, etc. And if one has JavaScript access one should be able to update the graphics in the exact same matter as the HTML DOM. Again, in a latter blog, I’ll get into the array of technologies available in order to mechanically place the 3D graphics in the browser; but now we are starting to get an idea of some of the prerequistes.  (There are many technologies for this, but I will tell you now, the more comprehensive and powerful the scene graph and JavaScript interface, the better). I have to give credit to the paper AJAX3D - The Open Platform For Rich 3D Web Applications by Toni Parsi. He observed it. We read it and put a Solid Modeler behind it.

As with all high level concepts; upon implementation come the details. Ohhh, the details. One has to be careful with AJAX. You can overuse it and make your site more annoying than worthwhile. You don’t have control over everybody’s network speed and people using your site will be anywhere in the broad spectrum of performance. We had to figure out when we really needed to go the server and when we didn’t. We knew that less would probably be safer and better. Of course, in our case, the 3D modeler is on the server (not in the browser) so when one fillets an edge (as in one of the examples in Spatial Labs) we have to go to the server for that. But what about other areas of interaction; rotation, pan zoom, picking etc? In our implementation these are on the client side, including picking. But in Solid Modeling apps, nothing is trivial. What if one wanted to select a FACE and get all the EDGEs belonging to that FACE? We could go back to the server and get this information … or what if we made the scene graph more intelligent and embedded this kind of information in it? Then it would all be client side and, well, one less blue rotating circle.

In the end we went through many iterations on this subject and are still refining as we go; basically adding more and more intelligence (in a very compact way) to our scene graph. We found it really key to understand what information is best on the client and what should be on the server. In the end, I don’t think the refinement will ever stop. It’s become one of the more intriguing problems of our design.

In the next blog I’ll discuss the array of technologies one can use to display the graphics in the browser and how we converged onto one solution but are keeping the doors open for others. I added an AVI so you can get a feel of the performance. 

From: MARKSON Howie
To: KENNY Stefanie; OETTING Gregg; ALPINE John; SLOAN John; TATTERSON Kevin
Subject: RE: Let's Start a Blog

Seems like we all have enough ideas to write an interesting blog. I have a great idea what our first post should be. Let's get started! 

From: ALPINE John
A great idea, we have no shortage of opinions and RSD’s (Really Smart Developers).  One of the more unique things about our business is that our end users are also developers.  So I would imagine we have something to talk about here. 

As we just announced CGM, why not have Gregg start out and talk about what’s different in CGM than ACIS from a technical standpoint? 

From: SLOAN John
Um - guys?  I thought I was the one who got the Really Opinionated Developer title.  Especially about Object Oriented Design and Architecture issues.  And about Typing Titles With Lots of Caps and How German Classes Ruined My Capitalization Ability. Is John A in? 

From: TATTERSON Kevin
Turns out we’ve all got opinions ;)

I’m sure I could come up with stuff.  I don’t know much about blogging, but from what I can tell, a blog entry doesn’t necessarily have to bring closure – it just has to put an opinion on a subject to get people thinking.  And it can’t take more than a couple minutes to read – the best ones are relatively short.

I’d put something crazy out there like “people or process – which matters most?”  Stir the conventional wisdom pot a bit. What does John think? 

From: OETTING Gregg
I’m doing the first one!? How about whoever is that last person to reply does the first blog. That’s the way I manage; by fear. Kind of like the kid’s story about the ducks getting back on some boat and the last one gets a whack on his butt. Actually, I spend a lot of time thinking about motivating developers; ownership, recognition, connecting them with customers, innovation and good old fashion fear. But I’m not sure that would make a good blog topic, especially with how this all interconnected during our integration with AGILE and Scrum.

I’ll bet Kevin has an opinion on this Blog. He has an opinion on everything. 

From: KENNY Stefanie
I don’t know about your addressing me as an RSD, but I’ll offer my opinion anyway.  Perhaps I should be a called a Really Opinionated Developer instead. 

Anyway, I like this idea.  From me personally, I’d like to discuss Interoperability and some of the difficulties surrounding it.  I’d also like to draw on my QA background to talk about testing and how modern ideas on testing from other domains, like web application development, can be applied to CAD and 3D.  We could even go further with this idea and discuss a range of software practices and tools and how they apply to the engineering software domain, for instance, what have been some of our successes (and failures) in applying Agile processes.

What are you thinking for the first entry?  I think it should be quite profound… set the tone for the rest of the blog, hint at topics to come and perhaps discuss one particular topic of utmost importance, including some ground-breaking insights.  You know… show how Really Smart we are.

Hmm, I’m coming up a little short on ground-breaking insights today, so I think Gregg should do the first one. 

From: MARKSON Howie
Hey Really Smart Developers,

It seems like we should start a really cool blog.  Everyone else is doing it and we certainly are at least as interesting as everyone else.  Maybe more so, if you consider we live in Colorado.  Plus we know a lot about developing engineering software and we talk with other developers, our customers, everyday.  So what do you think?  Anybody have any suggestions on what we could talk about in our blog?