NextApp Releases Echo 1.0, Sierra 1.0

Discussions

News: NextApp Releases Echo 1.0, Sierra 1.0

  1. NextApp Releases Echo 1.0, Sierra 1.0 (64 messages)

    Echo is an open-source platform for developing component-based, event-driven Web applications that rival the capabilities of rich-clients. Sierra, NextApp's first commercial offering for Echo, provides an array of Intranet-oriented components and a detailed sample application that demonstrates a complete Intranet.

    Visit http://www.nextapp.com.

    Press Release
    ----------------------
    NextApp ships Echo 1.0, Sierra 1.0

    Irvine, CA -- June 9, 2003 -- NextApp, Inc. (www.nextapp.com) today announced the availability of its Echo Web Application Framework, Version 1.0, and Sierra Toolkit, Version 1.0, for download.

    "Echo enables the creation of Web-based interfaces that rival the capabilities of 'rich-client' and desktop applications," said Tod Liebeck, Chief Software Architect of NextApp. "These technologies enable the development of applications which were not previously possible in a Web environment."

    Echo provides a framework for building Web-based solutions that work and act like desktop applications, from both the developer's and end-user's point-of-view. "The technology removes the developer from having to think in terms of 'page-centric' applications," said JP Fielding of Threewide Corporation, a leading developer of Internet-based real estate productivity software. "Echo provides us with a solid and extensible framework for Web development that frees us to focus on complex customer needs."

    Echo takes on all the responsibilities of rendering HTML and JavaScript for client Web browsers, and takes great steps towards making applications appear fluid and desktop-like. Developers are only required to have knowledge of Java to create Echo applications, which can then be deployed to any Java Servlet container or J2EE application server.

    "Of the myriad Web frameworks I've worked with, Echo stands alone in terms of simplicity, code reuse, and raw power," added Fielding. "Echo's introduction into our Web application development process has redefined our timelines by providing true reusability in developing stable and intuitive applications. We no longer reinvent, we just refactor and reuse."

    NextApp has harnessed the power of open-source development to bring this technology to market with extensive testing by a large and diverse user base. Developers can download Echo and build applications without charge. So far, the open-source model has been a success: Echo has been downloaded more than 20,000 times, and its development has been heavily influenced by the community offering up fixes, improvements, and ideas. "The Echo open-source project has already spawned several other projects," noted Liebeck. "The most prominent of these is EchoPoint, a community-developed library of components. It adds features such as menus, trees, and charting capabilities to the framework."

    NextApp is also providing commercial tools and support for the Echo platform. "Our first product, the 'Sierra Toolkit', offers an array of 'Intranet-ready' components. They make short work of creating applications by providing tools like recordset browsers, pre-made dialog boxes, and a common user-interface 'look&feel' for backoffice applications." said Liebeck.

    But perhaps the most impressive feature of this product is its sample application: Sierra provides a first-class suite of Intranet application modules, complete with source code, a thorough tutorial, and reference documentation. With this application, states Liebeck, "developers have a head start in building Echo-based solutions. The Sierra demonstrator app offers up the best practices for creating user interfaces on the Echo platform. It demonstrates the creation of a fully internationalized, modular, and highly maintainable solution, allowing developers to create robust and stable applications on-time and on-budget."


    About NextApp

    NextApp is dedicated to building software tools to enable the development of high-quality, reliable, and intuitive, Internet-based applications that connect and automate business processes. For more information, visit http://www.nextapp.com.

    Threaded Messages (64)

  2. Good news!
    Congratulations!
  3. I have looked around at many Web Application Frameworks and Echo is the best one I have seen.

    It has a clear stated purpoe, ie to allow complex applications to be developed for the web and it uses tightly coupled component based approach.

    This is in contrast to some many other web frameworks that are "page" based and use loosely coupled interfaces that introduce more bugs and require more testing.

    Echo is all Java based and hence the Java compiler can catch many of the coding errors because of strong type checking. Contrast this to "script" based web frameworks where a simple coding error may be discovered during testing or worse once deployed.

    Echo works something like a Swing for the web. In fact it works so well, and manages your application state so well, that you sometimes forget that you are working with a distributed web application.

    In fact I was so impressed I have helped create a large library of components for the framework called EchoPoint. (http://echopoint.sourceforge.net).

    So congratulations to NextApp on the official 1.0 release.
  4. Old stuff rereleased?[ Go to top ]

    I took the time and checked out the documentation and the tutorial.
    Actually it was very surprising to see that there are still developers
    out there that still does not learn the lesson.
    A few years ago it was a rather common approach using swing like components
    in web applications. Even huge commercial applications did it. Well,
    they are history now.
    This approach is definitely wrong. Who the hell want to build HTML pages
    in Java like this? I do not even like to do it with swing in a desktop
    application. There are many, many projects out there trying to overcome
    the painfull work of building swing panels in Java. The right way!
    Now there is Echo that goes all the way back in history. Unbelievable.
    What about template engines? Once you have worked with such a approach
    do you really want to go back to the hard work of building web pages with
    swing like components?
    IMHO working with Echo would be a punishment for me.
  5. Old stuff rereleased?[ Go to top ]

    "Who the hell want to build HTML pages
    in Java like this?"

    No one. That is not what Echo is for. It is for building an application interface the runs in the browser with out requiring Java on the client. Is it the tool for every job? No.

    Have you looked at WebForms(.Net)? Other than not having a GUI designer tool (does the current release have that) Echo is actually better, IMHO. Most hard core Java developers distain GUI builders anyway.
  6. Old stuff rereleased?[ Go to top ]

    Don't get me started on ASP.NET. Ok you did.

    Here's what the folks at ASP.NET actually did (architectually):

    1. Created an Html API which they really don't encourage you to use.
    2. Built in free binding to and from web form controls on a per request basis.
    3. Provide syntax for allowing you to define what code to execute when a particular action is taken on a control (event handling).

    That's it. Oh and they added tag syntax encouraging you to cram as much as you can into your aspx file.

    There is absolutely no abstraction of the traditional web players (session,request,response). They are still in your face and you have to deal with them. There is no statefulness, just the illusion of statefulness when asp.net magically binds your form controls. And it wouldn't be MS if it didn't have completely inconsistent API behavior, which I'm not going to get into now but trust me, it's a mess.

    To stay on topic :-), Echo solves all of these problems. I just wish I had the time to port it to .NET.
  7. I have noticed in reading this thread that there are two distinct reactions to Echo. Posters either say that Echo has proven invaluable in their shop, given them capabilities they didn't have before, and they absolutely love it (that's my response anyhow). OR, posters say that this is a bad idea, its a step in the wrong direction, the web ain't meant for this, "this is definately the wrong approach," etc.

    Here is the critical distinction: The people that are speaking positively about the product HAVE ACTUALLY USED IT, while those who deride it have never laid a hand on it, and are basically bashing it without any real understanding of Echo at all. This is typical of web forums, as much as I wish it weren't. So, for those that are arguing that Echo is a piece of crap: Put up or shut up. Have you actually used it, or are you just adverse to it on a conceptual level? The relative value of your opinion depends on the answer to that question.

    For instance, I note that Mr. Mecky has "checked out the documentation and the tutorial." This is not, by any stretch of the imagination, the same or even similar to using Echo to develop an actual application. As such, the fact that he feels this is "definately the wrong approach" carries very little weight with me. I, unlike Mr. Meckey, HAVE developed a real product, used by real users, at a real company that pays me real money to develop and maintain their applications, using Echo. As such, I can speak from a position of greater authority on the subject, and I will tell you that it works, VERY well.

    The purpose of this post is not to insult Mr. Mecky, only to point out the error in his post, and the greater error that is the whole of the negative posts on this subject.
  8. Echo - Just Another Tool[ Go to top ]

    Ironically it was the posts by some of Echo's users which started all of this. The first three posts from Echo users were about how Echo's method for building web ??? was the best available. Here are some choice quotes:

    "I have looked around at many Web Application Frameworks and Echo is the best one I have seen. It has a clear stated purpoe, ie to allow complex applications to be developed for the web and it uses tightly coupled component based approach. This is in contrast to some many other web frameworks that are "page" based and use loosely coupled interfaces that introduce more bugs and require more testing."

    "In removing us from the constraints of the "page based" model, it has allowed us to do alot of things that we really couldn't before."

    "Echo is the next generation web framework. Everybody uses at this time, page based frameworks that work quite nice such as Struts, JSF or even ASP.NET."

    Obviously these posters are really pleased, but it wasn't until after my post that anyone mentioned that Echo is geared specifically towards building a particular type of application. All three of the posters tell us that Echo is better than page-based approaches which is probably only the case in some particular circumstances. At least the last poster admitted that, well, yes, some of the other frameworks may be good.

    I think the fact that there are no examples of public internet sites written with Echo demonstrates that it is not the "best" framework available, rather that it is just another tool. It seems like it may be a decent tool for building web applications which are designed to work like desktop applications (as opposed to web applications which are designed to work like, well, web applications).

    I know we get caught up in the feeling that the tools we are using are the best but sometimes you have to realize that it is just a tool and not every tool is good for every job. When you jump right in and say "We are the best, all else is crap" you should expect to get a lot of responses from the skeptics.

    At this point I understand why Echo exists. Even with that understanding though I personally do not have a use for it.
  9. Took some time to look at both echo and echopoint and I must say so far I am impressed. Looks really simple, its enough to see how small jars are.

    Also Echopoint also includes some examples of how to use it with JSP templates. I do not know if it works well yet but if you looked at their architecture document there is nothing there that would make such integration impossible.

    Echo/ echopoint folks : Keep the good work and congratulations!

    Do not mind those that say CGI/PHP/ASP/JSP is better, they surely are for some, but then there is a lot of people that are not satisfied with the current state of Java web development and things like echo really offer lots of hope.

    Michael
  10. Echo - Just Another Tool[ Go to top ]

    I think the fact that there are no examples of public internet sites written with Echo demonstrates that it is not the "best" framework available, rather that it is just another tool.


    Echo is for application building. Not web sites. It might be part of the web site. Echo is relatively new so that would partially explain the lack of external applications. But typically things like these work from the inside out. I think way too many people who don't really know how to build applications are building them on the web. That would explain most of lack.

    >It seems like it may be a decent tool for building web applications which are designed to work like desktop applications (as opposed to web applications which are designed to work like, well, web applications).
    >

    Depends how you define web application. Many things called this are not web "applications".


    > I know we get caught up in the feeling that the tools we are using are the best but sometimes you have to realize that it is just a tool and not every tool is good for every job. When you jump right in and say "We are the best, all else is crap" you should expect to get a lot of responses from the skeptics.
    >

    True

    > At this point I understand why Echo exists. Even with that understanding though I personally do not have a use for it.
    >

    Maybe that is sad, maybe you don't do web "applications".
  11. The Back button[ Go to top ]

    Disclaimer: I haven't tried Echo, but I need to comment on this Back button issue.

    <brad>
    To avoid confusion, an Echo best practice is to load web apps into a browser window with no toolbar. It helpers alleviate some of the confusion if the back button is not there. I have seen many non Echo web applications do the same thing for the same reason. (My internet banking app does exactly that)
    </brad>

    I think you are falling prey to a sadly very common trap, but let me tell a short story first.

    Some time ago, a group of developers created this Web application that was trying hard to look like a native application. One day, I called them and told them "I just pressed BACK and my frames are all messed up, I have no idea how to restore the original content".

    "How did you press BACK?!? We deactivated it!"

    "I just pressed ALT-LEFT_ARROW, like I always do"

    "Oh... we'll have to deactivate that as well".

    Talk about not getting it.

    If it's not that, someone will drag and drop the link in a new window, or use a shortcut you didn't anticipate, or...

    Common wisdom (along with Jakob Nielsen) says: don't fight the Web metaphor. It's way too entrenched in people's minds. You will lose. If you application runs in a browser, your users will expect it to run like a Web application. Period.

    The trap you fell into is that you are facing a tough technical problem and you choose to make your users pay because it's easier to solve it this way.

    Work with the browser, not against it.

    --
    Cedric
    http://beust.com/weblog
  12. Re: The Back button[ Go to top ]

    Echo does not actually "disable" the back button. Instead, it responds to a user going backward in the history by redisplaying the current state of the application. Echo's technique does not differentiate between pressing the back button, alt-left-arrow, clicking "back" in a pulldown or context menu, or using whatever method is invented next for navigating backward in the history.

    There exists a fundamental problem when you have a stateful application that allows users to arbitrarily navigate to any previous state: In order for such an application to respond properly to the user navigating to a previous state and taking an action that is incongruent with the current state of the application, the developer must analyze every possible combination of states and user actions that could possibly occur. The number of cases increases exponentially with the number of additional possible states. As a result, developers can not and do not handle such conditions properly. We all see the result of this problem on the Web every day: applications that break when you press the back button (or go back multiple steps in the history) at the wrong moment.

    I would argue that it is far less frustrating for users to require the use of application-specific navigation than it is to attempt to "support" the back button and make users deal with the occasional or frequent failures that result.

    Best regards
    --Tod Liebeck
      NextApp, Inc.
  13. Re: The Back button[ Go to top ]

    Tod touched on a point that I think is pretty important. Often times there are big holes in the navigation for a web app. In the past I would sometimes take the lazy approach of relying on users to just hit the back button in order to "pop out" of a screen. With Echo, you have to provide navigation in your app in order to even test it (just like you would in a thick client). In my experience, uniform navigation makes for a better user experience.
  14. Re: The Back button[ Go to top ]

    Tod writes:
    Echo does not actually "disable" the back button. Instead, it responds to a user going backward in the history by redisplaying the current state of the application.


    Okay, that makes you immune to the kind of bug I was describing earlier, but I maintain that it might irritate your users.

    There exists a fundamental problem when you have a stateful application that allows users to arbitrarily navigate to any previous state: In order for such an application to respond properly to the user navigating to a previous state and taking an action that is incongruent with the current state of the application, the developer must analyze every possible combination of states and user actions that could possibly occur. The number of cases increases exponentially with the number of additional possible states.

    The Command pattern is what is traditionally used to provide unlimited (theoretically) undo. If Word and Excel can offer unlimited undo, I believe any applications on this earth can :-)

    --
    Cedric
    http://beust.com/weblog
  15. Re: The Back button[ Go to top ]


    > Okay, that makes you immune to the kind of bug I was describing earlier, but I maintain that it might irritate your users.
    >
     The company I work for (major brazilian telco) has lots of intranet applications that would fit nicely within Echo's structure. Actually the applications are designed so users won't need the back button, ever. We never received any complaint about that, since they get the feeling they are working on an application (which they actually are), instead on simply navigating through pages. That's the beauty of it all: users tend to forget they are browsing, and accept the web page as an application, and the system guides them through their work. No need to press back of forward.
  16. I work with Siebel 7 now: the browser back button does not work either. Siebel has instead its own back button widget inside the browser frame. They sold quite a bit of software, so surely back button problem is not that critical.

    I acknowledge that not having the back button is not an ideal situation, but I am sure that any project steering commitee would exchange few man-weeks of pixel sweating for lack of back button ;-).
  17. Re: The Back button[ Go to top ]

    The Command pattern is what is traditionally used to provide unlimited

    > (theoretically) undo. If Word and Excel can offer unlimited undo, I believe
    > any applications on this earth can :-)
    >
    > --
    > Cedric
    > http://beust.com/weblog

    Hrmmm... Are "Back" and "Undo" really the same thing in a user's mind?

    IMHO, very rarely. (By the way, what happens in Excel if the user clicks on "Undo" after executing a macro that updates an external database? Somewhat limited in what it can undo, huh? Oh well.)

    In my experience, the most common use of the browser's "Back" button is navigational. For example, the user simply wants to go back to view a previous page... perhaps a list of items to work on after performing an action on one of the items.

    Sadly, when deploying a web application for use in a browser, the users are drawn to the browser's buttons, hot keys, or shortcuts regardless of the application's navigational components. At some point, you have to deal with this limitation of your deployment environment in a way that ensures that the application and the application's data will not be jeopardized.

    It would seem that Echo has done an admirable job of implementing a solution.

    Sure... the user's experience is important... Does the "Back" button perform the expected action? It should when appropriate. However, it's not the most important issue. (Great... now I'm going to get flames from all of the HCI/Usability folks. :)

    BTW, there are many applications where implementing unlimited undo is not possible... and many more where it is impractical. You should get out more. :)

    Later.
  18. George Gochaleishvili[ Go to top ]

    I just discovered Echo and it looked quite powerfull for me, at least for developing a little and meium sized applications. It looks especially powerfull for those who is familiat with awt. Although for me, who worked for a wile in (D)HTML/JSP environment it was unusual (it's some hard to implement almost every design view), but if mastered, Echo could be great solution for the pure java developers.
    Now i'm working on some demo application to implement several custom developed widgets: Tabs, Tables, Menus and so on... so far so good:)
  19. well obviously someone who thinks the framework is conceptualy flawed wouldn't bother to spend the time to use in in practice. so this is kind of a silly response imho
  20. Maybe it is. But what the poster is saying is knowing is better than thinking. And not having used it coupled with the fact that it is being used successfully, it is difficult to take the thoughts seriously.

    Having used JSP/ASP and Taglibs I know, for applications, it knocks the socks off the competition. Perfect? No. I think Tapestry is great too but it solves a different problem and is useful where Echo isn't. Or maybe in combo with it.
  21. Echo IS suited to some applications[ Go to top ]

    Having used JSP/ASP and Taglibs I know, for applications, it knocks the socks

    >off the competition.

    * STRONGLY vs WEAKLY TYPED LANGUAGES

    I think its fair to think of developers as being divided into two camps. Those who like "strongly typed programming languages" and those that like the flexibility of "weakly typed" scripting languages.

    Echo is a web framework for the former and ASP/JSP/PHP/PERL/... are web frameworks for the latter.

    Personally I find "scripting languages" extrememly frustrating because you cannot have as much confidence that they will "work" when you code them. You must "execute" every codepath to see if they will "fall over" for the simplest typing error.

    Whereas with a strongly type language such as Java you can have more confidence that a certain peice of code will not fail because of simple typing errors. (You do of course still have to test as much as you can but IMO its testing application logic not your typing skills and hence more productive).

    So to me as a developer who loves a good 3GL, Echo gives me more confidence in the web application produced.

    * SUITED WEB APPLICATIONS

    Echo is certainly more suited to a certain types of application. If you have a lot of data input, need a lot of dynamic info, need to manage where is user is within the application at any time and want to present only the latest information to them , then Echo is a very suitable and capable framework.

    Imagine a hotel/airline booking web application or a stock trading web application. You cannot use cached pages because the information you displayed before may no longer be current.

    It doesnt make sense to try and booking a flight to a page that was displayed 1 hour ago (or even one minute ago) since it might be already booked. So in a traditional web application you would mark the page as expires 0 and "no-cache" and then try and have you application present the latest information. Echo definitely suits these style of applications.

    Whereas developing another type of application, such as personal web blog or a HR training manual may not be best done in Echo.

    Having said that, EchoPoint has two features in it that add precise HTML page layout and integration to traditional HTML/JSP pages within an Edco application.

    There is a HTMLTemplatePanel and JSPTemplatePanel that allows you to "include" pure HTML or JSP pages inside an Echo Panel container. Within this HTML you can use special markup to indicate that other "Echo" components be placed inside this HTML markup.

    Both the EchoPoint poker and bank example use this technique.

    http://echopoint.ascendancy.org.uk/echopointbank
    http://echopoint.ascendancy.org.uk/echopointpoker

    The JSP panel, it has a taglib feature that allows you to place Echo component "beans" into the JSP and have them rendered inside the JSP markup. And of course you can use the normal JSP session and request bean mechanims to your hearts content.

    So Echo does have some integration to what may be called traditional web techniques.

    * BACK BUTTON

    And finally on the question of the back button, Echo does take control of it. While I agree that this may be bit counter intuitive to some users, its done for a very good reason.

    Imagine a ordering confirmation step. You may have a basket of goods that you need to "confirm" the order. You press confirm! What does BACK mean now?

    Most web apps code around this by performing a POST and then printing the ubiquitous "DO NOT PRESS THE BACK BUTTON" on the following order confirmed page page.

    Echo has a different approach in that the client and server state is always tried to be synchronised and when you are on the post order confirmation step you are on it, regardless of back button pressing.

    To avoid confusion, an Echo best practice is to load web apps into a browser window with no toolbar. It helpers alleviate some of the confusion if the back button is not there. I have seen many non Echo web applications do the same thing for the same reason. (My internet banking app does exactly that)
  22. you are right but....[ Go to top ]

    Since you have mentioned my name I thought I should reply.
    You are right that someone should first take a deep look
    at something and work with it before start blaming it.
    But in this case it is not necessary. I have done one huge
    project with a CMS system (which was the market leader at that
    time) with exactly the same approach. It was horrible.
    What about the thesis of separating the java code and the HTML
    generating code? Why does Echo do not support this? There are
    ways to handle this (JSP, XML/XSL, template engines and even more)
    that have prooven to be a good approach rather then Java only
    mode.
    I must admit that I have never worked with Echo but with something
    similiar (regarding to HTML generation).
    Is this enough for you to accept my comments?
  23. Re: you are right but....[ Go to top ]

    I must admit that I have never worked with Echo but with something

    > similiar (regarding to HTML generation).
    > Is this enough for you to accept my comments?

    What I'm reading here is that you believe Echo is a bad idea because you believe that it is just like Framework X, which you have had a very negative experience with. I'm not aware of anything that works "with exactly the same approach [as Echo]". Could you please provide the name of the framework on whose merits you are evaluating Echo?
  24. There are few products that I'll offer a rave review for, but Echo happens to be one of them. My shop has tried a variety of frameworks (which shall remain nameless), and until now has been almost universally disapointed. Echo has, for me proven to be an exceptionally powerfull tool. In removing us from the constraints of the "page based" model, it has allowed us to do alot of things that we really couldn't before. Most telling is user acceptance. Most of the applications we build have doctors as the end user--perhaps the most technically inept breed of people on the planet. It has been my experience that M.D. end users are always unenthused about apps, and somwhat rightly so, given that most medical/legal apps are pretty mundane and clumsy. So far, with our Echo based apps, this hasnt proven true--we've gotten a lot of compliments from the users on the way our new stuff works from both the docs and the MIS staff. Puls, so far, echo has been bulletproof. I have yet to see a deployed app crash. In short, I'm really pleased--this is hands down the best framework I've seen yet.
  25. Echo is the next generation web framework. Everybody uses at this time, page based frameworks that work quite nice such as Struts, JSF or even ASP.NET. But they have some drawbacks, however. You write too much code, you must know HTML, JavaScript, JSP etc. Every page is reloaded each time a request is made, is hard to build reach user interfaces, you always have to be carefull about request, session or application parameters.

    Echo changes all that. Is component based, is 100% OOP, is very similar to AWT/Swing, is event driven. Some of the things that I liked most about it were, the fact that you can make a component, and that put it wherever you want, without being concerned about request parameters and other things. The second is the event/listener mechanism which makes development FAR easier. Not being page based, is EXTREMELY fast, some of my clients could not actually see the difference between a normal desktop application and the one written with echo.

    Congratulations Tod and Brad and others,
    Dan
  26. Real World[ Go to top ]

    Looks like a very interesting and powerful product. Are there any real world applications out there running on Echo.
  27. Should we use this[ Go to top ]

    We want to build a form based application with tabs over the web.

    Struts could be one way to go but I have not been able to get on the Struts bandwagon yet.

    Evaluated echo and echopoint a month or so back. Echopoint is very good and has good scope for improvement. Echo however seemed like if you wanted to change you UI a lot, it might now be a good idea to go with echo.

    Has anyone felt this as well. Has anyone used this for commercial projects. Does the extensive client - server conversation hurt/help?

    TP.
  28. Re: Should we use this[ Go to top ]

    I've used Echo (and Echopoint) sucessfully in two (medium sized) intranet applications (sorry, no public URLs). It's really a powerful framework and I will consider it for every non-design heavy site in any of my future projects.

    Two of my colleagues, only familiar with Swing, learned Echo in only a single day! It's so much more convenient than any page-based approach. Try it.
  29. Echo is a very reliable and robust GUI framework. If you are building web applications and are tired of all those page centric frameworks out their then take a look at Echo.

    It offers a Swing/AWT like api, is totaly OO based, know html programming required, great widget/component repository (aka echopoint), and gives you good cross browser support.

    Once you use Echo you will wonder how you ever put up with those other page centric frameworks.
  30. I Don't Get It[ Go to top ]

    Full disclosure: I develop JPublish, another web application framework.

    Now that that is out of the way I have to say that I just don't understand Echo, nor any of the other web application frameworks which use an AWT/Swing programming model.

    Why would you want to build web applications this way? How do your graphic designers contribute? Do you need to compile and redploy the application any time you make a change? Is it really better to build web sites where everything is written in Java? Is the web a replacement for desktop applications?

    What does Echo really give you? The web is based on pages. Hyperlinks take you from page to page. Echo tries to get around this with JavaScript and a programming model which is similar to desktop applications, but in reality you are still going from page to page. Trying to go around the way in which the web works is just going to cause trouble. Back/forward buttons don't work. Linking is impractical at best and impossible at worst.

    Let's step back for a second and look at the business objectives set forth in the Echo whitepaper:

    * Increase user-acceptance of Web-based applications.

    Most users don't seem to mind the page-based web, in fact most users don't even know what that means. As long as it works as expected then they are happy.

    * Increase capabilities of Web-based applications.

    As long as you are ok with the limitations of the object model required by Echo.

    * Improve quality, reliability and security.

    Just looking at the tutorial applications demonstrates that they have failed on at least item one and two. The application does not look or perform any better than a page-based solution, the back and forward buttons don't work so their goes reliability. I can't speak for security.

    * Decrease developer training costs

    Well, as long as you only have Java developers. In a mixed environment you are going to have serious problems.

    * Decrease development time.

    How are you decreasing development time. You have to recompile and redeploy your application in order to see any changes.

    * Decrease application support costs.

    Please, explain how Echo provides this? Every minor change now requires expensive Java developers in order to implement, even simple text changes.

    Now let's look at their technical goals:

    * Provide an object-oriented and event-driven framework.

    If you really see a need for event-driven frameworks, then there are other frameworks which do this but which do not suffer from the problems of Echo such as the inability for designers to be involved.

    * Require no developer knowledge of HTML, HTTP, and/or JavaScript.

    Instead it requires your developers to have graphic design skills and sensibility. I think it is easier for developers to learn a bit of HTML and JavaScript rather than require your designers to be Java developers.

    * Allow precise control of application appearance.

    Uh, what? You can only control properties which are known to your components - thus it is only as precise as your components allow.

    * Support applications with multiple windows and frames.

    This can be accomplished easily with any of the existing frameworks and a very small amount of JavaScript. Of course it begs the question on whether or not web applications should be opening new windows or not.

    * Minimize server load and network traffic.

    You still send requests each time an event occurs - how is this minimizing traffic?

    * Actively synchronize client browser state with application state.

    What do you mean by this? How does echo differ from any other framework in this sense?

    * Operate on HTML4/JavaScript1.3 compliant browsers, including Internet Explorer 5.5, Mozilla, and Mozilla-based browsers, e.g. Netscape 6.2.1.

    As can any framework.

    * Require no plug-ins, Applets, or ActiveX controls.

    As other frameworks.

    * Deploy applications to any Java Servlet Container (versions 2.2 and higher).

    As other frameworks.

    Perhaps I am dense or biased or both, but I just can't see what benefits echo provides. On the other hand I can see several glaring and obvious down sides. As always you be the judge.
  31. I Don't Get It[ Go to top ]

    Disclaimer : I havent worked with Echo or JPublish -- I am struts lifer!

    For web based corporate applications , I dont see why we need the page model. Hyperlinks are unnecessary in such applications as you typically have menu bars and pop-up menus, a frigging javascript nightmare, and people use it as they would any normal desktop application.

    My experience with creating application navigation with Javasript/HTML in JSPs has been horrific. Simlple things like drag-n-drop, selections, trees, tree tables and editable tables are a nightmare with HTML and Javascript!

    So maybe I am biased but I am beginning to believe that sophisticated web based applications are easier to develop using applets or WebStart. And your users get a much smoother experience.
  32. I Don't Get It[ Go to top ]

    I as a struts guy like you once - "I feel your pain". Try Echo you will like it.

    > Disclaimer : I havent worked with Echo or JPublish -- I am struts lifer!
    >
    > For web based corporate applications , I dont see why we need the page model. Hyperlinks are unnecessary in such applications as you typically have menu bars and pop-up menus, a frigging javascript nightmare, and people use it as they would any normal desktop application.
    >
    > My experience with creating application navigation with Javasript/HTML in JSPs has been horrific. Simlple things like drag-n-drop, selections, trees, tree tables and editable tables are a nightmare with HTML and Javascript!
    >
    > So maybe I am biased but I am beginning to believe that sophisticated web based applications are easier to develop using applets or WebStart. And your users get a much smoother experience.
  33. I Don't Get It[ Go to top ]

    Echo is for building web applications. Just like MFC is used for building Windows apps or X/Motif is for building unix apps. Publishing dynamic content on a website or putting up a form/submit page is a whole other world.

    Building a business application with complex state using a page centric model is not as efficient as using the traditional rich/thick client model. Any developer that has experience both will tell you that. Echo makes state management transparent and allows the traditional rich client programming model like MFC/Motif/Swing available to the web.

    If you want to get information or graphic designers involved then that is really a matter of tools support and integration. All the major frameworks have this challenge to some degree or another.
  34. I Don't Get It[ Go to top ]

    I can see the appeal of this kind of development. I think the big advantage is reducing some of the mental gymnastics of state management that are necessary with a typical web application framework.

    I can see, potentially, that Echo might give an advantage in getting functionality in place. I haven't used it yet, though I'd have concerns about scalability and clustering (I really need to understand what data is stored in the client, and what in the server).

    I think there might be room in the world for page oriented solutions (JPublish and Tapestry, for example) and hybrid solutions like Echo. Certainly if I had to choose between Echo and, say, JSF it would be Echo.

    I know for a fact that one potential client (a company I taught a Tapestry class for) eventually chose Echo over Tapestry because visual concerns were less important to them getting lots of functionality out fast. That simply raises the bar for Tapestry a bit ... something to work on in 3.1.
  35. I Don't Get It[ Go to top ]

    Now that that is out of the way I have to say that I just don't understand Echo, nor any of the other web application frameworks which use an AWT/Swing programming model.


    One key point to differentiate is that Echo has been built for designing web "applications" - bringing powerful, feature rich web "applications" to the client side browser.

    If you are not building a web "application", but are building a dynamic, content rich site - then Echo may not be for you. These projects usually involve the interation of a large proportion of non-development personnel.

    However, if you have to build a internet or intranet application with extensive functionality, user input, and interaction, there is no better way than Echo. Such projects do not usually have much graphic design interaction.

    >
    > What does Echo really give you? The web is based on pages. Hyperlinks take you from page to page. Echo tries to get around this with JavaScript and a programming model which is similar to desktop applications, but in reality you are still going from page to page. Trying to go around the way in which the web works is just going to cause trouble. Back/forward buttons don't work. Linking is impractical at best and impossible at worst.

    Echo designed web applications are not about "linking" - how many times have you filled out a form on several pages or interacted with a site where the words "do not hit the back button" have been found. In cases where you are in an "application" on the web, linking is not the issue - if you are in a web site that is content rich, then linking is important, but it is not the case with feature rich web "applications".

    >
    > Let's step back for a second and look at the business objectives set forth in the Echo whitepaper:
    >
    > * Increase capabilities of Web-based applications.
    >
    > As long as you are ok with the limitations of the object model required by Echo.

    There are virtually no limitations in the object model provided by echo - if there is not a component that fits the bill, create your own component and accompanying component peers. There are also other projects that are assisting the echo community by creating custom echo components (http://sourceforge.net/projects/echopoint/).

    >
    > * Improve quality, reliability and security.
    >
    > Just looking at the tutorial applications demonstrates that they have failed on at least item one and two. The application does not look or perform any better than a page-based solution, the back and forward buttons don't work so their goes reliability. I can't speak for security.

    Reliability - many web "applications" have the RELIABLE method of warning the user "do not hit refresh or back." If the user does, what happens - their state is lost. Echo synchronizes the state of the browser and the server for the user's session, so the "application" developer does not have to worry about state, b/c Echo handles the details - the client can't get out of state!

    Quality - from a development point of view, you can unit test your echo applications without having to deploy them to a servlet container. This includes unit testing the UI components and screens - you can't do this in most other application frameworks because the UI is generated by templates/etc - then you have to resort to using testing methods like HttpUnit, while albeit powerful, are not as easy or flexible as unit testing at the code level.

    >
    > * Decrease development time.
    >
    > How are you decreasing development time. You have to recompile and redeploy your application in order to see any changes.

    In most web "applications" (not content rich web sites), making changes to functionality (not text) would require the code to be compiled and deployed whether or not you use echo. If you are working in an environment where tomcat reloads and your IDE compiles automatically, then there is minimal lag between the time you change the functionality in the code and the time you see the results - but then you can also unit test your new features so you do not have to redeploy to make sure they work anyways...

    > * Decrease application support costs.
    >
    > Please, explain how Echo provides this? Every minor change now requires expensive Java developers in order to implement, even simple text changes.

    Most changes to web "applications" include source changes anyways - if your site is content rich and not feature rich, don't use echo (am I repeating myself on this point :)

    > Now let's look at their technical goals:
    >
    > * Provide an object-oriented and event-driven framework.
    >
    > If you really see a need for event-driven frameworks, then there are other frameworks which do this but which do not suffer from the problems of Echo such as the inability for designers to be involved.

    What better way to handle an event than simply saying:

    button.addActionListener (
       new ActionListener(){
          public void actionPerformed(ActionEvent ae){
             // method call here!
          }
       });

    > * Allow precise control of application appearance.
    >
    > Uh, what? You can only control properties which are known to your components - thus it is only as precise as your components allow.

    Echo allows you to build your own components if the core components don't fit your needs. However, we have built three production echo applications used internally and by end clients and we haven't needed to built a single customly rendered component yet.

    >
    > * Minimize server load and network traffic.
    >
    > You still send requests each time an event occurs - how is this minimizing traffic?
    >
    > * Actively synchronize client browser state with application state.
    >
    > What do you mean by this? How does echo differ from any other framework in this sense?

    If the user clicks the back button or hits refresh - or their connection dies in mid-session, the state is maintained on the server. If the server goes down and comes back up, the state is serialized on the server. When the user returns to the page or refreshes, the user is back at exactly the point in the "application" where they were when they started. Again, refer to the "please do not click refresh" messages on many existing web applications - echo doesn't depend on the user to read these messages but takes care of synchronization for you.

    >
    > * Operate on HTML4/JavaScript1.3 compliant browsers, including Internet Explorer 5.5, Mozilla, and Mozilla-based browsers, e.g. Netscape 6.2.1.
    >
    > As can any framework.

    Great!

    >
    > * Require no plug-ins, Applets, or ActiveX controls.
    >
    > As other frameworks.
    >

    Great!

    > * Deploy applications to any Java Servlet Container (versions 2.2 and higher).
    >
    > As other frameworks.
    >

    Great!

    ---

    In conclusion - echo makes building feature rich web "applications" easy and powerful. I would not use echo to build a large site which includes primarily content. However, we build web applications for the real estate industry that are not content rich but feature rich - user interaction/input rich. Echo fits the bill.

    John Rayburn
  36. I Don't Get It[ Go to top ]

    I agree with the root poster of "I Don't Get It". This seems like it is trying to hack on something to the web that should not be. The web is not a good application development framework. It sounds as if Echo is targetted at internal line-of-business applications (the guy stresses this a LOT in his response), and I have to say that if you are make a line-of-business application that is not available to the public, you SHOULD BE USING CLIENT-SIDE-JAVA and WEBSTART.

    PLEASE, think of the users you are subjecting to some retarded, slow, page refreshing, network hogging web application? Why would you make your poor users download the entire UI every time they click a button or a menu? THIS IS WHAT CLIENT-SIDE JAVA IS FOR. Not everything has to be a web-app. It's great that we have stuff like Servlets and Struts and JSP for making complicated public websites that serve content, and it's creat that we have forms in HTML so we can give public users some functionality, but I feel really sorry for some business user who has to sit there in their browser waiting for pages to refresh when they are trying to do data entry or generate reports.

    With WebStart you eliminate the main disadvantage of the Desktop Application Proper, which is distribution. With EJB, this is a non-issue. So, with WebStart and J2EE, you can give users a real Desktop app (that looks just like all their others thanks to JDK1.4.2) that updates automatically every time they run it, doesn't need nearly the bandwidth, doesn't rely on flaky technologies like JavaScript and poor programming models like stateless HTTP. Why hack event-driven-MVC architecture on top of that?
  37. Re: I Don't Get It[ Go to top ]

    So, with WebStart and J2EE, you can give users a real Desktop app (that looks just like all their others thanks to JDK1.4.2) that updates automatically every time they run it, doesn't need nearly the bandwidth, doesn't rely on flaky technologies like JavaScript and poor programming models like stateless HTTP. Why hack event-driven-MVC architecture on top of that?


    Ever tried to justify a deployment of Webstart for your application on 5000 client machines?
  38. Ever try...[ Go to top ]

    Ever try to deploy a new application on millions of machines using a network that no one is familiar with?

    People have web browsers on their machines because they saw the value. Even before Microsoft "discovered" the internet, millions of people installed Netscape on their computer (and upgraded frequently) because it enabled them to do something they found useful. This included more than just reading text and filling out simple forms.

    If there is real value, people will install it. They will pay for the hardware, bandwidth, software, support, and training to use it. But for 99%, people did not see see the value in client-based java applications. The page-based web was "good enough"

    Why? Not because the browser was ubiquitous; it became so because of its value. The value was in the speed and reliability of application development. Most applications are relatively simple. The complexity lies in either handling the GUI or handling the network. The browser/webserver combo completely eliminated this. Anyone (not just the computer literate) can whip together an HTML form and have it sent to a server.

    Sessions and transactions have become slightly more complex due to HTTP's statelessness, but that statelessness comes with two other benefits that plagued the client-server network: reliability, and bandwidth savings. A 5000 client -server network is a monster to deal with, and sucks up enormous resources. You'll be lucky to keep downtime to less than 5%. But a 5000 client HTTP network with 90% of the functionatily at 110% of the effort (minus 90% of GUI work and 99.9% of network code) is a piece of cake.

    Java client-server afficionados need to stop reciting the tripe about the ubiquitous browser and realize the secret of it's success. HTML & HTTP are why everyone has a browser. The architecture is superior, and it's why everyone hasn't rushed out to make sure they have a 1.4 JRE with Swing.
  39. I Don't Get It[ Go to top ]

    Dave C Wrote:

    > I agree with the root poster of "I Don't Get It". This seems like it is trying to hack on something to the web that should not be. The web is not a good application development framework. It sounds as if Echo is targetted at internal line-of-business applications (the guy stresses this a LOT in his response), and I have to say that if you are make a line-of-business application that is not available to the public, you SHOULD BE USING CLIENT-SIDE-JAVA and WEBSTART.
    ----------------

    Client-side Java and WebStart are very often not an option. I personally think they are great ideas and have their place, but they become quite useless in the all too common network environments where you are not allowed to install Java on the client.

    ----------------
    >
    > PLEASE, think of the users you are subjecting to some retarded, slow, page refreshing, network hogging web application? Why would you make your poor users download the entire UI every time they click a button or a menu? THIS IS WHAT CLIENT-SIDE JAVA IS FOR. Not everything has to be a web-app. It's great that we have stuff like Servlets and Struts and JSP for making complicated public websites that serve content, and it's creat that we have forms in HTML so we can give public users some functionality, but I feel really sorry for some business user who has to sit there in their browser waiting for pages to refresh when they are trying to do data entry or generate reports.
    >
    > With WebStart you eliminate the main disadvantage of the Desktop Application Proper, which is distribution. With EJB, this is a non-issue. So, with WebStart and J2EE, you can give users a real Desktop app (that looks just like all their others thanks to JDK1.4.2) that updates automatically every time they run it, doesn't need nearly the bandwidth, doesn't rely on flaky technologies like JavaScript and poor programming models like stateless HTTP. Why hack event-driven-MVC architecture on top of that?

    ---------------

    In response, let me first get this out of the way: JavaScript is not "flaky". The deficiency in JavaScript is not related to instability, but rather in the underlying difficulty of developing solid cross-platform code. As it turns out, if you write clean, modular, object-oriented JavaScript code, based on the specification, and test it with the big 3 browsers (IE, Mozilla, and Opera), the technology is anything but flaky.

    On to the point... There is a great deal of capability in a Web browser as an application platform. The combination of (D)HTML/CSS and JavaScript provide a reasonably complete (although not at all developer-friendly) toolset for buidling a user interface. With Echo, we've created technology that renders a remote view of a server-side application into the language of the browser. The developer uses a Swing-like UI model to create applications, and Echo takes care of rendering HTML, JavaScript, and processing input from the client.

    Echo's client-server interaction process is significantly different from those of the Swing-like model frameworks that have preceded it: Echo has a client-side engine (written in clean, modular, object-oriented JavaScript), that synchronizes state between client and server. This "client engine" uses a non-visible "controller frame" in each browser window that functions as a communication channel with the server. This channel is used by the client engine to send user input to the server for processing, and retrieve directives from the server to update the user's view of the application to reflect server side changes. These client-server interactions are done in batches (when the user takes an action that may require server-side processing) to keep bandwidth usage to a minimum. Using this technology, we are able to achieve a far more fluid user experience than was previously possible with a Web-based client. It makes multi-window, multi-frameset applications possible, and minimizes network utilization by exchanging only updated information. For a more thorough explanation of how this all works, please see http://www.nextapp.com/products/echo/doc/hltov/interaction.html

    To the naysayers, I cannot suggest enough that you try downloading the "Sierra Intranet Applications Demonstrator" application and deploying it to a servlet container. The Echo Tutorial, on the other hand, makes a very poor example for evaluation purposes; its only intent is to educate. The Demonstrator application is provided in the Sierra Free Trial, available for download here:

    http://www.nextapp.com/products/sierra/trial

    Best regards
    --Tod Liebeck
      NextApp, Inc.
  40. Client-side Java and WebStart are very often not an option.


    Not really! I grant you web start is not always an option but java applet is very much one. Network environments that ban Java are rare in my experience and wherever java is banned browser so is javascript and activeX!

    I have worked in projects that required Integrating javascript + css + DHTML in a JSP and this took ages to implement. In hindsight, all that could have been accomplished in an applet faster and easier. I understand you can do this better with Echo but I am not sure you have sophiptcated user controls like Java widgets and the ability to extend them seamlessly.

    Speed : having worked with creating a listgrid and tree in javascript + css + DHTML , this stuff is painfully slow to draw on the browser. And with large volumes of data, this is absolutely too slow to be usable!! An applet is so much better and faster rendering large volumes of data that any CSS+DHTML widget.

    Java applets got a bad rap when they first came out but I think this reputation is wholly undeserved now.
  41. Java applets got a bad rap when they first came out but I think this reputation is wholly undeserved now.


    Java applets is where it all started. Applets really on got a bad rap when Microsoft started shipping an incompatible JVM.
  42. Re: I Don't Get It[ Go to top ]

    Why would you want to build web applications this way? How do your graphic designers contribute?


    Usuall, there is no graphics designer (if we're talking about a person that produces PNG slices and everything) involved in an "application". Of course, a designer can do the overall GUI look and feel (which components should be used on which screen for what purpose). You don't need page-based, exact pixels layout in an Intranet application.

    >>> Most users don't seem to mind the page-based web, in fact most users don't even know what that means. As long as it works as expected then they are happy.

    And they are even more happy if it behaves and feels like their usual desktop environment and applications. This is what Echo is for. Not for marketing websites.


    >>> The application does not look or perform any better than a page-based solution, the back and forward buttons don't work so their goes reliability.

    You don't have a back and forward button in Word? It's not needed if you are not using "pages". The users sees no pages. On the other hand: Most intranet applications I've made (quite a few) use a popup window without any browser controls, even with the classical page template approach. Its so much easier to design an application without taking care of back/forward (even with a framework that providing a statemachine). It's not needed, keep it as simple as possible.

    >>> * Decrease application support costs. Please, explain how Echo provides this? Every minor change now requires expensive Java developers in order to implement, even simple text changes.

    You get Java developers knowing Swing by the dozen these days. I'd rather have a Java developer modifying type-safe components than any web developer hacking along in an obscure template language.

    >>> * Require no developer knowledge of HTML, HTTP, and/or JavaScript. Instead it requires your developers to have graphic design skills and sensibility

    No, thats where you can still use your graphics designer for. He should be able to draw a UI statechart diagram and decide what components should be placed where on which screen. This is not the job of a software developer. Implementing the statemachine is.

    I think most of the benefits of Echo show when you stop seeing it as an alternative to Struts, JPublish or any of the other (25? 26?) Java page-centric web frameworks. It has a different purpose and a different place, and rightfully so. Check it out next time you're doing an Intranet application, e.g. an Inventory/Warehouse management solution or a CRM application.

    It's a replacement for Swing thin-clients, and we really need that. There's no way to deploy a current JRE in a big company for a single application requiring Swing, but everyone has a browser.

    Having said that: Consider using Struts, JPublish, Tapestry or any of the other page-centric frameworks for a public marketing website.
  43. Back It Up With Examples[ Go to top ]

    "And they are even more happy if it behaves and feels like their usual desktop environment and applications. This is what Echo is for. Not for marketing websites."

    No offense but there is nothing in the demos which make me get the feeling of using a desktop application. Would you mind pointing out an example of something built with Echo which does feel like a desktop application?

    And don't assume that page based frameworks are only for marketing web sites.
  44. Re: Back It Up With Examples[ Go to top ]

    No offense but there is nothing in the demos which make me get the feeling of using a desktop application. Would you mind pointing out an example of something built with Echo which does feel like a desktop application?


    Sorry, all my Echo applications are in-house and/or Intranet applications, I can't give any URLs. But why not test-drive the Sierra demos?

    I want to stress this point some more: Echo (and other event-driven frameworks, like Millstone) has its place: Intranet applications that should be immediately available to a large number of client machines without any software installation on client side. Development should happen as with Swing (no web developers), Users should have the feeling they are using a local application. I know (i've been doing this stuff for more than 8 years now) that you can never have the same look/feel as with a real Swing application or even a native one (no drag&drop, context sensitive menues, ...), but having some nice Javascript functions wrapped in a convenient (tested and working in all common browsers!) component model is like a dream come true for developers in that field.

    BTW, you can use Echo components within an HTML page template (to get more control over the design) with the appropriate container/component (delievered with Echopoint), which is quite similar to what JSF should be. I don't know if JSF compatibility is somewhere on the Echo roadmap, though.
  45. Re: Back It Up With Examples[ Go to top ]

    "And they are even more happy if it behaves and feels like their usual desktop environment and applications. This is what Echo is for. Not for marketing websites."

    >
    > No offense but there is nothing in the demos which make me get the feeling of using a desktop application. Would you mind pointing out an example of something built with Echo which does feel like a desktop application?
    >
    > And don't assume that page based frameworks are only for marketing web sites.

    The "Sierra Intranet Applications Demonstrator" provides an example of a "desktop-like" application. The application is provided as part of the "Sierra Free Trial" download as a deployable WAR file. Please feel free to contact NextApp if you have any questions about the demonstrator app.

    The Sierra Free Trial may be obtained by visiting:
    http://www.nextapp.com/products/sierra/trial

    Best regards
    --Tod Liebeck
      NextApp, Inc.
  46. Re: Back It Up With Examples[ Go to top ]

    No examples on the internet. OK.

    As far as saying the other frameworks are good for marketing type websites but not for building applications you are simply wrong.

    It will take a lot to convince me that an event driven framework with just java is best for the web.

    The web is a request/response beast. Commands map to this very well. request comes in, execute a command, send response(page). Why try to make it anything else.

    tx

    Matt
  47. Re: Back It Up With Examples[ Go to top ]

    * Minimize server load and network traffic.

    Could you please explain how and why the loading and traffic will be minimized?
    As seem to me you on the background you still use HTTP requests, is not it?

    Thank you,
     Dmitry Namiot
     Coldbeans
  48. I Don't Get It (Followup)[ Go to top ]

    The responses to my "I Don't Get It" have clarified why Echo exists, however I think that there is this feeling amongst Echo users that web applications are different than web sites which is something that I don't agree with. Then again I develop mostly sites which are directed to consumers and design and appearance does matter. And I'm not talking about marketing sites but sites which are a mix between content and functionality. FWIW, I don't want to have to craft a whole new set of components just to get my web application/site to look the way I want.

    Tthe responses indicate that Echo is designed to be a HTML/Javascript based replacement for applets and WebStart applications. I would love to see a real site built on Echo in action to get a feeling for what it is really capable of as the tutorials just don't do anything for me.
  49. I Don't Get It (Followup)[ Go to top ]

    The 3 major reasons you would use Echo is strong language type checking (provided by the Java compiler), re-useable and well tested components and simplified web state management.

    Quoting off your JPublish web site:

    >>JPublish is loosely based on the FreeEnergy methodology. FreeEnergy was
    >>originally created by Leon Atkinson and others as described in his self-
    >>authored article Harnessing PHP's FreeEnergy ..... Essentially the FreeEnergy
    >>methodology was designed to handle page
    >>development in an object oriented fashion so that common objects could be
    >>reused.

    Therefore you are aspiring to the same development goals. Re-useable, well tested components that generate HTML, to alleviate some of the mind numbing web plumbing work and allow you to concentrate on application logic.

    In the Free Enery article :

       http://www.zend.com/zend/art/free-energy.php

    it talks a lot about including code, re-using it, layout of the pages, and handling actions.

    I propose that Echo and Java is one of the best ways out there to achieve these developments ends.


    > I would love to see a real site built on Echo in action to get a feeling for what it is really capable of as the tutorials just don't do anything for me.

    Two EchoPoint demonstrations are available right now at :

    http://echopoint.ascendancy.org.uk/echopointbank
    http://echopoint.ascendancy.org.uk/echopointpoker

    The third, which is a walk-through demo of all EchoPoint components, is currently off-line but the person who kindly hosts the demo s working to get it back online soon.

    http://echopoint.ascendancy.org.uk/echopointdemo

    Of course you can download them, install them unto a Servlet 2.2 engine like Tomcat and play around to your hearts content.
  50. I Don't Get It (Followup)[ Go to top ]

    Thanks for the links Brad. The EchoPoint web site does a much better job of demonistrating where Echo should and should not be used.
  51. Re: I Don't Get It (Followup)[ Go to top ]

    I don't understand this differentiation between "applications" and applications, as if most current web apps aren't "true applications" because they don't use a AWT/Swing like framework. Pah-leez. Do yourselves a favor and cut the sobery.

    Echo strikes me as a framework aimed at AWT/Swing developers who need to develop web applications, but don't want to learn HTML, DHTML and JavaScript, or how to work with HTTP's stateless nature. Reminds me of SilverStream's first entry into the app server market. Their web development tool was of the "visual markup" variety, where the developer would drag and drop forms, fields, buttons, labels, etc, and then functionality would be coded in event handlers much like Visual Basic or PowerBuilder. It was very cumbersome, temperamental and difficult to get the layout precisely as desired.

    J
  52. Re: I Don't Get It (Followup)[ Go to top ]

    That's snobery.
  53. Try again[ Go to top ]

    No, that's snobbery...

    ;)
  54. Paraphasing a famous movie: free your mind.

    If we have the chance of creating web applications using a proven paradigm, and stablished knowledge (swing apps), why not? Imagine porting a relatively small swing application to the web, it couldn't get any easier.

    I think people are just against such a technology because of fear of the different, and nothing else. I've read the docs, and found Echo to be a blessing, since most of my work is ASP code, which I hate. I'd love to change our environment to JSP and Java, but it doesn't depend on me...

    So, open your minds, and try to see things in a different way. There's nothing saying that web must be done page by page. If we have the choice of doing it differently, and the result is good and works, than it can't be a bad thing after all.

    "Tank, load the jump program"
  55. Re: I Don't Get It (Followup)[ Go to top ]

    In the form echo exists now, I didn't get it too...
    Maybe graphic designers are not very much involved in changing actual "real applications", but even hard-core swing developers should be tired to write
    this repetitive UI layout code. Echo advocates MVC, but it's
    L&F sits in Java code. I DO NOT need typesafety for L&F!!!
    What we do desperately need is a RELIABLE set of component
    to be used within some sort of templates (via taglibs?),
    and event-driven programming model (yes swing-like) for processing
    user input. But those components should not do dumb HTML re-rendering
    on every mouse-click. Yes we do need JavaScript/DHTML to back it all up, to
    create smooth user experience and minimize network traffic and
    load on a server, and here echo makes step in a right direction. Browser is a very thick and powerfull client, you know... 8-)
    The problem is well known - lack of compatibility.
    Solution - well-tested, tailored to differen browsers JS library, created by JS professionals, to back up those "Java" components where possible. It seems to me that JSF wile moves in a right direction (painfully slow), ignores JavaScript completely, and that's a pitty.
    We should not hide our heads into the sand and pretend developing Swing apps
    and knowing nothing about those pages, but we should give ourselfs a freedom
    to choose a view-point, and jump from page-centric to event driven the same way
    you used to jump from C to embedded Assebmler, should need arise...
  56. Re: I Don't Get It (Followup)[ Go to top ]

    Perhaps my experience has been different than everyone else's as far as the role of Graphics Designers but in my environment, Graphics Designers create images, layout, look and feel, etc. Then the developers are presented with the design and tasked with implementing it. That's where Echo comes in handy. I can look at a particular graphic design and break it up into Grids, Panels, and Images, then implement it entirely in Java. That may sound like a pain in the ass to some of you that are used to tag based programming but it really is easier:

    - Make a base component (let's say a Label) in which I set default properties and use it everywhere. Using OO techniques, I can easily extend the base Label and override certain properties. In no time at all you could have a hierarchy of label objects to use consistently throughout the webapp. You can do this with any Echo Component, including custom components that you make yourself.

    - Define my application styles in one class, say AppStyle. Then i can just say grid.BackgroudColor = AppStyle.GridBackgroundColor. Or better yet, have a base grid object that defines this and any other style I want. Then I don't have to worry about the specifics, nor does any other developer.

    You can see pretty easily how the Echo API combined with good OO techniques could save tons of typing and make the look and feel consistent. I've developed in JSP, HTML, countless template languages, and have not yet seen a better environment for developing web gui's than Echo.

    By the way, that JS Library you're describing doesn't sound much different than a JVM plugin for the web browser with which you can execute Applets.
  57. This example may be a small thing, but consistency of the user interface is important. With the app at http://echopoint.ascendancy.org.uk/echopointbank I do not see the "Back" button on my browser doing what I think it should -- go back to the previous page.
  58. No one gets it...

    It´s not a web page, it´s not a portal, what´s it? It´s an application!! Ever seen a back button on WORD, EXCEL (hint: it´s not the undo button :-)?

    This is about vertical applications, not you regular dynamic web page. The moment I looked at Echo, I instantly recognized how it could help me create systems. I work for a telecom company, and they are "porting" all their applications to its intranet. We have lots of systems, in ACCESS, mainframe, vb, and now everything is going web. Echo is perfect for this, since those sistems are all about "real applications", they dont require a nice picture, no fancy layout. Just plain forms, menus, reports, and not much else. The focus is not interface design, but solving the user´s problems fast.

    And I can use my swing design knowledge for that, with echo, instead of learning a new paradigm and API for each new framework.
  59. "This example may be a small thing, but consistency of the user interface is important. With the app at http://echopoint.ascendancy.org.uk/echopointbank I do not see the "Back" button on my browser doing what I think it should -- go back to the previous page. "

    It would be nice if we could convince the world that browser is not the place for applications. But it isn't going to happen(no matter how much I pray). So the problem of having maintainable non-plugin browser apps exists. And the back button, if not "disabled", will cause problems. How about a little label that says the back button won't work as "expected".
  60. Or just make your index.html use javascript to popup a new window with no buttons or address bar that actually contains your app.

    I remember something about a .hta extension a few years back, which was supposed to be html application. I can't remember what it did or what happened to it though, but it would be nice if it were reincarnated to solve these issues.
  61. Even if the back button is not present, many users today use the backspace key or even the alt-left arrow combo.

    Regarding the .hta, this great M$ innovation was one of the biggest hole on windows great security. One of the fix was to delete the file association .hta -> mshta.exe, thus preventing a wide developement of those applications. Nevertheless, this way of doing is still used internally by many of the wizards.
  62. First congrats to the Echo team on their successful 1.0 release! I've read the objects and responses and I'm currently an unhappy Struts user seriously considering Tapestry or JSF for my next project. I understand Echo and what it's trying to do. Here is my take: Let's break webapps down into two categories:

    1) Content rich - these are for typical web users who expect and demand a site that is visually stunning, full of graphics, etc. These sites are best made by web and graphic designers. Frameworks must be chosen to allow this.

    2) Application rich - these are where the functionality is more important than the look. Most intranet applications would probably fall into this category. The goal is to turn out business requirements with the highest level of quality in the shortest amount of time.

    In my opinion, after reading this thread, is that Echo is a good candidate for #2. For #1, it's not the best choice. I think some of the objections in this thread are assuming Echo is for #1 when it is not.

    I also like the business model: Give Echo away for free and sell add-on components. I'm very curious to see how this works as it's a popular business model now yet I haven't see too many examples of where it's been profitable.

    Finally, to the Echo team one piece of advice: It'd be of great value to see an appliation on the web that is built with Echo. Your tutorial requires installing everything, I'd just like a URL where I can play with an Echo app.

    Michael
  63. And what about using pure HTML to create dynamic JSP pages???

    Is it static HTML ?
    <INPUT type="text" name="bean.attribute">

    Maybe!!! I'm making it dynamic, but its pure HTML. Its running with Tomcat, and its free and open source.

    Want to use your own WYSIWYG editor to create dynamic JSP ? drop me a email at bengtson at withoutprice dot com

    Erik
  64. statefull or stateless[ Go to top ]

    It seems for every client an application instance is put into
    HttpSession object to keep its states. I don't know how big an
    average Echo application is, but this simple "cache" solution
    poses some serious questions: how many concurrent users can it
    support? is it scalable? how about using in clustering
    environment? Usually people just put some "data objects" into
    session object, HttpSession seems it's not a good place to cache
    application instance.

    As to back button, disable it breaks user's experience on Browser.
    After all, it's a standard feature of the platfom.

    thanks.
  65. Caching of Visual Components[ Go to top ]

    I'm looking at Echopoint Bank sample App. I'm impressed on how clean the code is. One question, are the visual components cacheable or could be placed in a cache pool so that we don't have to initialize it every time a user use it (or displays it)? Example on BankController there's contentPanel.add(new PanelLogin(this)). Can we cache panelLogin?