NextApp Releases Echo Web Application Framework 1.0 Beta

Discussions

News: NextApp Releases Echo Web Application Framework 1.0 Beta

  1. NextApp's "Echo" Framework is a platform for developing highly interactive Web-based applications. From a developer's standpoint, Echo resembles a user-interface toolkit: applications are built using a component-based, event-driven architecture. Echo's API borrows from the design principles of Swing while making accommodations for the low-bandwidth, semi-stateless nature of Web clients.

    Traditional "page-centric" architectures can limit the capabilities of Web applications. Page-centric designs are very difficult to implement when user interfaces call for multiple forms, frames, and windows. The situation further degrades when dynamically generated embedded objects are required, such as charts, graphics, and reports. As the requirements escalate, page-centric designs become exponentially more difficult to work with, often forcing developers to seek thick-client solutions. Echo removes the developer from having to think in terms of page-centric design, while still providing the zero-cost-per-client deployment of a Web-based solution.

    Every aspect of an Echo application is component- and event-based. HTTP interactions and HTML/JavaScript rendering are handled by Echo's "application container". The container is responsible for synchronizing the state of the client browser to the component hierarchy specified by the application. From the developer's perspective, all operations are performed using method calls and events no different from those of a user-interface toolkit. Complex JavaScript operations such as retrieving data from multiple forms, opening and closing windows, and updating multiple frames at once are handled without developer involvement. The application container even goes so far as to monitor the positions of the client browser's scroll bars to ensure they don't reset when frames are refreshed. The overall effect, from both the developer's and end-user's point-of-view is of working with a desktop application.

    Echo presently supports Internet Explorer (5.5+), Mozilla (1.0+) and Opera (6.0) browsers and their derivatives (partial support is available for Netscape 4.x and IE 5.0). No plug-ins, Java Applets, or ActiveX controls are required. The framework requires a servlet container that is compliant with the Servlet 2.2 or any subsequent specification. Echo is licensed under the terms of the GNU LGPL license, enabling the royalty-free development of both free and proprietary software.

    For more information and to download Echo, please visit the NextApp Echo site at http://www.nextapp.com/products/echo/.

    Threaded Messages (53)

  2. This looks very interesting. The needs of complex web application is very different from content based web development. Most of todays HTML/Web toolkits (JSP/Struts, Velocity....) are too content based to make complex application development an easy thing to do. The development is to "page" centric for the hardcore application developer.

    The fact that it is cross browser and keeps the developer thinking in terms of widgets and events is a big improvement for the developer. Has the feel of classical thick client application development. Will give it a test drive.

    Anyone know if the Java Server Faces spec allow for this type abstraction?
  3. I'm curious on how this differs from the WINGS product.I believe this is the same general approach (e.g. events, listeners etc...), but the WINGS model, by design, mimics SWING. I would love to see someone (with the free time that I don't have) compare an contrast the two products.

    My general feeling though is that WEB developers don't want to "program" their interface. Web developers want to layout their interface using a tool, and not code "layout manager" as such.

    Don't shoot me but I think the M.S model is a more complete approach. I would love to see somewhat build a USABLE GUI builder for WINGS and or this New product.

    I also wonder how good is the "composite component" features of this product are. They give an example of "extending" a component, but I think the real difficulty is in composing a component out of multiple sub-components, not extending a single component. I haven't had a change to look closely at Tapestry, but supposedly it is very good at composite components.
  4. It's excellent at composite components.

    I don't know about wingS, but one of Echo's strengths is handling cross-frame and cross-window communication/updates.

    And about Web developers not wanting to "program" interfaces, this toolkit is not for Web developers, it is for applications developers using a Web interface. Very different.
  5. I'm sorry, I don't distinguish between Application developers and Web developers, but I understand that 'people' do distinguish between them.

    I used to be a swing developer (Application developer ?) who is now doing web development with struts (Application development with struts?)

    Coding GUIs ( I found this true with SWING as well ) is VERY cumbersome. I've forgotten the product, ( think it's wingS ) that allows you to layout your HTML and then used ID to assoicate the underlying java object with the controls. This look promising but I don't know how well this worked in practice. Also, no TOOL support.

    I have been experimenting with MS Visual Studio, and ASP.net. I think this IS heading in the right direction. I'm curious if there are other JAVA developers who have tried VisualStudio/ASP.net and have some opinions on the JAVA tool set.

    Currently, I am VERY frustrated with Struts which only does HALF the MVC job (model/conroller). And struts has no concepts of components, consequently for the user to write reusable components is VERY difficult ! The fact that events are placed in a global name space and each event is associated with a single data element (model) in memory means that you could not have 2 of the same components displayed simultaneously (e.g. if a listboxControl uses the SCROLL event, this event is assoicated with the a single ListBoxModel )
    If you had 2 instances of a listboxControl l1, l2 on a form and each generated the SCROLL event, the event would operate on the SAME ListBoxModel m1. The struts config file associates an event with a specific instance of model object. Anyway....

    It seems like a Mix of your product and Struts, combined with a GUI layout tool would make a reasonable environment. Although not an integrated product. But I want to repeat my previous point, "CODING GUI's without a layout tool is VERY cumbersome. " Sun used to have a nice layout tool with JAVA Workshop. Borlands is usable, CAFE's was horrible.

    Has any other J2EE developer out their experimented with asp.net an Visual studio. I would love to her other opinions ? Am I the only one that thinks that coding GUI's is not the optimal solution ?
  6. seconds till howard lewis ship starts pluging tapestry

    9 8 7 6..
  7. Not from what I've seen here, looks like different spaces. I'm beginning to see a split between Tapestry (where precise control over the content is important) and Echo/WingS and that IBM framework whose name escapes me, which utilize HTML and JavaScript to replicate a fat-client GUI.
  8. howard Could you expand on the first line of you response, I don't understand it.


    thanx
  9. Looks like there is a related project that is building components for ECHO:

    http://echopoint.sourceforge.net/LinkedArticles/UsingEchoPointComponents.html

    Is'nt this the type of components that the JSF spc might look to define. I heard some folks complain that the initial/current JSF spec is missing such widgets.

    With the combination of an all Java server side framework, cross browser support (via JavaScript 1.3), and a Swing like API is making ECHO look very interesting for building web applications.
  10. Whether its Struts or Echo the gaping hole in all these products is the lack of GUI form designers.
  11. I have used ASP.NET and my main problem with it was that it almost tries to do too much. I found adding client side javascript to do simple things (such as sum up totals on a grid) very cumbersome. I also found that trying to work around .NET's weaknesses was really tedious.

    Having said that, I agree that ASP.NET seems to be heading in the right way. It will be interesting to see what Java Server Faces can offer. I have had a cursory look at the EA spec and it looks promising.

    I guess the main advantage that MS products currently have (and historically this has been one of their strengths) is the tool support. Visual Studio is an excellent tool and VS.NET is even better (though still a bit buggy) Hopefully projects like Eclipse and NetBeans will help Java along the way in this respect.
  12. See Thinlets
  13. I'm sorry, but don't want to be rude, but this thinlet thing requires a java VM ? If so, that idea is DOA at all of the companies I've consulted at.
  14. I agree with what most people have said about ASP.NET - it's definitely heading in the right direction. Two companies are producing products that I find interesting this way (although very different):

    - Altio (www.altio.com): a small component download and then you've got a rich windowing environment plus they have an interesting approach to building applications - you build them using the tool online. Pretty slick. It's sort of like online VB (but don't knock it for that!) I have played around with it with our internal web services and it's pretty neat - developed an app in about a day.

    - aspxp.com (www.aspxp.com): this is pretty straight-forward. It's a grid and application component that makes it cake to set up an app to edit a database. It's pretty slick (again) although it is obviously not a true application framework. I would just love to see something this good on the Java side.

    Damian
  15. Yes, but it even oldest jdk1.1 will work, and it's very small - less than 30k.
  16. I've done some things with ASP.Net too. I like that there is a GUI development tool and is neat idea. But I also have some issues with the way it works. What I was doing was sort of complicated and it definitely was not just point and click. From what I've done with ASP.Net and seen of Echo, I would pick Echo.

    As for VS.Net - it is a good environment and improves on VS Classic :). But it should be compared to other products that cost $ like WSAD 5. And, less ASP.Net (some don't care anyway), it definitely compares.
  17. What always amazed me is when you see posts for "The Next Most Amazing Web App Development Framework" and they dont include a really "Amazing" demo.

    If any of these frameworks are as easy to use and as easy to integrate as they claim, then it should be very easy for the company to write the most ass-kicking demo we've ever seen. It always leaves me wondering if they dont have an ass-kicking demo because it would have taken them too long, which then makes me wonder if the bits are as good as advertised.

    I know in our case, we integrated our product right into our product. There is nothing that shows commitment more then eating your own dogfood.

    Dave Wolf
    Personified Technologies LLC
  18. I see your point Dave. But, correct me if I'm wrong, your product is for sale and Echo is OSS. I would expect your product to have good demos. Echo is still beta OSS. Once Echo is out of beta, I would expect some good demos to show up.
  19. Mark,

    I didn't mean for my comment to come off as flippant. It was just an observation.

    Although, one might argue with an OSS product, there are in theory more development resources then at a small comercial software company. In theory of course ;)

    Then again, why not build your main site using your own bits? Its one of the best test suites you can make.

    Dave Wolf
    Personified Technologies LLC
  20. IDE integration and/or visual tools for developing Echo applications are often requested features. Our current thinking is leaning toward development of an Eclipse plug-in. We would greatly appreciate any suggestions regarding features for such a tool.

    The issues that arise from not having visual tools tend to lessen when one has a solid library of reusable components. Developing directly in Java is easier when you have larger, self-contained components that have interfaces designed around the concerns of applications instead of the underlying framework. By removing the developer from many of the issues of browser-based deployment, we believe that Echo lends itself well to this approach.

    We do intend to develop a visual tool soon, although our present focus is on beta testing.

    Best regards
    --Tod Liebeck
      NextApp, Inc.
  21. I would like to have a GUI tool. But I think having one is a good thing and a bad thing. Without one, developers are more apt to develop components. With one, developers are more apt to develop screens/forms.

    From what I have seen, Echo fits more in the way I work. I don't want to see/code any HTML or Javascript. I can do it but it is mucho paino, at least for me.
  22. Two points:

    1) It's not my product. I'm just "Joe Developer" who happens to be familiar with the product.

    2) Your re-iteration of your point make it more clear to me what you meant, and I agree with your point. Well developed RAD tools do make GUI development much less cumbersome.
  23. Hi,

    If you need tool support for a Java-based web application framework, check out Jade from Salmon LLC (www.salmonllc.com).

    It is open-source (GPL), but you can pay for support. There was a thread on it on TSS.

    I haven't tested it myself, since I currently don't have a Windows machine available. Jade uses Dreamweaver for the layout.

    Regards,
    Calvin Loh
  24. When I tried Jade I felt it was a good product. However, whilst it did suppor Dreamweaver as a development GUI the functionality supplied by Dreamweaver let it down.

    Dreamweaver makes it simple to insert tab lib code into templates using nice easy to use forms but has no way for generated code to be edited again in those forms. This still helps you get started but is a limitation that makes editing taglibs in Dreamweaver no better than using a text editor.

    Dan
  25. I have used ASP.Net but I really don't think it is better than JSP.

    I can't dynamically define ASP web control and if I define some extract field in the Grid, I have to break the event-driven model for just that extra field in the Grid.

     
  26. A very interseting approach. But when I looked at the tutorial examples I was asking myself: How do you integrate CMS systems with that?
  27. An example please![ Go to top ]


    "Highly interactive Web-based applications"

    For all the products and frameworks announced on TSS I have not yet seen 1 (one) decent demo application..

    Regards
    Rolf Tollerud
     
  28. Re: An example please![ Go to top ]

    "For all the products and frameworks announced on TSS I have not yet seen 1 (one) decent demo application.."

    Unfortunately Echo does not make an effort to reverse this trend, as it currently only provides testing and introductory tutorial applications. A true demonstration application is not yet available. The tutorial applications are intentionally simple, in that they serve to provide new developers with a basic understanding of how Echo works. The "TestForEcho" test application is a collection of interactive tests for each of the built-in Echo components. While TestForEcho provides examples of many different components, its source code is not adequately documented to qualify it as a demonstration app.

    The EchoPoint project (EchoPoint is a collection of components for the Echo framework) also provides two sample applications. The "EchoPoint Demo" application shows off the capabilities of various EchoPoint components. The "EchoPoint Casino" application was built with the intention of demonstrating EchoPoint's HtmlTemplatePane component, with the unfortunate side effect of also demonstrating the addictive qualities of BlackJack and Video Poker.

    Our forthcoming "Sierra" product will include a complete J2EE tutorial/demonstration application. This application is built using an Echo-based user-interface connected to an EJB 2.0 back-end. The purpose of this application is specifically to demonstrate how to build real J2EE intranet applications with Echo and Sierra. Sierra is currently under development, and will be released soon. Sierra will be licensed as commercial software.

    Best regards
    --Tod Liebeck
      NextApp, Inc.
  29. Re: An example please![ Go to top ]


    <Q>Our forthcoming "Sierra" product will include a complete J2EE tutorial/demonstration application.</Q>

    I am really looking forward to see a rich, highly interactive interface with a professional design that is fast and scale well. It would be such a relief to the theoretical musings of this forum. "Viel gespr?ch und wenig verkstatt".

    "A good demo app is worth more than a thousands word" (Old Chinese saying).

    Regards
    Rolf Tollerud
     
  30. Re: An example please![ Go to top ]

    Wenn schon auf deutsch, dann aber auch bitte richtig!<p>
    "Viel Gespr&auml;ch und wenig Werkstatt"<p>
    <p>
    Au&szlig;erdem gibt es das auch geb&uuml;ldeter *g*:<p>
    "Grau, mein Freund, ist alle Theorie. Gr&uuml;n ist des Lebens goldner Baum" (J. W. v. Goethe)

    Nur meine zwei Cent
  31. Re: An example please![ Go to top ]


    Excuse me, this is a test..

    Swedish letters copied from Word ????????

    Swedish letters copied from a texteditor "??????"

    Swedish letters copied from a notepad "??????"

    Sorry..
    Rolf Tollerud
  32. An example please![ Go to top ]

    Hi Rolf,

    See the W4Toolkit homepage (post about the release appeared on TSS a little ago) for examples:

    http://www.w4toolkit.com/index.php?bsID=7

    Ciao,
    Leif
  33. NextApp looks to be a fantastic and long needed software tool... I look forward to porting my "Applet Builder" to NextApp so that I can truly have a single source code for building Applications... This could be the breakthrough I have been waiting for... A single source base to build a rich HTML, Applet, or Swing implementation of a GUI.. The Applets never took off because of Microsoft and you may have solved the problem.. I will send further feedback as I proceed, but, again, my initial response is Hallelieuia, my prayers have been answered...

    Steve Hyland
  34. I downloaded and ran the demos. They weren't bad, but try going into one hitting the back button on your browser. Nothing happens, even when you are on the first page of a demo.
  35. That is by design. The back button does not make sense in an "application". It is disabled using a bit of javascript.
  36. <quote>
     That is by design. The back button does not make sense in an "application". It is disabled using a bit of javascript.
    </quote>

    This is a very bad idea and is sure to infuriate users. First of all, you probably didn't cover all your bases (do you forbid ALT-Left Arrow too?).

    Second, whether you call it an "application" or not is irrelevant. What matters is what the UI looks like and how users perceive it. And if it looks like a Web page, it is your duty to supply a Web-like interaction.

    Most of the time, when I find the Back button disabled, it's for technical reasons, and because of the fact that the designers were lazy trying to fit their interaction model into a Web-like one. This is a guaranteed failure, IMO.

    Don't fight the browser, leverage it.

    --
    Cedric
  37. <Cedric My Hero>
    Don't fight the browser, leverage it
    </Cedric My Hero>

    I couldnt agree more. Its things like this I EXPECT from a web framework, to handle page changes no matter how they are made.

    Many moons ago we wrote a web app and developed a finite state machine which managed page changes within the app. Instead of "blocking" the back button, we simply tracked that it occured (an IllegalState change in our case) and simply asked the user to use our navigation buttons, rebuilt the state and moved on.

    Dave Wolf
    Personified Technologies LLC
  38. The framework does handle it, it keeps you on the same page.
  39. It is true that most Web applications do not disable the back button. I believe it is also true that most Web applications break when you press it at an inappropriate time.

    "Disabling" the back button is accomplished by ensuring that the displayed document is the most recent in the browser's history. In future versions, it has been suggested that Echo offer the capability for the application to receive a back button press as an event and respond to it specifically.

    The very "strengths" you are referring to of the browser environment will quickly turn into weaknesses depending on how advanced of an application you are building. When a Web browser is used to view Web documents, a back button makes a great deal of sense. But when we start to talk about *APPLICATIONS* being viewed remotely with the Web browser as a thin-client, things change a bit. Any non-trivial application is stateful. In a stateful application, the capability to arbitrarily navigate to previous application states is unacceptable.

    One of the principles of the Echo framework that sets it apart from others is that an Echo application is always aware of the exact state of the client browser. This is a significant departure from the traditional design practices of Web developers. Having the state of a server-side application synchronized with the state of the browser provides Echo the capability to support applications which otherwise might not be possible to deploy in a Web environment.

    Best regards
    --Tod Liebeck
      NextApp, Inc.
  40. Well you stopped me in my tracks from even considering taking a look at your app with the back button comment. Declaring that a MAJOR web ui navigational idea doesn't make sense is ridiculous - you're looking at usability exactly backwards. I can just imagine the multitudes of everyday end-users calling IT wondering why the back button is broken.

    It's just an example of how some UI architects get their priorities out of whack. The UI should follow from what the user is used to, how he gets things done - and if that means he uses things like the back button, even if the back button is difficult to deal with programmatically, you need to support it.

    UI attitudes like yours (trade off usability in favor of being able to set type exactly or do some trivial neato thing that's only cool to UI people) brought us things like flash UI's, and the browser window with all the nav buttons and toolbars stripped out using javascript.
  41. Wow, all this energy over a back button! Also, this is not my app so I am not too concerned what app you consider........ :)

    BTW I am sure you can turn off this feature without too much trouble.
  42. Todd,
    In looking at Echo I had a few questions I was wondering if you could answer:

    1) Regarding how state is managed. If I wanted an app to allow multiple windows to be open and each have a different state is this possible? A very simple example is the Echo Tutorial number guess example. In the current tutorial if I open two windows from the same session (same browser), they both track the same state. Is it possible to allow multiple windows/apps (of the same URL) each with its own state?

    2) Is all the HTML and JavaScript created on the backend generalized to work across all the supported browsers, or is there custom HTML/JS per browser type for certain UI components? I understand that alot of the work is based on JS 1.3 but are there cases where you do browser sniffing or do you shy away from that as a principle?

    From what I have seen so far Echo looks like a nice piece of work.

    Thanks,
    Sam Taha
  43. <Tod>
    One of the principles of the Echo framework that sets it apart from others is that an Echo application is always aware of the exact state of the client browser. This is a significant departure from the traditional design practices of Web developers. Having the state of a server-side application synchronized with the state of the browser provides Echo the capability to support applications which otherwise might not be possible to deploy in a Web environment.
    </Tod>

    I agree completely. And therefore, since you know the state at all times, it should be quite trivial to handle the back button, and 'undo it' without simply turning it off.

    For instance, the state engine would know, that the user is on Screen3. Screen3 has only ScreenEvent1 which is a valid action for that state. Now the user hits back and goes to Screen2, and hits a button. Whoa, thats an action which is illegal for the state I was in, gosh, Im a state engine, let me handle this. Now I might have dozens of ways to handle that illegal state, and we can choose which one. Maybe we warn them that wasnt nice and please stop. Maybe we simply put them back where they were. Maybe we whistle dixie. But thats powerful flexibility to the developer to choose from.

    I guess my point is, and I'm likley beating a dead horse, that if the state engine is unable to handle and repair state it speaks to the functionality, scope and power of that engine.

    Dave Wolf
    Personified Technologies LLC
  44. Dave,

    I've noticed that in several of your posts, you appear to be highly critical of the Echo framework. While I appreciate valid criticism, in the course of re-reading this thread I have come to believe that you may be operating under a fundamental misconception as to the purpose of Echo. In an earlier post, you inquired as to why the NextApp.com site was not built using Echo:

    "Then again, why not build your main site using your own bits? Its one of the best test suites you can make."

    The answer to this question is simple: Echo is designed for building Web Applications. It is *NOT* useful for building Web sites. I cannot stress this point enough. If, for example, you are building an online banking system, Echo would be a good fit. On the other hand, if you intend to use Echo to build a thousand page static Web site with a feedback form, I can guarantee that you will be very disappointed.

    With regard to your most recent post about the disabled back button issue, I appreciate your suggestion, but your proposed implementation is in direct opposition to the design goals of Echo. The purpose of Echo's state engine is to keep the client and server in sync at all times. I would consider it a flaw in the product if Echo allowed the browser to enter an invalid state and did not report it immediately to the application container.

    Best regards
    --Tod Liebeck
      NextApp, Inc.
  45. Sam,

    Thank you for the kind remarks. Please let me know if the following does not adequately answer your questions:

    1.) "Is it possible to allow multiple windows/apps (of the same URL) each with its own state?"

    Having an application with multiple windows where each window has a different state is entirely possible, but it must happen at the application level. The application must have opened the extra windows itself. Simply visiting an application from multiple browser windows will have the effect you described.

    2.) "Is all the HTML and JavaScript created on the backend generalized to work across all the supported browsers, or is there custom HTML/JS per browser type for certain UI components?"

    Most HTML and JavaScript output will be identical regardless of the browser. There are occasional circumstances where components must take into account the peculiarities of a particular browser and render slightly different HTML or JavaScript. The Echo application container provides a "ClientProperites" object which contains information about the client browser, such as browser name, version, remote host, and JavaScript version. The ClientProperites object is available to any component renderer.

    Best regards
    --Tod Liebeck
      NextApp, Inc.
  46. Tod, I like the looks of Echo and it may make me make more web interfaces. I have stayed away from 'browser based' business applications (as much as I could) for the very reasons some here were saying they would stay away from Echo. All the extra work to deal with paging etc. wasn't worth it. If I wanted to deal with paging I would have stuck with green screens.

    And as for the other persons comment on using XSL - for business frontends (not just displaying data) all I can say is yuck. Use XSL and then try to internationlize it. I've done it and it was 3 times the work, at least.
  47. So as someone who supports the back-button, how will you deal with transactional applications???

    Example: eCommerce Application

    Screen1: A basket with 10 LineItems
    Action1: User deletes 3 LineItems

    Screen2: A basket with only 7 LineItems
    Action2: User hits back button in browsers

    Again Screen1 (now with "invalid" state).
    Action3: User orders the basket

    So what will the user get? What he can see is a basket with 10 LineItems. But what will the application do?

    The back-button related to web applications is something like a history function. you can go back in time.
    actually, you go back to an old state of the user interface of your application.
    the problem is, that you have to keep the state of the session on the server in sync with the ui in the browser.
    Supporting the back button, like you suggest would mean, you have to keep a complete record of all transactions from a user during the whole session he interacts with the application. this means, you have to provide complete undo/redo capabilities on all actions, your application provides.

    From my point of view, this doesn't make sense for most kinds of application. It would be nice, if it would be possible, but it is a very high effort, to implement. Nobody would be willing to pay for this.

    So how should a user-friendly application deal with the back-button?

    Distinguish between transactional and non-transactional activities (browsing a shop catalog is non-transactional, ordering some products is transactional).
    When the user hits the back-button and goes back to some transactional page, give him a message and redisplay the actual state. Or disable the back-button during a transactional interaction. why not?
  48. Can anyone here could compare Echo with RedHat CCM's Bebop? http://ccm.redhat.com

    I have done some developing with CCM. It seems that Echo like to put too much HTML stuff/UI stuff on java code. Bebop is looking at going away from this. What I meant about this is that in Echo, you set the padding and color. How will I want to redisplay this on a non PC browser?

    Bebop makes use of XSL. So you edit the XSL sheets or use another style sheet. But its not perfect since there are still some HTML/design stuff in Java. Which I think Red Hat guys is looking to push to the XSL.

    How will designers work in Echo? They learn Java and study the concept of Swing? A visual editor? Still that visual editor will be Echo specific. Bebop is not that good either, well atleast you can just give the designer the XSL files. OpenACS templating is good (in terms of designer have a html like template, and programmers can do what they want with the backend code) although lacks the Java hype since its Tcl based.

    I think Echo is ok. I am just playing the other side. I also think the Docs are good.
  49. This is the Real Deal[ Go to top ]

    Our shop has been doing Java web application development for about 4 years. We've made the transition from Servlets, to JSP, to XML/XSLT, to a web framework called Expresso, and finally to Echo.
     
    We're currently working on 2 seperate projects using Echo as the GUI layer.
    One application is brand new while the other is undergoing an overhaul from the ground up (previously driven by Expresso from JCorporate, one of the few horrible open source products I've seen).
     
    The developer working on the new app's gui has been out of school for less than a year and within days was off and running with his own echo components.
     
    I'm making record time using echo to re-implement the other gui. I still can't believe how much less time I spend making strong typed reusable echo gui components as opposed to <insert_templating_engine_of_your_choice> html templating.
     
    The acceptance of Echo in our shop has been viral...almost every project is looking to echo for their gui.

    I encourage you all to take a few minutes and check out the echo tutorials , demos, and the contributed EchoPoint Components

    jd
  50. This is the Real Deal[ Go to top ]

    Did you look at wingS. How does it compare ?
  51. Re: Wings vs. Echo[ Go to top ]

    I did some testing/research on each and found these differences to be key:

    1. wingS components are actually JSP based. Dig into their source and view a .plaf file to see for yourself. Echo uses strongly typed HTML Element objects to construct new components.

    2. wingS has no concept of dialogs. A "Dialog" in wingS is just a page. Echo uses the concept of Dialogs in the more natural sense by using a popup window.

    3. while wingS may appear to have more components than Echo, check out the components on the echopoint site before making that determination. Echo still may not be the victor in this category, but the contributions definitely narrow the gap. Also, because of Echo's HTML Element library and their solid set of base components, the barrier to creating new components is much lower than with wingS.

    4. wingS has a crusty look that I couldn't get rid of. Echo renders a much cleaner UI.

    5. Echo is being actively developed. I'm not sure about wingS.

  52. Re: Wings vs. Echo[ Go to top ]

    Echo and Echo point seem to be a perfect fit for Web Application. Echo is still in Beta. Any idea when will Echo will be released.
    Thanks
    Alagan
  53. Re: Wings vs. Echo[ Go to top ]

    Have you checked out the OpenSymphony platform? - http://www.opensymphony.org

    Though this may be a little off topic, I have heard rave reviews of WebWork + SiteMesh vs Struts

    More importantly, I have a dream. That all you talented and concerned java programmers in the universe collaborate in the true spirit of Objects and produce A SOLUTION. I plead for a website or forum where we clarify the array of java technologies that germinate everyday in fields like: OR Mapping, App Servers, Development Environments, Web App Frameworks, API implementations, Web Services implementation, blah, blah, blah.

    There will be categories like:

    Definition of technology
    Comparison to other technologies
    List of available implementations
    List of features of each implementation
    Readable and Dynamic comparison of each implementation
    Relationships between each implementation
    Combining the implementations

    Let's create a single simple complete point of convergence where everything has one meaning.

    I have a dream.

    Bioye
  54. I am very impressed with what I have seen so far. I am eager to try it out. Our developers are not HTML experts and we have been forced to use 1.1-compliant applets (no Swing, no Java2D) to provide our complex interaction models. Echo would really help us out in this area.

    However, our marketing department is constantly shoving minor GUI issues in our faces. How do I affect Look-and-Feel issues? What if I want my buttons to be blue or to use a different font? Are there standard Swing-like ways of changing this? Are there HTML "templates" for the different GUI elements that can be modified? Is there a concept of CSS?

    And what about the role of designers in the absence of a GUI editor - something which seems to concern more than one person on this list?