Icefaces vs Echo
Hi,
Recently I have been using Icefaces 1.8 with JSF 1.2 and facelets and I really liked it. Icefaces provides the AJAX support behind the scene.
Where Echo provides the solution just by writing the java code like swing, Icefaces requires you to write fully formed XHTML type tags intended for web programmers.
I know it's not same technology but I am trying to make a comparison between the two. Any help or experience will be appreciated.
Some points are -
Since you can embed simple html code with Icefaces it very easy to do things like putting line breaks, just write <Br/> tags, where as in Echo you will end up creating a java object first.
The look of the layout was pretty good in both as they both use style sheets extensively.
As I understand Echo stores everything in Session (the components and other data), whereas Icefaces provides you a way store managed bean with extended request scope / session scope.
I found Icefaces to be bit faster when it comes to show / hide data tables, and complex components like (tabs, tree etc)
Icefaces has built-in validation support, but because of the data binding feature of JSF, it is not easy to see who is invoking methods and listeners.
Icefaces provides bridges to hook your client side javascript, which I really like and it was matter of minutes I built a dialog same as "Please Wait..." in Echo with Icefaces connection status component, which shows a nice animation.
Very easy to handle concurrent dom views (new session when you click CTRL+N) just by changing a flag in web.xml
Very easy to switch server side / client side processing by switching a flag in web.xml
Icefaces allows you to redirect to other URLs so you can have different pages allowing users to save pages in favourites, In echo as I understand you will need diffrent servlet / some handling in application instance.
Thanks
Pawan
Echo is very flexible...
I'm a newbie and I can see a whole lot of ways to break up echo into easier to manage pieces (modules)... many folks frown on the tried and true iframe and frankly an iframe can do wonders to help break stuff up. Additionally, people use serialization in php and java(beany variety) to save state information for things; but frankly you can do this with the address url request; about 1k is safe for parameters typically... I think firefox gives ya 64k! (for a get!) In short, there are many ways to speed load times, modularize code and to make savable links for "bookmarks" etc.
I'm using the straight echo3 javascript client, and I'm admittedly a new guy on the echo3 block... but I think it's likely that both libraries have alot to offer you. I like qooxdoo also, but I have to say the echo3 demo shows cosmetically what is possible and looks great; and other drawbacks seem to just a matter of learning curve and the know how of when to jump out of the box when you hit a glass ceiling.
I don't know these NextApp folks well.. but they seem to have done a great job; I'm personally having tons of "problems" but I attribute them to learning curve. I need a GUI in a hurry; I have a good homemade web server; a crm needing a facelift and many applications and projects on my desk that need doing... I personally plan on pulling up my boot straps and getting to know this system well so I can figure out a "system" for myself to create apps quickly that are NOT laced with bugs (I may create) :)
--Jason
(editted: left out the capital word NOT originally... changes the post entirely! LOL )
Jason, here's a suggestion.
Jason, here's a suggestion. If you have experience with Java-based applications--particularly Swing applications--apply the same coding style to your Echo 3 client-side JavaScript applications and it helps somewhat. For example, use the Core library's capabilities to extend parent classes and composite things together, etc. A major difference I had to get used to coming from Echo 3 server-side was the property stuff where you call obj.set("property") or
Object.call(this, { property: true });I've found that Echo 3 sacrifices quite a bit of raw power you get from access to the DOM, etc. (unless you write your own rending peer, which is doable but another learning curve) for the sake of multiple browser support and stability. However, with some thinking, I was able to composite some Echo 3 API objects together to do what I want (such as a selectively boldable select list).
thanx - good suggestions....
I read in another post the push to write one's one rendering peers also.
Seeing how I'm looking for a suite of "special" controls for my needs... (mostly text boxes for various data types and data scrubbing or special "link" functionality) ... I will check this out.
One thing in particular I need to "port" to echo3 is my dynamic screen system which works like a web based visual basic form kinda or a like other CRMs (aside from my own) do... where you can manipulate the fields that show, their position etc....
In short - I'll be making my own rendering bits soon enough - Thank you very much for the feed back :)
--Jason
I have found writing custom
I have found writing custom components to be quite easy in Echo3. It took a bit of time investment to read the docs and look at the existing components. After you get the hang of it, you can create any components you may need.
Some components I created for my own app with jQuery:
- Drag and drop sort pane.
- Clickable pane with rollover effects.
- A corners pane which can do all the effects from jQuery.corner.
- An effect pane which can do all the effects from jQuery.effect.
All these can be combined to create a sliding expansion panel with bevel/rounded/etc corners.
Making components is pretty rewarding, though I still hate javascript and why I chose Echo3. :)
Oroborous
http://rpgworkbench.blogspot.com