Slashdot Mirror

My Java tip for the near future is Echo2 or something like it. Sophisticated AJAX without writing a line of HTML or JavaScript.

Here's another example of an AJaX e-mail client written using the Echo2 Web Framework. This one is very much no frills (it's an example app for Echo2) but it does include complete MPL/LGPL/GPL source.

Here's another example of an AJaX e-mail client written using the Echo2 Web Framework. This one is very much no frills (it's an example app for Echo2) but it does include complete MPL/LGPL/GPL source.

Why not just use Echo2 and not have to worry about the details of an AJAX implementation for Java? I generally prefer not to reinvent the wheel, and with all of the various browser quirks with respect to AJAX, that's quite a non-trivial wheel to try and recreate.

From my experience, Echo 2 is by and large the most complete and stable AJAX toolkit for Java. It has a very nice pure Java swing-like API and is very extensible. The Online Demos are very cool and definitely worth a look. If Atlas is the AJAX framework for .NET, Echo2 has got to be the equivalent for Java.

I've used it on TrackIt for a few weeks now and in my opinion, it is head and shoulders above any open source Java web framework, AJAX enabled or otherwise.

From my experience, Echo 2 is by and large the most complete and stable AJAX toolkit for Java. It has a very nice pure Java swing-like API and is very extensible. The Online Demos are very cool and definitely worth a look. If Atlas is the AJAX framework for .NET, Echo2 has got to be the equivalent for Java.

I've used it on TrackIt for a few weeks now and in my opinion, it is head and shoulders above any open source Java web framework, AJAX enabled or otherwise.

It was a while back. I think it was about 2 years ago, but it could have been a bit more. Anyway, I ran into UI glitches and bugs all over the place, just trying to deal with the demos. I recognize that you have a difficult job dealing with browser stupidity, but the end result is what I care about.

Were you using components other than those included in the stock Echo distribution, and was the stock distribution a final version? Were any add-on components you were using from beta versions of component libraries? Did you seek any help from the developer forums?

Of course I can't even try to take another look at your demos today, because your server is refusing connections, and that doesn't exactly project a solid professional image either.

The Echo 1.x demos had to be taken offline due to server-related issues that will be rendered irrelevant when nextapp.com moves to its new server shortly. The notice on the demo page indicating such appears to have been accidentally removed in the latest update to the site a few days ago. I was not aware of this until reading your comment; the correct page is now online once again.

Though the 1.x demos have been offline for several weeks, the Echo2 demos are presently available and server logs indicate there have been no recent interruptions in service. If you want to see a demo of Echo2, please visit: http://www.nextapp.com/products/echo2/demo My apologies for the inconvenience with regard to the Echo 1.x demos.

Best regards
--Tod Liebeck
    NextApp, Inc.

Echo and .Net are From-based web apps. Every click / button push results in a form being submitted to the server, and the whole page being re-drawn. This is no different than any other form of web development done for the past 15 years, the only benefit is ease of development or deployment on the server side.

You're correct with regard to the Echo 1.x platform (originally released in early 2002), but the upcoming 2.0 version of Echo, "Echo2", is built entirely around the technologies now being referred to as "Ajax". Every single update to the state of an Echo2 application is performed by partial updates to a DOM (there is no case in which an entire document is reloaded or swapped out). All client-server synchronization is performed over XMLHttpRequests, with the client sending an XML message describing a user's input and the server reciprocating with an XML message containing directives to update the state of the user interface.

You can see all the XMLHttpRequest stuff in action by appending "?debug" to an application's URL, e.g., click the following link to run the interactive test app in debug mode:

http://demo.nextapp.com/InteractiveTest/ia?debug

You'll need to allow a pop-up through as the "Debug Pane" runs in a separate top-level browser window.

Note that running in debug mode will reduce the speed of an application to a crawl, especially in Internet Explorer. Normal operation can be restored by simply closing the debug window.

Currently Echo2 is on its second release candidate, with the final version being released imminently. More info on Echo2 can be found here:

http://www.nextapp.com/products/echo2

The Echo2 demo apps may be found here:

http://www.nextapp.com/products/echo2/demo (Both of these can be operated in debug mode.)

Best regards
--Tod Liebeck
    NextApp, Inc.

Echo and .Net are From-based web apps. Every click / button push results in a form being submitted to the server, and the whole page being re-drawn. This is no different than any other form of web development done for the past 15 years, the only benefit is ease of development or deployment on the server side.

You're correct with regard to the Echo 1.x platform (originally released in early 2002), but the upcoming 2.0 version of Echo, "Echo2", is built entirely around the technologies now being referred to as "Ajax". Every single update to the state of an Echo2 application is performed by partial updates to a DOM (there is no case in which an entire document is reloaded or swapped out). All client-server synchronization is performed over XMLHttpRequests, with the client sending an XML message describing a user's input and the server reciprocating with an XML message containing directives to update the state of the user interface.

You can see all the XMLHttpRequest stuff in action by appending "?debug" to an application's URL, e.g., click the following link to run the interactive test app in debug mode:

http://demo.nextapp.com/InteractiveTest/ia?debug

You'll need to allow a pop-up through as the "Debug Pane" runs in a separate top-level browser window.

Note that running in debug mode will reduce the speed of an application to a crawl, especially in Internet Explorer. Normal operation can be restored by simply closing the debug window.

Currently Echo2 is on its second release candidate, with the final version being released imminently. More info on Echo2 can be found here:

http://www.nextapp.com/products/echo2

The Echo2 demo apps may be found here:

http://www.nextapp.com/products/echo2/demo (Both of these can be operated in debug mode.)

Best regards
--Tod Liebeck
    NextApp, Inc.

Echo and .Net are From-based web apps. Every click / button push results in a form being submitted to the server, and the whole page being re-drawn. This is no different than any other form of web development done for the past 15 years, the only benefit is ease of development or deployment on the server side.

You're correct with regard to the Echo 1.x platform (originally released in early 2002), but the upcoming 2.0 version of Echo, "Echo2", is built entirely around the technologies now being referred to as "Ajax". Every single update to the state of an Echo2 application is performed by partial updates to a DOM (there is no case in which an entire document is reloaded or swapped out). All client-server synchronization is performed over XMLHttpRequests, with the client sending an XML message describing a user's input and the server reciprocating with an XML message containing directives to update the state of the user interface.

You can see all the XMLHttpRequest stuff in action by appending "?debug" to an application's URL, e.g., click the following link to run the interactive test app in debug mode:

http://demo.nextapp.com/InteractiveTest/ia?debug

You'll need to allow a pop-up through as the "Debug Pane" runs in a separate top-level browser window.

Note that running in debug mode will reduce the speed of an application to a crawl, especially in Internet Explorer. Normal operation can be restored by simply closing the debug window.

Currently Echo2 is on its second release candidate, with the final version being released imminently. More info on Echo2 can be found here:

http://www.nextapp.com/products/echo2

The Echo2 demo apps may be found here:

http://www.nextapp.com/products/echo2/demo (Both of these can be operated in debug mode.)

Best regards
--Tod Liebeck
    NextApp, Inc.

I suggest the Echo2 website:
http://www.nextapp.com/products/echo2/

It's sweet, an Open Source framework for developing client-server apps with the display in dynamic html using XMLHttp as a transport.

What, like this?

http://www.nextapp.com/products/echo2/

echo2 is still under development, but echo1 (its non-ajax predecessor) is excellent. Its api will seem very familiar to anyone who has coded swing apps. You don't need to know any html or javascript at all.

Try the demo of echo2. It's pretty amazing considering its still in alpha.

Isn't he describing something like the Echo Framework?

Hey look, a web framework that uses javascript to dynamically update itself! It's only been around at that website since 2002.

They might as well just write a bloody all-in-one operating system and get it over with. :P

Man, with what they have now, if they just set up some kind of browser-based productivity /office tools (based on e.g. Echo or summat) then for all practical purposes they will have made the first true multi-platform OS ever !

The underlying OS (win, linux, whatever) will just act as a kind of bloated BIOS. The browser being somewhat equivalent to the windowing system.

Where do I sign up ?

Thomas-

What I intended to convey in this statement was the difference between "page-based" and "non-page-based" frameworks. For a better explanation that isn't cut down to a soundbyte, take a look at this developerWorks article:

http://www-106.ibm.com/developerworks/java/library /j-echo1/

Another item worth checking out to better explain how Echo actually works from a technical perspective is to take a look at the "high-level technical overview" on the nextapp.com site:

http://www.nextapp.com/products/echo/doc/hltov/

Best regards
--Tod Liebeck
NextApp, Inc.

I picked a couple of controls from the Echopoint demo to look at:

1. It takes ages to load. So what's it doing? Caching JavaScript?
2. The DatePicker and DateFinder controls require a server round-trip to change the month you're looking at! That's way behind the times. So what happened to whatever it was loading for 1?
3. The tree control seems to default to 'not client side'. That's wrong - it should autodetect.

Now maybe this is all some protest against me because I'm using IE and it all works client-side by default in Mozilla - but that wouldn't be very professional.

.. once I discovered echo and echopoint

I haven't looked back since.

To sum echo up:

Write web applications using a swing like API.

You may actually be thinking of echo.

"I found this to be the worst web development ever. Using javascript to instead of regular links makes it slower and messier. Just because the application may be a little easier to write doesn't make it a good idea. In the email example, the login form submit uses javascript. "

The act of using JavaScript in place of a link should not have a noticeable impact on performance. Please take a look at the Echo high-level technical overview documentation for more information about why we're doing things like this. Specifically, look at chapter 2, "Client/Server Interaction".

"The link to view the email uses javascript and reloads both frames, very inefficient. It also seem to do multiple submits/redirects just to load one page. One could have just used to highlight the table row, instead of reloading the entire window."

With regard to the "multiple submits/redirects": I think you are seeing the client-browser download the small JavaScript resource files that are required to make the application work. These are downloaded on an as-required basis, and are cached for future use. After two or three clicks, this issue goes away.

With regard to using JavaScript to highlight a single row of the e-mail message list in order to avoid reloading its frame, you are very much correct in that this would be more efficient. It is possible to do exactly that, but it would have required the creation of an Echo component that rendered a few bits of HTML and JavaScript to do it. This was out of the scope of the tutorial, so instead the stock Echo components were used. For more info on creating Echo components that render their own HTML and script, see the Component Authoring Tutorial.

"Not only that, but the app doesn't even work in Mozilla for me!!"

I take it you're using Firebird 0.6.1? Another slashdot user reported this issue and I've looked into it. Echo works with 0.6 and the latest nightlies, but not with 0.6.1 (possibly due to a bug in 0.6.1). It also works quite well with the Mozilla 1.0-1.4 series. Please take a look at this post for more details on the problem.

"I found this to be the worst web development ever. Using javascript to instead of regular links makes it slower and messier. Just because the application may be a little easier to write doesn't make it a good idea. In the email example, the login form submit uses javascript. "

The act of using JavaScript in place of a link should not have a noticeable impact on performance. Please take a look at the Echo high-level technical overview documentation for more information about why we're doing things like this. Specifically, look at chapter 2, "Client/Server Interaction".

"The link to view the email uses javascript and reloads both frames, very inefficient. It also seem to do multiple submits/redirects just to load one page. One could have just used to highlight the table row, instead of reloading the entire window."

With regard to the "multiple submits/redirects": I think you are seeing the client-browser download the small JavaScript resource files that are required to make the application work. These are downloaded on an as-required basis, and are cached for future use. After two or three clicks, this issue goes away.

With regard to using JavaScript to highlight a single row of the e-mail message list in order to avoid reloading its frame, you are very much correct in that this would be more efficient. It is possible to do exactly that, but it would have required the creation of an Echo component that rendered a few bits of HTML and JavaScript to do it. This was out of the scope of the tutorial, so instead the stock Echo components were used. For more info on creating Echo components that render their own HTML and script, see the Component Authoring Tutorial.

"Not only that, but the app doesn't even work in Mozilla for me!!"

I take it you're using Firebird 0.6.1? Another slashdot user reported this issue and I've looked into it. Echo works with 0.6 and the latest nightlies, but not with 0.6.1 (possibly due to a bug in 0.6.1). It also works quite well with the Mozilla 1.0-1.4 series. Please take a look at this post for more details on the problem.

"I found this to be the worst web development ever. Using javascript to instead of regular links makes it slower and messier. Just because the application may be a little easier to write doesn't make it a good idea. In the email example, the login form submit uses javascript. "

The act of using JavaScript in place of a link should not have a noticeable impact on performance. Please take a look at the Echo high-level technical overview documentation for more information about why we're doing things like this. Specifically, look at chapter 2, "Client/Server Interaction".

"The link to view the email uses javascript and reloads both frames, very inefficient. It also seem to do multiple submits/redirects just to load one page. One could have just used to highlight the table row, instead of reloading the entire window."

With regard to the "multiple submits/redirects": I think you are seeing the client-browser download the small JavaScript resource files that are required to make the application work. These are downloaded on an as-required basis, and are cached for future use. After two or three clicks, this issue goes away.

With regard to using JavaScript to highlight a single row of the e-mail message list in order to avoid reloading its frame, you are very much correct in that this would be more efficient. It is possible to do exactly that, but it would have required the creation of an Echo component that rendered a few bits of HTML and JavaScript to do it. This was out of the scope of the tutorial, so instead the stock Echo components were used. For more info on creating Echo components that render their own HTML and script, see the Component Authoring Tutorial.

"Not only that, but the app doesn't even work in Mozilla for me!!"

I take it you're using Firebird 0.6.1? Another slashdot user reported this issue and I've looked into it. Echo works with 0.6 and the latest nightlies, but not with 0.6.1 (possibly due to a bug in 0.6.1). It also works quite well with the Mozilla 1.0-1.4 series. Please take a look at this post for more details on the problem.

"The Echo HTML code isn't even valid!

Such applications could break in future browsers. Browsers tend to become stricter and stricter. Only valid HTML is future-safe."

Rendering correct and "future-safe" HTML is a very critical concern in the development of Echo. In a few cases Echo will even render alternate non-standard HTML based on the results of browser detection. As we all know, browsers often don't conform to the spec. I'd personally love to be able to dump all such "workaround" code, but end-users appreciate things looking and working correctly far more than adherence to the HTML specification.

The goal is to keep Echo as close to the spec as possible. If you see something in particular where we have deviated from the specification incorrectly, please, please, please let us know. Post something on the mailing list, developer forums, or even in reply to this comment. It would be greatly appreciated.

Another issue you might find when validating Echo's generated HTML code is that some validators get tripped up by some of the URIs. W3C's for example doesn't care for the following img "src" attribute:

src="/EchoWebMail/webmail?E_id=E_ls&E_z=107a6_ 0"

"They can't even put a correct doctype declaration in the HTML!"

All Echo rendered HTML documents have a DOCTYPE declaration. If you see one that does not, please let us know. I would definitely consider this a bug.

Also, if you're referring to character set-related issues, please understand that we do provide this information in the HTTP response header. If you're cutting and pasting the source into a validator, this information will be lost.

"And frames are crap anyway, even if you do the code right."

I would disagree. Breaking up code into smaller documents that may be independently refreshed has performance advantages. Frames can be a major pain when developing page-based applications, but Echo's JavaScript libraries take care of these problems to ensure the developer doesn't have to deal with them. For example, when a user clicks a button in Echo, the server will be notified of all changes (e.g., modified text fields) in every frame and window of an application. This is performed by storing the form values in a single non-visible frame that is submitted in response to the user performing an action that requires server interaction. The response to this request will contain JavaScript directives to re-render other frames and windows of the application, thus eliminating the "big problem" encountered with frame-based apps where the developer would be required to know which frame was to be refreshed in response to a specific user action.

For more info on how Echo does this, take a look at:

http://www.nextapp.com/products/echo/doc/hltov/int eraction.html

Yes, options are always good.

Echo seems interesting, and there is also Millstone, which is truly terminal independent, whereas Echo seems to be browser only.

Fundamentally the two platforms seem to be very similar, just take a look at the HelloWorld examples: HelloWorld with Echo, HelloWorld with Millstone.

The important thing about a platform like this is the default component library, and at least Millstone has a versatile and strong component set that's also as small as possible. Take a look at their feature demo that showcases the basic components. The feature demo itself runs on Millstone.

the echo project contains the base functionality of widgets. this provides a very clean base from which customization is made trivial.

echopoint, a derivative project, does provide things like wizardpanes, tabbedpanes, trees (just like swing).

it's worth a look, and echopoint poker is good enough to kill a few hours...

the echo project contains the base functionality of widgets. this provides a very clean base from which customization is made trivial.

echopoint, a derivative project, does provide things like wizardpanes, tabbedpanes, trees (just like swing).

it's worth a look, and echopoint poker is good enough to kill a few hours...

All this talk about the back button is interesting, but it seems to ignore one of the biggest failings with todays web browsers, and that is the whole page based metaphor. Now it works great for content that lends itself to it, but it sucks for the ever increasing sites that use the browser as an application front end vs a simple content reader. For anyone whose done any application creation in html/http you know what type of nightmare exists trying to keep track of user sessions and making your app "back button" proof.

There are application frameworks in existance which provide the capabilities you're referring to, specifically moving away from the page-based metaphor to an "application-based" approach. Check out the Echo Framework. In its case it simply disables intra-application use of the back button.

I see that the difference in the nunber of features between Echo and Millstone is huge -- in favour of Millstone. I think that this can be most easily demonstrated by just going through Millstone feature online demo [millstone.org] (also available for download [sourceforge.net]) and Echo Test application [nextapp.com]. Some of the most obvious differences are: extensive data binding, server side events, tree component and xsl-theme support.

I am the lead developer of Echo. I am therefore, by definition, not qualified to make an unbiased comparison between Millstone and Echo. An analysis by a developer of either product will be flawed because that developer will be significantly more familiar with his/her own product than that of another. Such a developer also has an interest in seeing a particular outcome to any comparison.

That said, I do feel the need to set a few things right. First of all, to perform a feature-for-feature comparison between Millstone and Echo, one also needs to consider EchoPoint. EchoPoint is an LGPL licensed collection of Echo components. It includes features such as the mentioned server-side event generation and a large collection of user-interface components including trees. For more information about these components, visit http://echopoint.sourceforge.net, or specifically http://echopoint.sourceforge.net/LinkedArticles/Us ingEchoPointComponents.html. Also, please note that the TestForEcho application is not intended as a demo. TestForEcho is maintained only as an interactive test application for the framework, and as such, its aesthetics and demonstrative capabilities are quite limited.

As far as the data-binding issue goes, I am not aware of how Millstone distinguishes itself from Echo. Both frameworks use an architecture where data is decoupled from the components themselves, such that developers are not required to create code to update the state of components when their represented data changes.

In the case of XSL stylesheet-baesd themes, you are correct that Echo does not provide this capability in this manner. The reason we have not pursued this course is architectural: Echo goes about rendering the HTML and JavaScript representations of components using Java-based renderers, which take into account the eccentricities of different Web browsers to ensure consistent output. Look-and-feel definition is handled on the "component-side" of the framework, rather than the "rendering-side." Should one desire to fully externalize L&F information, the EchoPoint project provides a package to do so by placing such data into cascading-style-sheet-like resources.

One thing everyone needs to bear in mind when considering Echo or making comparisons against it is that it has been developed for the creation of Web-based applications, not for the creation of Web pages. The term "Web application" is often gratuitously used to describe the spectrum of software between a feedback form and an online banking system. Echo is intended for the latter portion of this spectrum. It was built to offer capabilities previously only available to rich-client (desktop-based) interfaces.

In order to offer a level of capability approaching that of rich-clients, Echo includes features which are to the best of my knowledge not available from any other framework. Echo provides a client-side state management engine, written as a series of cross-browser JavaScript modules which serve to synchronize the state of the client browser with that of the server-side application. This engine is capable of managing multiple browser windows with a degree of control that is far beyond what one would expect from a Web application framework. Echo makes use of a hidden "controller" frame in each browser window to transparently communicate the state of the client to the server, and to allow the server to issue directives back to the client without re-rendering unchanged resources. While my description of these features unfortunately must be quite technical, the real benefit of them is a user and developer experience not unlike that seen with a rich-client interface.

Please understand that my comments are in no way intended to flame or otherwise deride the Millstone framework. I wish you folks nothing but the best.

Best regards

First a disclaimer: I am one of the head developers of Millstone and CEO of the company behind it.

I see that the difference in the nunber of features between Echo and Millstone is huge -- in favour of Millstone. I think that this can be most easily demonstrated by just going through Millstone feature online demo (also available for download) and Echo Test application. Some of the most obvious differences are: extensive data binding, server side events, tree component and xsl-theme support.

Still Echo is very nice framework and provides good competition for Millstone. I hope that the both frameworks gain popularity.

This seems quite similar to echo which is getting close to reaching 1.0. Can anyone comment as to how the two compare?

I agree with the above post. If you have an intranet and a complicated application then you may as well provide your client machines with a downloadable application (this can be done through the intranet site using something like Java Webstart). That being said, if you really MUST provide a web-based applictation, I'd recommend taking a look at the Echo Web Application Framework. I haven't played with it much but it purports to allow one to produce HTML-Javascript applications using Swing style programming.

I don't know of an immediately available solution to your situation, but I am working on an application framework that will allow developers to create products that meet your needs. The framework is called Echo, and it licensed under the GNU LGPL license. It's written entirely in Java, and runs in any Java Servlet container (v2.2 or higher). It enables a developer to create Web-based applications using a component/event-driven methodology and an API similar to Swing.

Echo takes care of all HTML/JavaScript rendering and HTTP request handling for the developer. It currently supports Mozilla or IE 5.x+ browsers (it does not require any plug-ins or client-side Java). Its built-in capabilities are limited to those that a JavaScript-enabled browser can provide, but it is built to be extended, such that it is possible to create components that will embed complex DHTML/JavaScript-based or Applet-based widgets within an application.

Echo is under development, with a stable release targeted in a month or two. The project is hosted at sourceforge.net at http://sourceforge.net/projects/echo, if you want the latest info, feel free to join the mailing list. Tutorials and a white paper are available at http://www.nextapp.com/products/echo