Choosing a web client framework

Discussions

News: Choosing a web client framework

  1. Choosing a web client framework (96 messages)

    My company is going to start a new project. We have decided to take the opportunity to change the current web client framework in the process. If everything goes well, we will replace other projects with this framework as well. Here are some basic information: Development: mix of Linux and Windows, Java, EJB (2 and 3); deployment: linux, Glassfish for the new project (UI only), existing projects using WebLogic Server 10.3. We hope there is not steep learning curve for the new framework, with enough maturity, good Ajax support, ease of development, don't have strict requirements on the back end data model. Currently we are considering the following frameworks: (in no particular order) wicket, Seam, and Struts2 and we are open to hear community's input, feel free to suggest others and your views on the choices on the list. You can send your feedback in private in you like. Thank you. Chester Chen (cchen at ascentmedia dot com)

    Threaded Messages (96)

  2. GWT and Spring MVC[ Go to top ]

    As always, there is no one correct choice, and such debates can quickly turn into a religion war. Here is my opinion and experience: After working with Struts, Spring MVC, JSF, Seam and GWT, there is no doubt you will get the best results with GWT when considering the user experience, since the user doesn't have to wait for pages, or even Ajax parts, to load, and the GWT RPC communication is very compact and fast. It also means you will probably pay less for bandwidth and server CPU (this can make a big difference if you deploy to Amazon EC2 for example). The down side of GWT is that for some people (myself included) programming the entire UI and event model in Java is a lot less intuitive than writing the UI in XML and having POJO's methods handle events as in JSF. I use Spring MVC where I need to upload or download files, which GWT RPC doesn't handle, but GWT does allow submitting a form which can be processed by a Spring MVC controller. Good luck with your project! Gabriel
  3. Re: GWT and Spring MVC[ Go to top ]

    Thanks for the input, that's good feedback
  4. Flex all the way[ Go to top ]

    I've tried seam and gwt. Both are nice, but from what I've read, nowadays Flex is in another dimension, you should consider it seriously. If I would start I new project, I would definitively try Flex.
  5. Re: Flex all the way[ Go to top ]

    I heard good words about flex, besides license costs, what are the risks and learning curve ? Given that no one in the shop familiar with flex ?
  6. Re: Flex all the way[ Go to top ]

    Also, doesn't has any special requirements to the back end ?
  7. Re: Flex all the way[ Go to top ]

    What license costs? Flex is free unless you're using lifecycle services that no one really needs. Flex Builder has license costs, but it's just for developers and deployment of flex is still free. Also, there are other free ways to develop with flex. Flex SDK itself without the Flex Builder is completely free. Ilya
  8. Re: Flex all the way[ Go to top ]

    What license costs? Flex is free unless you're using lifecycle services that no one really needs. Flex Builder has license costs, but it's just for developers and deployment of flex is still free. Also, there are other free ways to develop with flex. Flex SDK itself without the Flex Builder is completely free.

    Ilya
    I did not know that. I always assume that use the Flex and its builder and deployment would associate some sort of license. Thanks for the information.
  9. Re: Flex all the way[ Go to top ]

    I've tried seam and gwt. Both are nice, but from what I've read, nowadays Flex is in another dimension, you should consider it seriously. If I would start I new project, I would definitively try Flex.
    even if i agree with you and i am actually using flex + blzeds + spring + hibernate, you have to admit that the client to server integration with blazeds is still miles away from being a solid platform; still too many black holes in the whole integration architecture
  10. Re: GWT and Spring MVC[ Go to top ]

    It sounds like GWT itself is not enough and need to work with another framework sometimes.
  11. Re: GWT and Spring MVC[ Go to top ]

    Let me clarify: GWT is purely a client-side framework - the end product is pure JavaScript. GWT does not depend on the server-side implementation, and you can use Servlets, RESTful services and JSON services to communicate between the server and client. Instead of using the Servlet API I prefer using a Spring MVC controller, because it provides a very nice REST support (and Spring 3.0 is supposed to be even better). You could use whatever server-side technology you prefer for that matter.
  12. My Recommendation[ Go to top ]

    For a recent large Java project, my team choose JSF: everyone who worked on the project was unhappy. Why we didn't like it: - Big learning curve. Even doing fairly simple GUI work, required us to learn lots of complicated object models that to me were far more complex than they needed to be. - Lots of weird bugs. Almost any routine or novice mistakes generated bizarre error messages that took hours or even days to resolve. - Components were terrible. We tried Oracle's component library, Trinidad, and some ajax4jsf stuff. Everything was very complicated to setup and buggy. Basic data table functionality was lacking. I evaluated Struts 2: Nice, simple MVC. I found the best approach was to ignore the server-side components and use basic HTML components + a client-side library (Yui/JQuery). I liked it. Then I evaluated Stripes: My favorite. This is just a simpler, lighter, cleaner version of Struts 2. I can't name one feature that I missed when switching from Struts 2 to Stripes. Stripes does have more elegant configuration and great support for clean URLs (http://site.com/items/1234 rather than http://site.com/ViewItem.action?id=1234). Stripes is a very simple, elegant framework. You can build anything you want in it, however, it doesn't do a whole lot: your GUI logic is nearly raw HTML, JavaScript, and a client-side library (Yui/jQuery). This is what I would recommend though. I've never tried Tapestry or Wicket or Groovy or Lift. GWT and Echo (and Laszlo) look excellent, but I haven't had the opportunity do a substantial project with them.
  13. Re: My Recommendation[ Go to top ]

    Thank you for sharing your experience with us, this is very helpful.
  14. Re: My Recommendation[ Go to top ]

    Agreed on simplicity and elegance. Feels as if these days all those frameworks are going somewhere without any purpose. Having 50 different clients all with different layouts but sharing the same logic/code is just as complicated on them as a shuttle. But stripes manages to allow for that without so much work.
  15. I can't believe nobody is really talking about Grails here! Come on guys, wake up and smell the coffee, drink the Kool-Aid! I developed a prototype for a web application the other day in under 2 hours with Grails, in between getting my 2 daughters to sleep, making and eating my dinner, and my wife coming home. I'm quite confident nothing is as productive as Grails on the Java VM. And look ma, its all java underneath!
  16. Re: GWT and Spring MVC[ Go to top ]

    Given you have a Java EE server architecture, the case for GWT is very strong. It works well with Spring. The upsides of GWT are so numerous I won't reiterate them again (plenty other posters have) except to highlight what are for me the clinchers: * You can make complex AJAX clients run blindingly fast - the thing is designed bottom up to do that. * You code and debug the whole stack (DB->browser) in Java from your favorite IDE. This is a big wow. * It compiles separate purpose built and optimized javascript files for each major browser that eliminate (almost) all cross browser problems. *it's RPC mechanism works very well with Java EE back ends, and you can use a REST approach to Spring integration if you like equally easily. There are some downsides to GWT that might affect your decision: * it is a toolkit rather than a framework. Its widget set, although comprehensive and fully functional, does not give you out of the box beautiful desktop style emulation. You can do that with GWT but you will need to put extra effort into art work/CSS (or hire a graphic designer/CSS expert). Rather it conforms to Google's philosophy and style of deceptively simple looking web UI's that do incredibly clever things for you behind the scenes. * GWT is a Java abstraction of DHTML, javascript and CSS, but it never tries to hide you from that. You can always use HTML, javascript and CSS with GWT and they encourage you to do so particularly when you are leveraging the browser's native functionality to deliver raw speed. The upshot of this is that the traditional distinction between Java server programmers and web page designers is blurred almost to extinction (if you are a Java programmer you really need to understand CSS and how the HTML box model works with GWT). * because of this the learning curve to production quality UI may be steeper than alternative frameworks that provide out of the box desk top style themes and widgetry depending. * technically you can pass annotated EJB3/Hibernate managed objects directly to the GWT client over the RPC mechanism *but* this does not work where lazy loading is involved, e.g. where your persistent objects may be adorned with proxies and "magic collections" by your ORM/EJB container. There are solutions to this, but you need to consider the options carefully. Reason is that GWT JRE Emulation is a subset of Java 1.5 and doesn't support things like reflection.
  17. It depends (are you surprised?)[ Go to top ]

    You have not really given much of info about the nature of the project, so people are just going to reply with their favorite framework. You could at least divulge where your project falls on the spectrum from web page to RIA, and who the target audience is. For my generic answer, I would say that if it's more on the app side of things and isn't public, going to something like Flex or GWT is a pretty solid, future looking move. I haven't used GWT, but I have used Flex and it is extremely powerful. (I have some complaints, but that's true for everything)
  18. The project is a "thin" Web client not a RIA. The site is going a B-2-B site, so there are limited number of users (from few hundreds to thousands at most). The shop is a Java shop with developer experienced mostly in Struts, JSP, Javascripts, some AJAX etc on client side. The server site is standard EJB (mixed EJB2 and 3) implementation with SLSB via remote interface.
  19. If your developers are experienced with EJB3, I recommend using JBoss Seam which is a glue between EJB3 and a presentation layer (mainly JSF2, the one I use, but other technologies are supported). Moreover Seam introduces very useful features like conversation contexts (the best way I found to avoid lazy exceptions) and gives a solution to recurrent web application needs : authentication, business process managament, pageflows, validation, PDF export, mailing, ... It also makes it very easy to use Ajax. I use it with JSF2 and Richfaces components and it works very well. Moreover the documentation is very good and the programmation model is very easy to understand, so tou have a short learning curve. Seam has been imagined by Gavin King, a quite serious guy, and it is the base for new web beans specification.
  20. Some other things to consider[ Go to top ]

    I have seen that most of the popular modern frameworks feed off lessons learned from others problems and improve their own frameworks, so the end result of products built on such frameworks come very close to each other in terms of performance and productivity. People can advocate one framework to be better that the other, but most of the time, it is based on their familiarity and comfort factor. So along those lines, there are a few other things that we take into account, which could help narrow down your choices. 1. Your team composition - do you have the teams separated by skills such as: UI designer, application developer, database developer etc? If so, then you probably want a framework that is designer friendly and is not completely Java oriented. 2. Team skills: What kind of people do you have, if they are from a Swing background, something like GWT would bring them upto speed very quickly 3. Component set: While most of the frameworks out there have the standard widget set built in, a few of them go beyond the norm and provide a much richer set. I have seen that in a lot of database drive products/projects, the grid/table control functionality is one of the primary requirements and that drives the choice of the framework to be used. This might not be the right approach in all cases, but sometimes when time is a factor, it could be. 4. Community/Support: Spend some time on the boards of the framework and see what people are complaining about. Remember that people come to the boards only to talk about problems and not the good things, so don't get biased. Just use the problem reports to see if they would affect you. Also if the traffic is low on the boards, or responses are slow, it could mean that the community using the framework is small and if you face a problem, there might not be a ready solution available. Of course it could also mean that that the developers would be more eager to build a custom fix for you faster. Ultimately, the best way to go about it would be to take your requirements, the component set you need, the ajax capabilities you require and spend a couple of weeks building a prototype with the above using the top 3 or 4 frameworks. At the end, you will see that it would be very clear as to what the best choice for your team is. Folks here (or any public forum) are very knowledgeable, but some are pretty religious too, so it would be hard for you to make a meaningful decision based on recommendations here. Hope this helps, good luck.
  21. Re: Some other things to consider[ Go to top ]

    Thanks for the insight. That's very helpful.
  22. Take a look at zkoss[ Go to top ]

    I am implementing an application using zKoss, With the zKoss 1. Easy to learn 2, Full ajax support 3. Easy to design any copmplex UI 4. Can be integrated with hibernate, spring
  23. Re: Take a look at zkoss[ Go to top ]

    I haven't heard this one before, I will take a look.
  24. Very good ZK! (And OpenLaszlo too)[ Go to top ]

    I've developed a complex Web Application in the past with ZK (Ver. 2.1). I've found it very useful, simple and powerful yet. It has a simple Xml Form description standard and you can write your own event handlers with simple POJO. It has also supports annotations for data binding. (Very useful). Other RIA tool is OpenLaszlo (very very good). Take a look this also. Sandro
  25. qooxdoo for the front-end[ Go to top ]

    I would suggest to use qooxdoo. http://www.qooxdoo.org This is a js framework that will give you an outstanding OO layer, a client side framework plus a widget library. This is really made for "serious web application", not for "cool internet site" :-) You still need a backend that could anything you want able to receive HTTP request to provide data and play server-side business logic. What distinguish qooxdoo from other client-side stuff ? Qooxdoo use the CPU power of the client side. In term of software architecture, it could be seen like a Swing client that un into a browser coded in JavaScript. This leave the server horse power to deliver data to more client. With qooxdoo, the server bandwidrh is not wasted to manage each single AJAX click or even mouse over of the client side. Of course, qooxdoo allow asynchronous request with underlying AJAX mecanism. Of course, qooxdoo, like any modern web client side, is multi browser. Hope this helps !
  26. I did a similar selection about 1/2 year ago and after trying out close to 10 frameworks I ended up on the Wicket framework, and I am very happy about the choice. I prefer the component oriented apporach a lot over a tag- / request-based web framework. I also recommend that you write a prototype to understand Wicket. It's hard to grasp the concepts properly without writing a prototype. (maybe unless you have some GWT experience... GWT is similar to Wicket in idea). I also challenge you to find anybody that has anything negative to say about Wicket. My biggest surprise about Wicket is how happy everybody is about it, and how every problem seems to have a nice solution that does not create spaghetti code. Plus Wicket supposedly has the most active community of any web-framework out there. Regards, Oyvind
  27. Re: Choosing a web client framework[ Go to top ]

    I'd agree with Oyvind. Of course everyone has their preference, but for me it's Wicket everytime. The ability to do proper OO programming in the frontend, use Component inheritance and composition, creating custom components easily etc, and also an excellent out-of-container unit-testing framework all make Wicket a winner for me. Also, there is quite a vibrant community of add-on Components and utilities around Wicket - if there is a Wicket problem or Component you want, a simple Google search will often find you exactly what you need.
  28. Re: Choosing a web client framework[ Go to top ]

    I know many in the community favor Wicket (from reading the past posts in TSS), and it looks like a good framework from documentation. I haven't tried myself. Does have a steep learning curve ? We have a tight project schedule.
  29. Re: Choosing a web client framework[ Go to top ]

    I know many in the community favor Wicket (from reading the past posts in TSS), and it looks like a good framework from documentation. I haven't tried myself. Does have a steep learning curve ? We have a tight project schedule.
    Depends - yes, Wicket is more API based than pattern based (you have to learn some part of the API), but I have gotten developers productive with Wicket in less than a week. ..and depending on what you are trying to do, there are also a lot of add-on libraries/frameworks that can help: For instance Wicket RAD is a RAD framework/add-on to Wicket that can help with things like form generation from beans with the help of annotations, eased persistence with JPA integration and generation of tables (full disclosure: I am the author of Wicket RAD).
  30. @Oyvind Thank you for sharing your choice with us. Would your mind to tell us which 10 frameworks you have tried and why do you decide NOT to use them ? I know every one probably has his/her favorite pick and may have strong opinion on them. But I would like to hear your experience, your choice and your decision behind the choice. I think that would help us as well. Chester
  31. Use Struts 1.x[ Go to top ]

    It's been here for years, it's rock solid and stable. Every week on TSS there is at least one new Web Framework, but why bother?
  32. Additional frameworks[ Go to top ]

    I'd recommend comparing Wicket and Stripes. Joshua
  33. For larger Projects: Wicket[ Go to top ]

    i´ve been down the Seam/JSF road and i´ve beared some classic MVC frameworks all for professional serious projects. What i have learned so far: if you want to get things done quickly AND keep em maintainable AND want to follow the DRY Principle, component based frameworks are the only way to go. From what i have experienced, easy of development, developer productivity, maintainability as well as system scalability kind of exploded when we switched to wicket a year ago. i´d recommend this for any 'more than a website with a few dynamic boxes'-kind of webapp.
  34. Re: For larger Projects: Wicket[ Go to top ]

    @uwe schaefer Just be clear, are you saying that your have experienced problem with Wicket and now you are using (or thinking using) Seam/JSF ? Would you mind clarify and/or elaborate ? Chester
  35. @uwe: I interpret your use of explosion as a positive laden word... (?) In any other case I would beg to differ. Wicket is simpler, simple one-to-one mapping and nice inheritance. Otherwise; I am afraid of using T5 - It seems to me it lacks a serious community of core developers. I do not wish to spread FUD, but I hardly think this is a fallacy...
  36. Re: For larger Projects: Wicket[ Go to top ]

    @chester chen
    are you saying that your have experienced
    problem with Wicket and now you are using (or thinking using) Seam/JSF ?
    not at all. what i meant to say was: for any non-trivial webapp wicket is the best tool i have seen. if your usecase is not too different to mine, you´ll find that wicket rocks for anything beyond a trivial marketing website.
  37. We're switching to Stripes[ Go to top ]

    My company is finally upgrading the site (from '98 ASP + VB DLL) and we've chosen Stripes for framework - so far, I couldn't be happier with the development speed and ease of installation. Not to mention the minuscule learning curve.
  38. Re: We're switching to Stripes[ Go to top ]

    good to hear that, have you look at other frameworks and would mind share your decision process ?
  39. Re: We're switching to Stripes[ Go to top ]

    I've spent about 3 months looking for framework. The biggest issues that came up were the learning curve, ease of installation and simplicity. Some thoughts: * struts - skipped this one due to a lot of negative bias among friends/developers. Everyone I know has some kind of an issue with it, installation or development hurdles. * tapestry - the learning curve was too great. Hard to find some simple example of a simple task such as login/logout. Too much restriction on correctness of HTML. * wicket - loved it, but installation process was a bit hard and required a lot of customizations on IDE part. HTML pages were in a weird directories and our HTML guy got confused. * spring - learning curve is too steep. There were others, but none more come to mind. The idea was to keep the site layout as simple as possible and preferably use POJO for coding. We don't use hibernate as our database structure is old (based on some old mainframe from a Belgian bank) and we also have none-db information that needs to be added to the records. Our site requires to be customized for many different languages and clients w/ some (really) strange requirements. I was very happy to stumble upon Stripes and compared to others, had a simple login/logout site running within an hour (including all IDE setup). Before Stripes, I spent weeks on Tapestry (since TSS is written on it, I think) and it made closest sense but was just too much work and aimed mostly for developers. HTML guys were most unhappy. Hope that whole rant makes sense.
  40. Re: We're switching to Stripes[ Go to top ]

    Oh, yes, forgot to mention. Combining DRW and Stripes was really simple. For us its a huge plus.
  41. Re: We're switching to Stripes[ Go to top ]

    Thanks for the input. That's very helpful. Just few followup questions, beside learning curve, you mentioned that "HTML guys were most unhappy" about Tapestry. I thought Tapestry is component-based and with Separation of HTML (except for the component ID) layout and code (just like the Old WebObject from Next/Apple), that should make HTML guy happy, doesn't it ? And Stripes is Action-based (like Struts 1.x) and not component-based, is that correct ? Is there community site you can post questions and hopefully get some answers ? I did not seem to find it. Thanks a lot
  42. Re: We're switching to Stripes[ Go to top ]

    At first, I really loved the idea of Tapestry having complete separation between code and HTML. But the HTML guys said, we want to see our pages as they would look on live site, so basically no prototyping. This is rather good idea since we, as developers, aren't very happy trying integrate their HTML into the working version. Plus, when I was trying Tapestry, it kept complaining about simple HTML typos, not closed tags etc... things that browsers tend to ignore. That proved to be a headache. As for Stripes, I've never had a question so far that haven't been answered by a tutorial or 5 min experiment. They have a site, you may want to check how active it is. Also a note, our site is rather simple and we have 3 developers and 2 HTML guys.
  43. Re: We're switching to Stripes[ Go to top ]

    Thanks again, I did went to their site, and I did not find a community site,but just email archive. The last post was in 2006. They did have a recent release in Aug.2008. That makes me think I might have look at the wrong place.
  44. Re: We're switching to Stripes[ Go to top ]

    I believe the site is http://www.stripesframework.org As with all frameworks, you should try prototyping. Can't fully grasp the concepts until you try out for yourself.
  45. Re: We're switching to Stripes[ Go to top ]

    Hi Chester, Besides the mentioned main Stripes web site, http://www.stripesframework.org, you will also find: Cheers, Freddy Daoud Author, Stripes ...and Java Web Development is Fun Again
  46. Re: We're switching to Stripes[ Go to top ]

    Thanks for the extra information
  47. wicket is cool[ Go to top ]

    I have been playing around wicket for a while and its pretty cool and has solid ajax implementation...even has some recent support for cometd server push notification which is pretty interesting as well. I would certainly consider it when starting a new project now. As others have mentioned it really depends on what your requirements are and what your developers are going to be able to work with easily. Things like GWT and Dojo are great so long as you want large chunks of your application to be javascript based and your comfortable in debugging those kinds of concerns. Things like wicket and struts will give you a more traditional web framework to work with which certainly has its benefits, but if you want to have some combination of the two with all sorts pretty javascript bells and whistles and ajax widgets in your application I recommend you take the time to map out how the really complex bits will work...maybe even prototype out the complex bits. Few things are more annoying then investing in and growing to love a framework that takes you 95% of the way and then you have to do all sorts of hacky things that are terrible to maintain for the last 5% of the functionality.
  48. GWT-Ext and custom behavior[ Go to top ]

    I recently worked on a GWT-Ext project and it really simplified the UI layer development. However, sometimes the customer requested specific changes on widget behavior which become problematic. I think that this is another aspect to take in account.
  49. We are currently using the following framework mix with great results: ExtJS: for a Rich Internet Application front end DWR: Direct Web Remoting, for communicating with Java backend. Acegi: For security stuff (now part of Spring) Hibernate: For Object Relational Mapping Spring: For gluing it all together. The learning curve is quite steep though, but the results are worth it. We make heavy use of AOP (through Spring) for crosscutting concerns as security and auditing. References: http://www.extjs.com/ http://directwebremoting.org/ http://www.springframework.org/ http://www.hibernate.org/
  50. @Pablo Krause thanks for sharing your experience. So for the front end, you are pretty much Javascripts based if I am not mistaken ? Is portability and debugging on different browsers an issue for your ?
  51. Agree with Stripes, here is why[ Go to top ]

    Based on all the information you provided about your project and team, I agree with the choice of Stripes. 1) Easier and faster to learn than the competition - it is an action-based, MVC framework like Struts, which your developers already know. Struts2 and Spring MVC are harder to learn in our experience - their documentation was not as focused as with Stripes and there were too many things to learn at once. 2) Very productive to work with. 3) Stable, mature, unit-testing friendly, POJO model, easy to use with other technologies like Spring, DWR (AJAX), etc... Beware: 1) if you have only Java 1.4, you have to use Retrotranslator 2) no support for automatic client-side validation via JavaScript
  52. Re: Agree with Stripes, here is why[ Go to top ]

    Please note that although the Stripes core doesn't provide automatic client-side validation it does have a way to provide validation meta-data to JavaScript via the tag. There is at least one existing library that uses that validation data for automatic client-side validation. You can find it in the SVN repository for the Stripes-Stuff project on sourceforge.
  53. GWT[ Go to top ]

    Well, although it is almost true that GWT is client side framework, it is not completely right. GWT has its own communication protocol (RPC) that is supported on the server side (your servlets extends GWT base servlets). This way, the communication of client (technically JavaScript) and server (Java) is done by GWT and is transparent to developer. But you can use your own communication (REST, JSON, whatever...), that's right. But the above is a beauty of GWT and it is its biggest advantage that is not matched by any other framework. GWT is component framework, everything is defined in Java. You can share your code (i.e. validation) on client and server. Still client is translated to JavaScript, thus the application (user experience) is superior to different frameworks unless you want to write (a lot of) client side JavaScript. Other component frameworks usually run on server only, the client is just a small JavaScript engine, that process user response and send AJAX request to the server, which has 2 huge drawbacks : the communication is much more heavier (slower feedback to user, higher volume of traffic) and the server needs to keep state of the user interface in memory, which will start to be a problem once the application is big enough plus your user base grows. In GWT, you can do a lot on client side, and only let the server side handle business logic and operations that needs to be secure. I have experience with several frameworks such as Echo or JSF or Thinwire, but due to nature of the almost magical Java to JavaScript translation of GWT I think it is really a superior solution to those "traditional" frameworks.
  54. Click or Flex[ Go to top ]

    Hi my two cents worth on this topic is. If you want an easy to lean / use framework, Click is probably one of the best out there. Ajax support isn't Clicks strongest area, as it introduces a different programming model (asynchronous). However, we do use quite a bit of AJAX in Click, as you can see on Click Examples: http://www.avoka.com/click-examples/ Note if you need a really feature rich UI (Ajax heavy), you should also look at Flex. The advantage of Flex is that you don't have to program for the different browser JavaScript engines, DOM models and CSS support (IE6, IE7, FF, Safari, Chrome, etc). This point is not to be underestimated. Flex also has a great IDE in Flex builder, with compile time checking. Disadvantages with Flex are: * More complex programming model, but you will hit this anyway if you do a async AJAX based design. You will need to use a proper MVC architecture (see Cairngorm). * Have to include a Flex/Java marshalling layer, you should use Adobe Blaze (open sourced) or look at web services. Not a big deal, but something you need to do. regards Malcolm Edgar http://click.sourceforge.net/
  55. Re: Choosing a web client framework[ Go to top ]

    Spring webflow (rich navigation) + jQuery javascript library (AJAX + millions of widgets/plugins) jQuery/JSP .tag files for components. Sitemesh for decorating pages and widgets. Webflow also gives you post-redirect-get out of the box, extra scopes (conversation/flow/flash) to solve a lot of problems that you'd otherwise have to roll-you-own for. Avoid horror stories like Struts / JSF. I haven't looked at Wicket enough to offer a comment, and not sure if it would fit in with Webflow.
  56. Re: Choosing a web client framework[ Go to top ]

    My take. One thing to consider is the userbase profiles. If you're going to develop a casual-user oriented website, and you like to see clean urls (I would do if I were the casual user), then you should think it twice before choosing a component-oriented framework. They tend to use strange url mechanics (JSF uses POST always, Wicket and Tapestry use weird parameters...) Action oriented frameworks, on the other side, are quickly put up to work, but have less reusability than component-oriented in the long run. I would take Wicket for a component-oriented, and Stripes or Loom for an action-oriented framework. Stripes is a pleasure to work with, but Loom has a lot of awesome features. Hope it helps.
  57. The app I am working on is not multi-page heavy. Users generally work with a few pages and each page is dynamically updated based on user interaction. For this I have found Spring 2.5 MVC with annotated controllers and a custom handler that converts the ModelMap to JSON (using json-lib library) to fit the bill. I found this to be extremely effective in separating the backend logic from the frontend and the respective roles. Your frontend developers need to be JS capable and just about any JS framework will work (we use ext-js). Also the interaction between the backend and frontend via JSON must conform to a stable well communicated API. This also lends itself to be a very testable framework.
  58. Wicket[ Go to top ]

    We recently went through a similar excercise. After evaluating most of the popular frameworks including Seam, JSF, GWT and Spring, we ended up choosing Wicket. Here are some of the main reasons: 1. Its front-end is fully testable with unit tests, including Ajax calls 2. It uses one simple concept for everything Ajax-related that allows you to do just about anything you can think of 3. Very clean separation of presentation from business logic. 4. Very active and helpful community 5. Short, if somewhat steep, learning curve. Once you understand a few basic principles, you understand pretty much everything. 6. Easy to integrate with both front-end (javascript) and backend (spring and others) frameworks. Good luck with your decision! Remember, if you are unsure, choose two or three and do a short prototype of the same functionality in each. A clear winner is bound to emerge. Andre
  59. EXTJS + Spring MVC[ Go to top ]

    We have successfully developed/enhancing a complex web application with lot of ajax calls for last 1 year using Spring MVC and ExtJS. Learning curve for Spring MVC is negligible if you are familiar with Spring. Though ExtJS demands some effort initially but you get the coolest looking UI. The JSF based components are no where near the ExtJS component suite. One negative point with EXT-JS is that it is no longer free.
  60. IT Mill Toolkit[ Go to top ]

    Reasoning: - You only write Java: no XML, no HTML, no JavaScript needed - Free. Open Source. Under really liberal Apache 2.0 license.- Really rich widgets, just look at the demos at: http://itmill.com/ - Full-blown Ajax UI supporting all modern browsers (without writing any Ajax code yourself) - Mature: lots of apps written with the toolkit since year 2001 - All of you code is securely executing on server-side: integration with backend is just a method call - Strong data-bindings built in, easy deployment as a servet or portlet, useable from any IDE as the library is just one JAR-file, no dependencies - Easily extensible in Java using Google Web Toolkit
  61. Have you considered Grails?[ Go to top ]

    From what you described as your type of project and team, you may want to take a look at Grails.
  62. Capability is the key[ Go to top ]

    How good is your company's experiance in using the Open source products and frameworks? Nothing wrong in trying a all new framework/product for the development. I am sure no client will pay for doing research and on the job learning. At the end of the a client wants a working product with his expectations met. Choose the one you have tried and your team is comfortable with confidence. This may sound like bit odd, But if you are a solutions company the capability is the key for successful project delivery. www.itspice.com
  63. Just working...[ Go to top ]

    Hello Chester, First, I'm glad to see so many nice feedbacks on stripes in this thread. Is humanity at the edge of a significant mass awakening? FYI, the basic techno stack we are using everyday for our websites is jQuery-stripes-springIoC-iBatis. Stripes mainly bcz: -stripes is only a MVC framework, but does it so well! and is very stable -previously on struts and spring MVC, moving to stripes was so easy for the team -juniors learn it easier and faster than struts2 and spring MVC -higher productivity in the team! -(no OGNL :-) ) JC
  64. Re: Just working...[ Go to top ]

    JC, I just ordered a book on stripes, thanks for the feedback. I really appreciate everyone's input. I hope this helps other readers as well. Chester
  65. Is it possible ?[ Go to top ]

    To use plain HTML and no framework, just javascript to update html with dynamic content. After looking at various frameworks I feel plain old html (POH) is what I would be happy with. And then spring and other frameworks in the middle tier. Please share your thoughts .
  66. Re: Is it possible ?[ Go to top ]

    just javascript to update html with dynamic content... And then spring and other frameworks in the middle tier
    You just described GWT.
  67. Re: Is it possible ?[ Go to top ]

    just javascript to update html with dynamic content... And then spring and other frameworks in the middle tier
    That's exactly the pattern we apply for some parts of our websites at work. Basically, we expose RESTish API using stripes with its nice url binding mechanism. Then we use jQuery's JSONP to interact with the server-side. This architectural style allows us to expose very "neat API" and move a good part of the presentation logic to the client. Actually, applying this approach is straightforward. You don't even need to learn any new sort of technology. Besides several aspects of the development cycle get simpler... Hope it helps. Please share your thoughts. JC
  68. Re: Is it possible ?[ Go to top ]

    Hi JC Thats very interesting. How do you manage i18n and functional security for users in terms of user menus etc. Thanks much for your input Cheers
  69. Re: Is it possible ?[ Go to top ]

    Hi Andrew thanks for pointing to GWT. GWT sounds like its programmatic. I am thinking more of HTML straight out of dreamweaver working serverside code. Are there patterns of integrating GWT with plain html that comes from dreamweaver like tools. Would be good to know. Cheers
  70. Re: Is it possible ?[ Go to top ]

    ...HTML straight out of dreamweaver working serverside code
    HTML doesn't work serverside code. Homegrown XMLHttpRequest or more capable AJAX frameworks do. You can't escape the programmatic. My experience is that I tend to work with a creative person who cuts the static style and layout and gets sign-off. I then hook in the dynamic nature which means page scoped and async service calls.
  71. Re: Is it possible ?[ Go to top ]

    While you can't escape the programmatic Wicket helps keep it cleanly separated.
  72. Look at Grails[ Go to top ]

    When I started in IT, my development process was quite agile; apps were done in an iterative manner that kept an executable in front of the customer constantly. As my toolkit changed over the years I stayed pretty agile until I left Delphi looking for a multi-platform tool in Java in 1999. With the plethora of frameworks, there's a lot of heavy lifting before you could produce an executable (this was early EJB). Java on the web has just exacerbated this situation. Grails brings java-like syntax (and as many frameworks you care to keep) into an extremely rapid development environment. You can even simplify your tools, skipping a large Eclipse install for a simple text editor (I use JEdit) and the command line. Take a day (next week's a holiday - maybe Fri?), have your developers spend one hour on the first tutorial in the 'Mastering Grails' series (http://www.ibm.com/developerworks/java/library/j-grails01158/index.html?S_TACT=105AGX02&S_CMP=EDU). After they pick their collective jaws off the floor, spend the next 3-5 hrs on the following tutorials in this order: 1. GORM 2. Views 3. Event Model 4. Testing 5. Async with JSON/AJAX The productivity offered by Grails is simply astounding. Writing web apps really can be this easy.
  73. JSF 2 + SEAM 2 + Facelets + RichFaces[ Go to top ]

    We just finished a big SOA project with 100s of GUI an 3-4 complex dashboards. Main requirement were. 1. GUIs should be good looking. 2. Component orienter, easy to reuse components across pages. 3. Web 2.0, lot of AJAX and partial page rendering and partial page refresh. 4. Industry backed open source. We evaluated many frameworks, finally we choose JSF 1.2.10 + Facelets 1.1.14 + Seam 2.2.1 + JBoss Rich Faces 3.2.2 + Ajax4Jsf (part of Rich Faces) with Netbeans 6.x as IDE. With Facelets u can use plain HTML and create composite components easily. With SEAM 2.x state maintenance were like cake walk. With Rich Faces 3.2.2 we had very good looking GUIs (Blue sky and GlassX are my favorite). With AJAX4Jsf u have power of partial page rendering and partial page submit. With JSF now going to JSF 2.0 you have very powerful lifecycle (Convertors + validators + action processing + Rendering) With Netbeans you have a very productive IDE integrated with Glassfish. On server use Spring and Hibernate and EJB 3.x based on your architecture and load and clustering requirements. We have also worked on Flex for a smaller project, Flex gives u good animations but speed and performance of Flash is still not good, even with Flex 3 its RSL caching feature performance is still bad and so before choosing it for a v big enterprise application do lot of performance and load testing and decide accordingly. Honestly just because of few animations I cannot slow my application which has requirement of 100 active session, so we did not go for it in bigger projects but still using it for prototyping and smaller ones. JSF 1 release was buggy but With JSF 1.2 and now with JSF 2.0 planned to be released in december which addresses composite components + Ajax + State + bookmarking its evaluation is a wise decision.
  74. +1 JSF + RichFaces + Ajax4JSF[ Go to top ]

    I second Rahul's view. We are using JSF 1.2 + RichFaces + Ajax4JSF and we are pretty happy using them. I would even say that you should not use JSF without richfaces. The components offered by richfaces are really amazing.
  75. Rich Faces demo can be seen at http://livedemo.exadel.com/richfaces-demo/welcome.jsf Also lot of things depend on your future Strategy on B2B integration (SOA). Portals JSR 168 + JSR 286 and WSRP are used a lot in this area. I am working as architect in world one of the best MNC and we are working a lot on JBoss Portal server and IBM Websphere portal server using SOA ESB. BEA has also a good portal products. With JSF portal bridge now being released and implementations ready, JSF 2 becomes more promising. But this all depends on your actual B2B requirement.
  76. Happy with JSF + EJB 3 + Optionally Seam[ Go to top ]

    since you use Glassfish, I would recommend using JSF + EJB3 with Netbeans you can use visual web pack to develop prototypes very fast. they work fine together. JSF have some problems which you can solve them Facelets and Seam. if you want to use Seam + JSF + EJB 3 it is easier to switch to JBoss server + JBoss IDE (Eclipse plugin), for less painful development. (netbeans dosn't recognize seam components) there are lots of JSF components which you can use together which reduces development cost and pain. if you want to use Oracle ADF rich client which is one the best Ajax enabled JSF components sets, be aware that they don't support facelets. (trinidad do) AJAX4JSF (bundled in seam) can help to add AJAX support to those JSF components which don't offer AJAX capability.
  77. Have a look at Jolene. http://jolene.sourceforge.net/
  78. +1 Wicket[ Go to top ]

    If you are looking for a general purpose framework and prefer traditional action style frameworks I would personally choose Stripes. If you prefer working with components I would suggest Wicket and for attractive product marketing/sales sites or when the application needs to call on heterogeneous remote services I would consider Flex. If you prefer programmatic layouts over HTML then GWT and Echo are also great choices. I am intrigued by but haven't tried ZK and Click. For now though I am enjoying Wicket.
  79. Spring MVC[ Go to top ]

    I find Spring MVC has a higher learning curve because there aren't enough documentation/tutorial out there. I bought books but they cover the Spring framework along with Spring MVC and you'll still need to use something like DWR with Spring MVC for AJAX. IMHO, Spring MVC probably makes more sense if you plan to leverage other parts of Spring framework such as DI, AOP, their excellent SpringDAO.
  80. Here are a series of Spring MVC tutorials which you might be interested in. It's quite simple. http://www.zkoss.org/smalltalks/mvc4/
  81. Give wingS a try![ Go to top ]

    Hi, if you have at least basic Swing knowledge, give wingS a try (http://wingsframework.org). Holger Engels (biased wingS lead developer)
  82. Can anyone comment about ICEFACES?[ Go to top ]

    Icefaces is looking really nice. Anyone here used it?
  83. ICEFACES, RichFaces, and JSF[ Go to top ]

    These are pretty much dead for many shops because of the monumental failure of JSF to deliver on the goods. I mean, no page templating? Are you serious? What was to be an ASP.NET competitor component based framework ends up being more work in the end. It's easier just to use another templating system and plug in a an AJAX RIA control framework. I applaud ICEFACES and JBoss for their efforts, but the JSF model is just jury rigged IMO.
  84. ICEFACES WEBSITE[ Go to top ]

    http://component-showcase.icefaces.org/component-showcase/showcase.iface
  85. ZK is Easy Ajax for Java[ Go to top ]

    ZK is a MUST-SEE Java framework for the following reasons. 1.Rich Widget Set: 200+ ajax widgets including rich editor, google maps, chart components. 2.Ease of development: component-based, and event-driven development. 3.Simple programming model: No more RPC call, or XML request. Your application can access back-end services directly. 4.Low learning curve: only little java programming is required. 5.Buil-in MVC: XML for UI, Java for business logic 6.Markup language support: UI designer friendly. 7.Complete Integration: could be integrated with Hibernate, Spring, Seam, JSF, JSP properly. 8.Mobile support: allows you to extend your application to mobile device with ease. 9.Fast prototyping: Script language supported. So far, ZK exceeds 75,000 downloads at sourceforge.net. Explore the live demo. Or you can read this article. Direct Ajax - Goodbye to Ajax Deadly Sins.
  86. Re: Choosing a web client framework[ Go to top ]

    Lot's of answers so far! My two cents: We don't use Wicket nor Seam. Wicket seems very good and popular; it's not enough recognized as a standard outside Java architect's world for us, we were not sure about its future. Seam is supported by JBoss, but currently relies on JSF and it's a no go for us (too complicated, not sure about its future, steep learning curve, a new version which fixes a lot of things is coming but too late, and still not really released) We use currently Struts 2 and Flex. Struts 2 looks like Struts 1 (so it's okay for developers who know MVC). Framework is okay, but not perfect, and still has bugs. Not as solid as I hoped. I'm not sure about recommending it. Flex is great, but very very different from traditionnal web frameworks. Basically, a lot of things must be stored on the client (but not too much!). The basic is simple, but as soon as you want to do more complex things, it's very time consuming to learn Flex and Flash component development. So if you want to go this way, you have to spend a lot of time on learning, and your first project will take some time. If your schedule is tight, I wouldn't recommend it; otherwise, it is a good solution. So? what would be the best choice for you? GWT is really nice. Not so sure about the future of HTML and Javascript, but GWT compiler could generate Flash or Silverlight or something else. New releases add a lot of new functionnalities, and it's not very difficult to learn. Wicket could be a good choice, if the community around this framework is an important part of your choice (lot's of support). Flex if you have time to learn it. If you're looking something simple and your developers know struts, you can go for Struts 2. It's okay, but not a very long-lasting (something like 3 or 4 years).
  87. Wicket´s future[ Go to top ]

    Wicket seems very good and popular; it's not enough recognized as a standard outside Java architect's world for us, we were not sure about its future.
    come on. it is an apache project with a VERY healthy community (actually one of the most active community i have seen so far). if you choose in a conservative way, you cannot even consider struts, flex or - god forbid - GWT for being non-standard. in fact, you´ll end up the JSP road then, if JSF is a showstopper (and i agree with your arguments about JSF here). and really, nobody wants that.
  88. Simple[ Go to top ]

    For me, Stripes in like 90% of the cases... whatever you need to plug in past that point you can. The frameworks do far too much to be in "open source", because by the time you get one down, you're on a new project with a different one and back at ground zero. Thinning the model out to focus on functional, highly usable code is far better than the magic framework where it all happens "behind the scenes".
  89. JSF 2 is very Powerful!![ Go to top ]

    I really doubt above comments technical inputs. With Facelets one can easily create composite component. SEAM 2.x gives lot of good power to state management, bean outjection, URL bookmarking and many other things. Just See the power of JBOSS RichFaces 3.2.x and AJAX4JSF, partial page submit and partial page rendering. This all is very powerful in JSF. I love JSF lifecycle, it is very cleanly and wisely designed(convert->Validate->CreateModel->EvaluateAction->Render) Netbeans 6.5 come with decent CRUD generator with woodstock, giving RAILS like productivity and integrated with JPA. I agree, JSF start was not good but now it is quite good. JSF 2 is very powerful, EDR2 is already available and in DEC mid it is expected, anyways JSF 1.2.10 is also v stable(Majorra).
  90. Don't forget to check out Matt Raible's deep knowledge in this area. Here's a recent offering. http://raibledesigns.com/rd/entry/oscon_2008_web_frameworks_of
  91. Click Framework[ Go to top ]

    you should try click framework, it´s very easy to learn. http://incubator.apache.org/click/
  92. Mentawai Framework[ Go to top ]

    Well, I suggest the MENTAWAI. It's a Brazilian framework. It's an excellent framework. Look at http://www.mentaframework.org/?loc=en
  93. Accessilibility Anyone?[ Go to top ]

    All this talk of this ajax that ajax, jsf and etc. Does no one out there have to produce accessible standards compliant web sites? Let me tell you we do and let me tell you as soon as you use any component framework or framework that relies on javascript it is broken in the accessibility world. If you want truly well coded accessible web sites you need to code most of the html by hand and be very careful when using server side code that generates html. You must not rely on ajax for core functionality as the web site must still function with javascript disabled. Would like to here anyone on this thread say that this was part of their selection criteria?
  94. +1 Wicket[ Go to top ]

    I would evaluate those frameworks and see what's best for you but I personally use Wicket for web development. It has a huge range of reusable, yet easily extensible components for 99.9% of my web development, strongly typed AJAX without boilerplate code, retains state elegantly and there's no logic in my HTML. If you have any questions about Wicket then its active mailing list is a great place to get them answered quickly. Good luck with your evaluation, James.
  95. My proposal: ItsNat Natural AJAX. * Absolute pure HTML (or SVG) templates with the static layout and patterns of dynamic parts in pure HTML with no code, and no custom tags. Including "page fragments" to build applications ever in the same web page. * View logic using Java W3C DOM APIs. Absolute control of the HTML layout and view behaviour. * AJAX as a basic piece, client events converted to Java W3C DOM Events automatically when a DOM event listener is registered in the server. * Learning curve very very flat: HTML + Java W3C DOM APIs + Java W3C DOM. If you know HTML and JavaScript (DHTML) you know ItsNat. * Optional component system reusing Swing when possible. HTML layout of components is fully customizable. * Perfect to build One Single Web Page applications: no reload, no back button problems, fully AJAX. * Supported by almost all modern desktop and mobile browsers including AJAX and new BlackBerry devices (Bold and Storm). * Unique features like "Remote Views/Monitoring": a (ItsNat) page seen by a concrete user can be seen by other users to monitor actions, like a remote control for web. * Sever driven Comet
  96. Considered going on the cloud?[ Go to top ]

    I may be a little out of context here, but have you considered coding in the cloud a.k.a. Platform-as-a-Service offerings? The force.com platform and mor.ph are two of the good options with very less learning curves. Force.com allows coding in Visualforce and Apex which are very similar to JSPs and servlets/POJOs. Mor.ph lets you code in java or ruby. Again, it may be drastic to change the platform altogether when you're only looking for web frameworks, but considering the advantages offered by these (quick development, no servers to maintain, etc), you just might want to look into the options as well. Cheers and all the best with the selection process. Look forward to see what you decide on!
  97. Jt Pattern Oriented Framework[ Go to top ]

    You may want to consider the Jt Pattern Oriented Framework. It is a Java framework based on design patterns (DAO, GoF, MVC, etc). It integrates with many J2EE technologies (EJBs, Struts, Ajax, BPM, etc) Jt - Java Pattern Oriented Framework (Jt 3.0) Jt3.0 has been released. Jt is a pattern oriented framework for the rapid implementation of Java applications. Jt has been utilized in several large mission critical systems. Jt implements many well-known patterns including Data Access Objects (DAO), GoF design patterns and J2EE patterns. Jt3.0 features several enhancements to the Jt components and a version of the Jt automated Wizard (JtWizard). The Jt Wizard is an application built on top of the Jt framework that provides automated capabilities for generating framework applications. The Jt Wizard is able to automatically generate application modules based on several design patterns including Jt Messaging, DAO, MVC and GoF. The current Jt Wizard implementation provides integration with MVC Struts and DAO Hibernate. DAO mapping files, Struts configurations files, Views (JSPs), Java classes are automatically built by the Jt Wizard. The Jt Wizard is also a reference web application implemented using the Jt framework. The framework addresses the following goals and requirements: A) The pattern oriented framework implements and/or facilitates the implementation of well-known design patterns like GoF design patterns and J2EE Design patterns. The framework itself is conceived and implemented based on design patterns (from the ground up). The framework facilitates and accelerates the implementation of applications based on design patterns. B) The framework architecture is based on a messaging design pattern: framework objects is able to interchange information and perform computations by sending, receiving and processing messages. A messaging API provides strong encapsulation and loose coupling; framework components can be easily plugged into complex framework applications using a “lego/messaging” architecture. The framework takes full advantage of the power and simplicity of the messaging design pattern. C) The framework lego/messaging architecture provides transparent access to remote components: remote framework objects is treated as local objects. Design patterns implemented by the framework (adapters, remote proxies and facades) make this posible by hiding the complexities associated with remote APIs. D) The framework provides transparent integration with other technologies via framework adapters, proxies and the implementation of related design patterns. These technologies include BPM, DAO implementations, MVC implementations, EJBs, JMS, XML and Web Services. E) The framework is designed to be lightweight and fast in terms of performance (low overhead). F) The framework messaging/lego architecture should improve and simplify design/development efforts. There should be a tight correspondence between UML design diagrams and the framework messaging based applications and components needed for the implementation. Ideally, the framework provides wizards and automated capabilities for generating framework applications. Framework components should be easily added to BPM process diagrams. In future versions of the framework, it should be possible for applications to be generated directly from the UML design diagrams. G) The framework messaging architecture facilitates testing and debugging efforts. The framework provides capabilities for testing components independently (each component as a unit) by sending messages and verifying the reply (output) messages. H) In order to provide additional productivity benefits, the framework is integrated with open source IDEs. Additional features include: * Implemented J2EE design patterns include J2EE business delegate, J2EE Session Facade, J2EE Service Locator and J2EE Value Object. * Web Services integration via the implementation of Web Services adapters and proxies. The Jt messaging API greatly simplifies the development and deployment of web services. * Integration with business process modeling (BPM). A jBPM adapter is provided within the Jt framework. jBPM is an open source implementation of the BPM technology. A Jt application can now be modeled using a process graph. This provides users with a very powerful way of modeling business processes. * Integration with the MVC (Model View Controller) design pattern and Ajax. Universal Jt components and adapters provide a transparent interface between the Jt framework API and these technologies. The business logic (controller piece) can be implemented using Jt framework components and/or BPM business processes. * Integration with the Hibernate implementation of Data Access Objects (DAO). A Jt adapter provides a transparent interface between the Jt framework and Hibernate DAOs. A native Jt DAO implementation is also provided. Additional DAO strategies can be easily plugged in. * JDBC integration via a JDBC adapter. * The Command pattern implementation supports a request log, a queueing mechanism and undoable operations. * JavaMail API integration via the implementation of a JavaMail adapter * Integration with J2EE Enterprise Java Beans (EJBs) via Jt Adapters and proxies. EJB clients are able to gain transparent access to remote framework objects. No need to deal with the complexities of EJB application development. An implementation of the J2EE Service Locator pattern is also provided. * Easy customization of framework applications. This is done via resource files: object attributes can be automatically loaded from a resource file. * Java Server Pages (JSP) integration. * Integration with the XML APIs via XML adapters, helpers and built-in bean/XML mapping capabilities. * Integration with the asynchronous Java Message Service (JMS). Jt messages can be sent and received via JMS adapters. * Built-in logging/debugging capabilities. Messages between framework objects are automatically logged. This simplifies the debugging and testing tasks. * Built-in testing capabilities. * Efficient and lightweight in terms of memory utilization. * The framework can be easily extended by implementing additional Jt adapters and helpers. * The Jt Framework provides a consistent way of handling and logging application messages, errors and exceptions. * Proven technology. The Jt framework has been used for the development of several large enterprise applications. * Cross-platform, implemented using JavaTM technology. * Integration with the Eclipse environment. * Runs on any J2EE compatible application server. Jt online documentation can be found at http://jt.dev.java.net/servlets/ProjectDocumentList For additional information please refer to http://jt.dev.java.net. You can join the Jt mailing list here.