Weaving WebSphere: AIRPort Now Arriving

[MCWebsite.Staff]

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
** This thread discusses the Content article: Weaving WebSphere: AIRPort Now Arriving **
0

[dbaleTHI]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
You dare to incur the wrath of John Denver fans?!?!? A pox on you, Joe!

[H.Boldt]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
Joe: Reading about Airport reminds me much of another simple web programming technique that's been around a while. Can you compare and contrast your Airport technology with putting each portal in its own frame? Cheers! Hans

[J.Pluta]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
Sure, Hans. As opposed to AIRPort, frames are really quite setup-intensive and fairly rigid once defined, which may be one reason why they're not used much. They're not entirely bad; an example is a frame with copyright information on the bottom of the page, or a navigation frame which helps scroll a particular long content page. The primary characteristic of frames is that you have complete control over the layout of the frames on the page, which makes such absolute positioning possible. On the downside, this layout is quite static. You have to set up an initial HTML page which defines the frames and their initial URLs. In this page, you set up the absolute positioning of the frames. There can only be one layout, this layout cannot change (while you can change the sizes of the frames, you can't change their relative positioning). That's the primary difference between frames and AIRPort. Because AIRPort uses SPANs to target its output, it is quite easy to change the size, position and even the visibility of a given element within the page. On a positive note, if you found the frames methodology to be an absolute requirement, you could easily create a frames-based layout and then use AIRPort to populate the frames. Thus your primary interface to the server side would remain constant, while your UI presentation could take advantage of the benefits of frames. Joe

[dmcdona1]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
This is a little off subject but I believe we need to also start a new acronym. The acronym is Stacronym. It stands for Stacked Acronym. The world is so full of acronyms that we have acronyms within acronyms, AIRPort being one of them. AIRport is a four-level stack. Level 1 is AIRPort. Level 2 is AJAX Integrated Responses for Portals. Level 3 is Asynchronous JavaScript and XML Integrated Responses for Portals. Level 4 is Asynchronous JavaScript and Extensible Markup Language Integrated Responses for Portals. Also keep in mind that multiple airplanes waiting in line to land is a Stack of Airplanes. Now… who can give me a five-level stack?

[GlenKerner]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
Joe, I read your article and like aways it was very thought provoking and educational. (Think I buttered you up enough?...haha) I was wondering, could or can AIRPort be utilized in some of the programming Case tools out there as well as some of the development environments. I was specifically wondering about Lansa for Web. The is always some need to build javascript to handle functionality that is not always there. I don't know if you have tried using with Websphere Developer the or similar packages for development?

[J.Pluta]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
Triple-stacks like AIRPort are pretty new, because I think AJAX is one of the first widely used double-stacked technical acronyms. (My numbering is one off of the original poster's; in my terminology a double-stacked acronym is actually three layers - e.g., XML is the first stack, while AJAX is the double-stack). Although any acronym using XML is a double-stack, most of those are application or product names, which tend to end the stacking process. In order to be stackable, the acronym must be able to be included with something else and people tend to not include proprietary products in acronyms. However, since AJAX is a technical term it lends itself to stacking, and thus the triple-stacked (or four-layer) AIRPort. All this talk about double- and triple-stacks makes me think about Wendy's Hamburgers, and now I'm hungry... Joe

[J.Pluta]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
Well, I'm already considering it for inclusion in my PSC/400 product, so yes I think the AIRPort concept is applicable to just about any environment. One thing we're looking at is using it at a public website (whose name will be disclosed at a later date ) in order to make it easy to showcase multiple technologies. The beauty of AIRPort is that it is really easy to integrate different server-side technologies (hence the "I" in AIRPort). How easily a technology can be integrated depends on how well it supports outside URLs. For example, it's relatively easy to pass data out of a web application by simply creating a URL with parameters. It's a bit trickier to accept a URL with parameters and integrate it into your application. PSC/400 does it; others may not. Another option is to use a different case tool. My next major Open Source initiative will be to attach AIRPort to EGL, which is a really high-level development environment. If that works, you could see a very powerful application development environment in a very short time frame. Joe

[J.Pluta]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
I wasn't dissing ol' JD... just noting that "Leaving" was perhaps best left to others. And considering the circumstances of his untimely demise, it might be argued that the song was something of a dark foreshadowing, anyway. Joe

[H.Boldt]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
Joe: I'm not a big fan of frames myself, although I was tempted to use an iframe once. Frames have a number of well-known problems: You can't bookmark within framed sites and navigation can sometimes be a problem. But then again, AJAX enabled sites suffer these same problems! Do frames have to be rigid? No. I know that at least iframe's can be resized. Basically, like Airport, frames are a way to combine input from several http requests. Like Airport, you can (with a bit of simple Javascript coding) update multiple frames. But unlike AJAX code, frames won't cause the browser to hang while waiting on a request. If you still want or need to handle asynchronous requests, you can still use simple AJAX within a frame. Maybe it's just the curmudgeon in me speaking, and maybe I'm missing something in all this, but the more I think about it, the more it seems like all you've done is re-implement frames using AJAX. Granted, you've hinted at the possibility of more cool features in Airport. But then again, the scenario you describe already should be sufficient for most business applications. And that scenario could already easily be implemented using iframe's. No? Anyways, I'm sure I must be missing something important in this. Please educate me. Cheers! Hans

[J.Pluta]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
I don't plan to educate you, Hans. You can do that yourself. I'm also not going to argue the merits of frames; again you can find information on that elsewhere. Also, please note that you've switched back and forth between "frames" and "iframes" in your discussion; these are two VERY different entities. It's one of the may reasons people don't use either except in specific instances. But, no, Hans, I didn't reinvent frames, any more than the entire Portal concept reinvented frames. Tare two fundamental differences between frames and any portal framework, but especially AIRPort. First, frames are separate, specific entities in the DOM. They have specific properties (such as scrollability) and the code required to navigate the DOM from one frame to another is a little bit tricky. As an example, printing an entire page including frames is sometimes problematic. (iframes are a little better, but not much.) With AIRPort, the code is simply included inline with the rest of the HTML. You can, as I pointed out, put that code in a frame if that's what you want. Or you can just as easily put it in a table cell. Or include it as a navigation bar, or a banner. You can use AIRPort to include any portion of your page, and it will immediately become integrated with and accessible to the rest of the page, including printing. Second, frames (and especially iframes!) are rectangular blocks that really are separate from the rest of the screen. iframes in particular usually have a border around them and scroll bars so that they really look like a window within a window. If this is your goal, then use frames - but you can STILL load them dynamically using AIRPort. But AIRPort simply includes HTML, which could be anything from a table to an image to a JavaScript function. Joe

[nandelin]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
It's pretty remarkable what passes as an open source project these days. I guess they all start somewhere. I guess it's the idea that counts. And filling in the innerHTML property of [span] tags via AJAX is a pretty good idea. It may be a far cry from a portal, but every great work begins with a simple idea. Maybe it could be called the beginning of a dashboard. Of course the interface is fast. Everything shown on the screen is in memory. Incrementally refreshing portions of the screen is what AJAX is all about. No database access. No business logic. The vision of AJAX is catching on. The user interface is changing, AGAIN.

[J.Pluta]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
"It's pretty remarkable what passes as an open source project these days." Nathan, I'm pretty unsure as to how to take this. It's a project because it includes complete, working code that can be extended or expanded by anyone. It's open source because I made the source available. Thus it's an open source project. What do you think makes it not measure up? The fact that it's only a few hundred lines of code? Size matters? As to a far cry from a portal, it's not. That seems to be the part you are missing. It's a complete portal implementation, from the standpoint that you can write individual working "AIRPlanes" if you will (to differentiate them from portlets) and use the framework to bind into a single working application. What's more important is what it doesn't have. What it DOESN'T have is all the administrative overhead associated with traditional portals, most of which is unnecessary in the business application niche (and the reason that it's so small). With this framework, I can bang out entire working applications in a few hours. "Open source" isn't necessary about huge projects like Linux; it's about using technology in a new way and then publishing that for others to use. By the way, I've also got a database application running. It took me just a couple of hours. Even running in the WDSC test environment on my desktop and connected to the iSeries over a LAN, I can display 150 records in about a quarter of a second. I also want to write something a little more substantive that uses iSeries APIs. I'd like to connect to a local database on my workstation as well, maybe even a pure Java database. All of that will be in later releases. I'm sure you noticed this was an alpha version, version 0.1.0. I wanted to publish this alpha version first because it can run completely on the desktop with no host. In my copious free time I'll certainly be putting together versions with various forms of database access and different languages (in fact, AIRPort will be PERFECT for testing various database access techniques side by side in the same browser). But if the first thing I published only ran on an iSeries, it would have a far smaller target audience than what it has now. Heck, there have been nearly 40 downloads already; that's more than a lot of projects get in their entire lifetime. I'm sorry you're not impressed, but I'll get over it . Joe

[Guest.Visitor]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
I always look forward to see what you are up too... thanks, and keep it coming.

[J.Pluta]

Weaving WebSphere: AIRPort Now Arriving

** This thread discusses the article: Weaving WebSphere: AIRPort Now Arriving **
Thanks! I really appreciate that. I sometimes don't get the same response that other writers get, and I always wonder if it's because I covered the topic very well, or very poorly . This topic in particular is going to need a lot of input from the user community to keep it sustained, but I hope that once a few people play with it they'll see just how cool it is. Joe