I don't see the problem of using a servlet-applet combination for interactions with a server through a user-friendly graphical interface inside a browser. It really isn't asking much for a graphical designer to learn how to use Swing and java graphics APIs.
:D
I take the point here to be "How does Echo fit with the needs of the creative/graphics design team when building applications?" Certainly a valid question.
First of all, I'd like to make clear that Echo isn't based on Swing, and you don't wind up using the Java graphics APIs all that much (they're only used when you want to dynamically generate images, which isn't necessary in most applications). Echo has enough similarity with Swing that your underlying statement is still valid: creative designers are not going to be working with it.
The interactions between designers and developers when building an Echo application will be the same as they would have building a rich/thick-client app. The responsibility is placed on the developers to integrate the graphical elements designed by the creative team into the application. We can "get away with this" for a couple of reasons:
- Echo is best used in scenarios where rich clients would be otherwise. Such applications don't tend to be "Web-site-like", where presentation is everything, and visual pieces are modified every few weeks at the whim of the marketing department.
- The API used by Echo developers to lay out user-interfaces is easier to work with than HTML. For example, there are dozens of little tricks used by web developers to get HTML tables to lay out content correctly. It's not uncommon to have to do quite a bit of arithmetic calculation if you want to construct, for instance, a table that has fixed width cells, margins, paddings, and some cells spanning multiple columns (I'm sure some might think I'm full of it here, but I bet their tables don't look right on all platforms/browsers:)). Anyway, point being, Echo's Grid component offers a much simpler interface and performs such calculations (and many other table rendering tricks) for the developer. You can even do things like allowing cells to fill empty space in a particular direction. The result is that the effort required of the developer to integrate visual design elements into an application isn't anywhere close to what it is with a traditional roll-your-own-HTML app.
While I'm at it, one other thing I need to mention is that Echo doesn't make use of any applets. It's all servlet-based, and the client-side user interface is rendered using only HTML and JavaScript. (Although it is possible to write Echo components that embed items such as Applets, movies, or Flash objects).
akweboa164 wrote: Each of the sample apps don't seem to work in Mozilla Firebird 0.6.1.
Thanks for pointing this out. On looking into it, Echo does NOT appear work on Firebird 0.6.1 on either Windows or Linux. 0.6 works properly, as does a fresh nightly build that I downloaded just a minute ago. Mozilla 1.0-1.4 also should work fine. Mozilla and its derivatives are very much in the "first-tier" of target environments for Echo. It's quite frustrating to see that this problem with 0.6.1 was not previously noticed.
The particular piece of code that appears to be tripping up 0.6.1 is a single line of javascript:
history.go(1);
This is used to ensure the browser is always on the latest page of the history at all times. When executed in Firebird 0.6.1, a JS exception occurs indicating that the "history object has no properties". On further investigation, it appears that the history object does not exist in 0.6.1. I'm guessing that this is a problem in this particular version of Firebird, as no other browser encounters this issue, including previous and current (nightly build) versions of Firebird. The O'Reilly JS (rhino) book seems to think the code is legal too.
If this problem presents itself in future versions of Mozilla, Firebird, or any other browser, we'll have to modify the browser detection startup script to disable this feature based on browser type (unless of course I'm wrong and history.go() is no longer fashionable).
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.
Slashdot Mirror
I don't see the problem of using a servlet-applet combination for interactions with a server through a user-friendly graphical interface inside a browser. It really isn't asking much for a graphical designer to learn how to use Swing and java graphics APIs.
:D
:)). Anyway, point being, Echo's Grid component offers a much simpler interface and performs such calculations (and many other table rendering tricks) for the developer. You can even do things like allowing cells to fill empty space in a particular direction. The result is that the effort required of the developer to integrate visual design elements into an application isn't anywhere close to what it is with a traditional roll-your-own-HTML app.
I take the point here to be "How does Echo fit with the needs of the creative/graphics design team when building applications?" Certainly a valid question.
First of all, I'd like to make clear that Echo isn't based on Swing, and you don't wind up using the Java graphics APIs all that much (they're only used when you want to dynamically generate images, which isn't necessary in most applications). Echo has enough similarity with Swing that your underlying statement is still valid: creative designers are not going to be working with it.
The interactions between designers and developers when building an Echo application will be the same as they would have building a rich/thick-client app. The responsibility is placed on the developers to integrate the graphical elements designed by the creative team into the application. We can "get away with this" for a couple of reasons:
- Echo is best used in scenarios where rich clients would be otherwise. Such applications don't tend to be "Web-site-like", where presentation is everything, and visual pieces are modified every few weeks at the whim of the marketing department.
- The API used by Echo developers to lay out user-interfaces is easier to work with than HTML. For example, there are dozens of little tricks used by web developers to get HTML tables to lay out content correctly. It's not uncommon to have to do quite a bit of arithmetic calculation if you want to construct, for instance, a table that has fixed width cells, margins, paddings, and some cells spanning multiple columns (I'm sure some might think I'm full of it here, but I bet their tables don't look right on all platforms/browsers
While I'm at it, one other thing I need to mention is that Echo doesn't make use of any applets. It's all servlet-based, and the client-side user interface is rendered using only HTML and JavaScript. (Although it is possible to write Echo components that embed items such as Applets, movies, or Flash objects).
Each of the sample apps don't seem to work in Mozilla Firebird 0.6.1.
Thanks for pointing this out. On looking into it, Echo does NOT appear work on Firebird 0.6.1 on either Windows or Linux. 0.6 works properly, as does a fresh nightly build that I downloaded just a minute ago. Mozilla 1.0-1.4 also should work fine. Mozilla and its derivatives are very much in the "first-tier" of target environments for Echo. It's quite frustrating to see that this problem with 0.6.1 was not previously noticed.
The particular piece of code that appears to be tripping up 0.6.1 is a single line of javascript:This is used to ensure the browser is always on the latest page of the history at all times. When executed in Firebird 0.6.1, a JS exception occurs indicating that the "history object has no properties". On further investigation, it appears that the history object does not exist in 0.6.1. I'm guessing that this is a problem in this particular version of Firebird, as no other browser encounters this issue, including previous and current (nightly build) versions of Firebird. The O'Reilly JS (rhino) book seems to think the code is legal too.
If this problem presents itself in future versions of Mozilla, Firebird, or any other browser, we'll have to modify the browser detection startup script to disable this feature based on browser type (unless of course I'm wrong and history.go() is no longer fashionable).
Thanks again!
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.
s 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.
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/U
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