|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 102
Messages: 102
Messages: 102
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Red Hat, Exadel partner around open source tools for JBoss
Exadel, a provider of rich application components and tooling, today announced plans to open source its commercial products, Exadel Studio Pro and its RichFaces component library, to JBoss.org under LGPL. As part of the partnership with Red Hat, Exadel will also migrate its Ajax4jsf project from java.net to JBoss.org. Red Hat's Gavin King will lead efforts to integrate the three projects into the JBoss Enterprise Middleware Suite (JEMS).
TheServerSide.com sat down with Sacha Labourey, CTO of Red Hat's JBoss Division, to learn more about the partnership with Exadel, and its effects and benefits for the enterprise and the open-source communities.
TheServerSide.com. What is the extent of the partnership between Exadel and Red Hat?
Sacha Labourey. The Red Hat and Exadel partnership is twofold. First, Exadel will open source its commercial products -- Exadel Studio Pro and RichFaces -- at JBoss.org as Red Hat Studio Developer and JBoss RichFaces, respectively. Exadel is also moving its popular Ajax4jsf project, currently hosted on java.net, to JBoss.org, where it will become JBoss Ajax4jsf. Second, Red Hat and Exadel will continue developing the three projects going forward, including integration with existing JBoss platform technologies such as JBoss Seam. This ongoing development will be done under JBoss's leadership.
In 2007, one of our engineering focus is on the "JEMS Grand Unification". This unification takes place at the management, tooling and programming model. The management part is something that was already initiated about 2 years ago with JBoss ON and led by Greg Hinkle and Richard Friedman. The tooling aspect has now been initiated by this partnership and Seam is taking care of the programming model.
The very good news here is that Gavin King is taking a leadership role in that "Grand Unification" and will lead the vision of these two strategic aspects: tooling and programming model. Given Gavin's credibility in giving back productivity to the developers, you should expect great innovations. I am personally thrilled to see Gavin take on that strategic responsibility.
TSS. What's the main benefit that your users can expect from this partnership?
SL. For the first time, developers will have access to a very rich Eclipse-based toolset that is entirely available in open source. Now, developing on any platform, and in particular the JBoss platform, will be easier than ever, as developers benefit from an integrated, highly productive, and rich development experience. Also, thanks to the Exadel engineers, you should expect an acceleration in the number of JEMS plugins that will be made available in Red Hat Developers Studio.
TSS. Which products are included in the partnership?
SL. Ajax4jsf, currently one of the most popular open source projects on java.net, will become JBoss Ajax4jsf. Ajax4jsf is a rich component development framework that extends the benefits of JSF to AJAX development. JBoss Ajax4jsf is available since Monday, March 5 at JBoss.org.
RichFaces, currently a commercial product, will become JBoss RichFaces. **RichFaces** is a rich component library for JSF built on top of Ajax4jsf, an advanced framework for easily integrating AJAX capabilities into business application development. RichFaces allows users to quickly incorporate AJAX and flexible design through skinnability into their JSF applications. JBoss RichFaces is available in open source, for the first time, since March 5 at JBoss.org.
Exadel Studio Pro, currently a commercial product, will become Red Hat Developer Studio. Exadel Studio Pro is an Eclipse-based development environment combining visual and source-oriented development approaches with support for multiple open source technologies and frameworks, including JSF, Struts, Hibernate, MyFaces, Oracle ADF, Shale, Spring, and others. Red Hat Developer Studio will be available in open source by summer 2007.
TSS. Does the partnership also include services, or will Exadel continue to operate that part of their business independently?
SL. Exadel will continue to provide professional services around these three products. This was already a very strong part of Exadel's business. By moving software development and product management to Red Hat, Exadel can focus exclusively on this core strength.
TSS. What are the benefits for enterprise development organizations regarding this partnership?
SL. Enterprise developers now have a mature, Eclipse-based development environment that is entirely available in open source. Though Red Hat will be optimizing Red Hat Developer Studio for the JBoss platform, we will continue to support our tools on other platforms like WebSphere and WebLogic.
This partnership also lays the groundwork for a much more comprehensive developer program that Red Hat will launch in conjunction with the availability of Red Hat Developer Studio. This program is aimed at enterprise developers that want to leverage our 108 developer portal (launched in May 2006 and in beta now), certified tools and runtimes for out of the box development, and subscriptions which provide access to valuable support and services. We will announce this new program in the next months, so stay tuned.
TSS. And the benefits for independent and open-source developers?
SL. Independent and open source developers also benefit from having a high caliber Eclipse-based developer toolset available in open source. They can download and use Red Hat Developer Studio, JBoss Ajax4jsf, and JBoss RichFaces in the same manner that they use other JBoss.org projects. They are welcomed to contribute to the future development of these projects. Because we will be using GPL-based licenses -- a first for the tools space -- these projects will remain in open source and available to all developers.
TSS. Can you provide a time line for the Red Hat Developer Studio?
SL. Because Exadel Studio Pro is a more mature product that's been in development for several years, it has a much larger code base for us to go through, sanitize, and prepare for open sourcing. We expect to release Red Hat Developer Studio under a GPL-based license by summer 2007.
TSS. The products are released as open-source under the LGPL license rather than Eclipse's. Are you concerned that this may turn off potential users due to perceived issues of redistribution involved in the LGPL/GPL licenses? Some enterprises see the Eclipse license as more IP-friendly.
SL. No, in fact. With a GPL-based license, users can have confidence that these products will always remain in open source, available for all to use. The license ensures that any changes/additions to the code base go back to open source, thus making for a much more stable distribution in the long run.
Even though, some companies (usually proprietary software vendors) have a vested interest to generate FUD around the GPL and LGPL licenses, most of the open source projects are based on these two licenses. And as you know, for a few months now, this includes Java SE (OpenJDK).
TSS. Will users incur in any redistribution issues for code produced by these tools due to the licensing changes?
SL. No, absolutely no changes. What you generate is your code.
TSS. What is the upgrade path for existing JBoss and Exadel customers?
SL. Starting March 5, Exadel is making an extended evaluation version of Exadel Studio Pro available at no cost. This evaluation version should expire around the time that Red Hat Developer Studio is available in open source. To get the extended evaluation of Exadel Studio Pro, visit http://jboss.org/projects/rhdevstudio
TSS. Are there any end-of-life support issues for existing Exadel customers after the transition?
SL. No, any Exadel customer will get what they are expecting from Exadel.
TSS. What's next?
SL. While we cannot talk about those yet, you should expect more announcements in the next months, so stay tuned.
The partnership with Exadel was a great example of collaboration inside Red Hat, 6 months after the merger: this partnership has been initiated and led by Bryan Che (PM for developers at Red Hat) and Ram Venkataraman (PM for JBoss). While engineering wasn't leading that partnership, we remained in close touch with Ram and Bryan. We think it is a fantastic opportunity.
I'd like to also thank some people that have been involved at various levels and helped make it happen on time for EclipseCon: Max Andersen, Gavin King, Ryan Campbell, Eric Brown, Bob McWhirter and James Cobb.
|
|
|
Message #228564
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
Very cool. I hope the new IDE will add integrated support for Seam soon, that should make it the perfect combo: Ajax4JSF + RichFaces + Seam.
|
|
|
Message #228567
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
I might be wrong.. But sounds to me like Exadels business hasn't worked out, and they are winding down business by open sourcing and letting JBoss/Red Hat take over the development..
- 2 years ago, Exadel Pro was priced at $99.
- Recently prices where hiked up a few hundred percent.
- Now their open sourcing the lot.
Sounds to me like the business model never really worked out.
But Exadels stuff does have some promise, so not being an Exadel shareholder, I'm happy to see it open sourced!
|
|
|
Message #228568
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
Me thinks that compititon from MyEclipse has caused Exedel to make this move.
|
|
|
Message #228570
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
I might be wrong.. But sounds to me like Exadels business hasn't worked out, and they are winding down business by open sourcing and letting JBoss/Red Hat take over the development..
Seems like their business has actually worked out pretty damn well, given that we just paid them a whole bundle of money to get this deal done. ;-)
This is not a typical case of a commercial vendor deciding to give away a product they couldn't sell, in a last-ditch attempt to get users. Rather, this is an acquisition of successful technology, for money. It follows the model of JBoss Transactions, which was acquired from Arjuna, and JBoss ESB, which was acquired from Aviva.
To be clear, development of these products is most certainly not being "wound down" - the deal very explicitly specifies the resources that will go into ongoing development of RichFaces and the tooling.
I have absolutely zero doubt that we will be able to build a super-vibrant community around these excellent projects, now that they are open source, hosted at JBoss, and being integrated with the Seam and Hibernate communities.
We've wanted to do something like this for a Long Time :-)
|
|
|
Message #228571
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
Seems like their business has actually worked out pretty damn well, given that we just paid them a whole bundle of money to get this deal done. ;-)
I stand corrected, although the pattern of pricing to open source would have implied something completely different. :)
I used to be an Exadel customer, the product sure had a lot of promise, however it was plagued by some extremely peculiar bugs and performance issues when I was using it (the IDE would freeze to build the workspace for minutes at a time). This caused me to drop Exadel after a while, as the pain outstripped the benefit.
..so, I hope you take care of it and make it fulfill it's promise!
|
|
|
Message #228572
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
Me thinks that compititon from MyEclipse has caused Exedel to make this move.
Hehe. I know some guys from the JBoss IDE team who are just itching for some competition with MyEclipse. :->
Some of us believe that Genuitec are skirting waaay to close to an LGPL violation over bundled modifications to Hibernate Tools. Repeated attempts on our part to get them to modify their behavior in this respect as resulted in nothing but empty promises. That's one reason why we decided to go GPL on the Exadel toolset - to break the Genuitec model of "take but never give back".
|
|
|
Message #228573
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Congrats!
I always knew that something like that could happen.
The community needs only ONE faces library. Gavin did it with persistence, I hope he can do it again.
And please, aim your efforts on constructing a solid and stable library with useful components, don't waste time in visual editors.
|
|
|
Message #228574
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Mac OS X support
I hope Mac OS X support is on the way. Eclipse and Java are available for the Apple platform, last I checked.
|
|
|
Message #228575
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
This is great news - Exadel has always had a great product for JSF development (the lack of OS X support is unfortunate, however), and I'm excited to see where the product goes after the partnership with JBoss.
The feature I think would be most useful for JSF/Seam development is allowing the view layer to participate in refactoring operations - ie, if I refactor a method name on a managed bean, I have the option of having that changed in all the xhtml pages it is referenced.
Does anyone know if Exadel Studio Pro/Red Hat Developer Studio already supports this or will support it in the future? I've been trying all morning to download a trial copy to see the new features, but it looks like everyone else had the same idea :)
|
|
|
Message #228577
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mac OS X support
I hope Mac OS X support is on the way.
Since so many of us at JBoss are using Mac now (including me), this is also a high priority for us ;-)
|
|
|
Message #228578
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mac OS X support
I hope Mac OS X support is on the way. Eclipse and Java are available for the Apple platform, last I checked.
Actually, I was just looking through the forums and found this:
http://forum.exadel.com/viewtopic.php?t=4822
It looks like Exadel works unofficially on OS X (except for the visual designer), so I imagine we'll be able to use the new Red Had Developer Studio in a similar manner until full OS X support comes out.
|
|
|
Message #228580
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
The feature I think would be most useful for JSF/Seam development is allowing the view layer to participate in refactoring operations - ie, if I refactor a method name on a managed bean, I have the option of having that changed in all the xhtml pages it is referenced.
Yes, we are prioritizing EL navigation/search/refactoring/autocomplete/errors/quickfix for both JSF managed beans and Seam components. A lot of this is already in the Exadel codebase. Note that this goes beyond just the view, including other Seam artefacts such as jBPM orchestration, pages.xml, components.xml, etc.
|
|
|
Message #228582
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Better than MyEclipse
FWIW
Beyond having a better license, what would make something better than MyEclipse for me would be that if the whole is truly greater than sum of its parts. That is, rather than just being a bundle of plugins, there needs to be a real unified vision full of the necessary "opinions" and "conventions" to create a much more productive environment.
|
|
|
Message #228583
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better than MyEclipse
Beyond having a better license, what would make something better than MyEclipse for me would be that if the whole is truly greater than sum of its parts. That is, rather than just being a bundle of plugins, there needs to be a real unified vision full of the necessary "opinions" and "conventions" to create a much more productive environment.
Precisely.
This requires framework and a toolset to be developed hand-in-hand by the same team.
|
|
|
Message #228584
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better than MyEclipse
FWIW
Beyond having a better license, what would make something better than MyEclipse for me would be that if the whole is truly greater than sum of its parts. That is, rather than just being a bundle of plugins, there needs to be a real unified vision full of the necessary "opinions" and "conventions" to create a much more productive environment.
I think MyEclipse has always tried to compete based on price - what is it, like $25 for a copy? Unfortunately, they've always been very slow to support new technologies (at least the ones we use), which lead me to drop all our licenses.
Honestly, I'd rather pay $2,500 for a good IDE that made me significantly more productive than $25 for one that was of marginal use.
|
|
|
Message #228586
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better than MyEclipse
Lucky you, you can spent 2'500 on IDE. Fortunately you do not have to do so. It all LGPL now. :-)
Best,
Igor Shabalov.
|
|
|
Message #228587
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mac OS X support
Yes, full support for OS X is in our top priority list.
We have preliminary support for OS X (without VPE - Visual Page Editor) and we will add VPE at next major release time frame (which is few months from now)
Best,
Igor.
|
|
|
Message #228588
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
seeing as how Exadel is eclipse based, I don't suppose you guys have it in your plans to develope the equivalent for netbeans platform do you?
|
|
|
Message #228590
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
tutorial at 1PM at Eclipsecon
Any chance this could get recorded and made available via internet?
Further: congratulation - I'm looking forward to enjoy this together with Seam. Just don't waste any time with the visual stuff until content & refactoring assist, which is IMHO much more important, really work.
|
|
|
Message #228591
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
Congratulations on this move, Gaving (and Red Hat).
Java has a lot of interesting and world-class APIs and libraries, but they rarely come with the sort of integrated dev tools that allow them to be used at maximum productivity.
I am glad to see Red Hat is focused on delivering exactly this type of integrated experience for developers.
|
|
|
Message #228592
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
Oops, I meant Gavin...not Gaving (nice Viking name, though) :-)
|
|
|
Message #228593
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
One of the things I really liked about Exadel was its Hibernate tooling.
|
|
|
Message #228594
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
Congratulations on this move, Gaving (and Red Hat).
Don't congratulate me, I'm not the one who worked on this deal. If anyone at JBoss deserves thanks, it is Ram Venkataraman.
|
|
|
Message #228595
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
True. But I am just excited to see someone have a dedicated vision to bring Ajax-enabled JSF (for UI) with Seam (for business logic) and JPA (for DB access) into one common development environment in a way that maximizes productivity.
|
|
|
Message #228596
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
I wonder if this explains why BEA is now selling their $899 BEA Workshop Studio for $99 until March 23?
I've been wanting to try BEA/Nitrox for some time but couldn't justify the $899 price.
Ain't competition great!
Here's the advertisement from the February 23, 2007 EclipseZone:
Get the #1 Commercial Eclipse tool for $99 until March 23rd!
We'd like to thank the community for voting BEA Workshop Studio the #1 Commercial Eclipse IDE in 2006 with a online-only promotional pricing of $99.00 USD, support not included. Find out how unique features like Spring artifact generation from EJB3-Hibernate, and AppXRay™ make this the #1 tool on the market.
Buy it now using promotional code: TSSpecial99
|
|
|
Message #228597
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Exadel
Always had for me this basic geniality with some of the tools being the best in the Eclipse space,
and they always failed by the buggyness of the entire package.
The Price hike once the underlying WTP went out of beta (and still was unusable) made me go away from the platform and revert back to myeclipse which could not do that much in JSF but at least worked 100% at the parts I needed.
I just wonder how the entire package is nowadays, I always thought, if the rest of the ide (db tools, server management, generally the underlying wtp) was as good as their html and jsf editors this ide would have been awesome.
Anyway this is great news, especially since I am moving towards facelets currently!
|
|
|
Message #228598
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
I wonder if this explains why BEA is now selling their $899 BEA Workshop Studio for $99 until March 23?
I've been wanting to try BEA/Nitrox for some time but couldn't justify the $899 price.
Ain't competition great!
Here's the advertisement from the February 23, 2007 EclipseZone:
Get the #1 Commercial Eclipse tool for $99 until March 23rd!
We'd like to thank the community for voting BEA Workshop Studio the #1 Commercial Eclipse IDE in 2006 with a online-only promotional pricing of $99.00 USD, support not included. Find out how unique features like Spring artifact generation from EJB3-Hibernate, and AppXRay™ make this the #1 tool on the market.
Buy it now using promotional code: Special$99.00
How is Nitrox btw. 99$ is even a price I would consider (since I am working mostly privately in the JSF and JPA space I am on a budget here)
|
|
|
Message #228600
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
So far I see:
To implement simple Web2.0 UI with JSF developer must
Learn JSF + Facelets and find out that it makes him write a lot of stuff like new forms writing language,backing beans, as well as force to use huge XML mappings. To get rid of half of mappings and replace backing beans with other backing beans developer must learn SEAM and find out that it is not a peace of cake to run SEAM on anything but JBOSS4. After that he understands that he still haven't done anything that makes his application look and feel like Web2.0 application. And now he must learn IceFaces or NetAdvantage or Ajax4JSF. uuuuf.
Quite a steep learning curve, isn't it?
Did I miss something?
Probably yes. I missed unit testing for UI, clusterization problem, HARRRRD to DEBUG UI (does your IDE provide good means to debug JSF code? Place your ads here ;-) ).
What will happen with Java developer if he choose different Web2.0 component based framework, let's say GWT.
He will be able understand framework in one day.
With GWT he will be able to write UI in a language he already knows - java.
He will be able to do unit testing for UI.
He will be able to debug UI just like you debug your AWT/SWT/SWING application.
He won't write 100K xml mappings files.
He will be able to store client state on client(in this case he won't need to use distributed cache and the clustering will be peace of cake).
He won't have to learn complex client states (just like he does when he develops AWT/Swing applications).
Did I miss something?
Probably there are better choices?
|
|
|
Message #228601
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Congrats!
I always knew that something like that could happen.
The community needs only ONE faces library.
One of the great strengths of Java over alternatives is choice. The whole point of standards like JSF and JPA is to allow competing implementations, which is good for both vendors and developers.
|
|
|
Message #228602
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
So far I see:
To implement simple Web2.0 UI with JSF developer must
Learn JSF + Facelets and find out that it makes him write a lot of stuff like new forms writing language,backing beans, as well as force to use huge XML mappings. To get rid of half of mappings and replace backing beans with other backing beans developer must learn SEAM and find out that it is not a peace of cake to run SEAM on anything but JBOSS4. After that he understands that he still haven't done anything that makes his application look and feel like Web2.0 application. And now he must learn IceFaces or NetAdvantage or Ajax4JSF. uuuuf.
Quite a steep learning curve, isn't it?
Did I miss something?
Probably yes. I missed unit testing for UI, clusterization problem, HARRRRD to DEBUG UI (does your IDE provide good means to debug JSF code? Place your ads here ;-) ).
What will happen with Java developer if he choose different Web2.0 component based framework, let's say GWT.
He will be able understand framework in one day.
With GWT he will be able to write UI in a language he already knows - java.
He will be able to do unit testing for UI.
He will be able to debug UI just like you debug your AWT/SWT/SWING application.
He won't write 100K xml mappings files.
He will be able to store client state on client(in this case he won't need to use distributed cache and the clustering will be peace of cake).
He won't have to learn complex client states (just like he does when he develops AWT/Swing applications).
Did I miss something?
Probably there are better choices?
That's a good questions. Right now, I am exploring our next generation of front-end technology. Yesterday, I spent a few hours playing with GWT, putting up a simple page that uses a service to integrate with an existing Spring/Struts/Hibernate based app's business object.
Except for the 70% of that time spent figuring out how to get the thing to deploy on Tomcat, it seemed pretty straightforward. The next step will be to put a GWT page into an existing app and see how this goes.
Then, repeat the process with JSF/MyFaces/Icefaces.
What's next, zk?
|
|
|
Message #228605
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
Not much ... I've always thought of JSF as being little more than JSP 3.0. There's some work on integrating Seam and GWT -- Seam is a whole lot more than JSF.
Of course once you treat your web app as a monolithic event-driven GUI thing, one wonders what the advantage of GWT is over Swing. Certainly the programming model doesn't appear to be any less verbose.
|
|
|
Message #228608
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
For one I'd like to see a lot more components in the GWT. The current code base is pretty sparse and nowhere near compares to some JSF libraries out there.
After that, I think it is, in a large part, a matter of preference. If you're a swing programmer I think GWT is far more intuitive.
I for one have quite often found myself working with a team where the site was designed as an HTML prototype by a design team and our job was to add life to it. Doing this with JSF, or even JSP for that matter, is a lot easier than doing it with GWT.
|
|
|
Message #228610
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
JSF and GWT are not competitive, but complementary technologies. I explained our position in the article on the server side site time ago:
I agree with author and totally disagree with you.
Both technologies are used in same problem domain.
Building Web2.0 applications.
Yes, they have different approach.
With GWT it is simple.
With JSF it is complex and error prone.
Learning JSF,Facelets,ICEFaces + SEAM to make simple WEB2.0 forms works sounds like overengineering .
PS You article doesn't show WHY we should use JSF. What are the benefits of JSF?
And doesn't it look strange that your “framework” made the size of simple GWT application 2 times bigger in case you include all mapping files? ;-)
--Mark
|
|
|
Message #228611
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Further with Red Hat Developer Studio
Precisely.
This requires framework and a toolset to be developed hand-in-hand by the same team.
Yes.
I just recently spent some time with .NET and one can see how someone developing both together makes possible the otherwise impossible.
You have some great open source frameworks to start with. And it's obvious that you know that JEE productivity needs more than just wizards in an IDE, it needs newer frameworks like SEAM or other improvements that can't happen by an IDE alone. (And vice versa.)
Anyway, this is all good news. Congratulations to all of you.
I look forward more great stuff.
|
|
|
Message #228612
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
So far I see:
To implement simple Web2.0 UI with JSF developer must
Learn JSF + Facelets and find out that it makes him write a lot of stuff like new forms writing language,backing beans, as well as force to use huge XML mappings. To get rid of half of mappings and replace backing beans with other backing beans developer must learn SEAM and find out that it is not a peace of cake to run SEAM on anything but JBOSS4. After that he understands that he still haven't done anything that makes his application look and feel like Web2.0 application. And now he must learn IceFaces or NetAdvantage or Ajax4JSF. uuuuf.
Quite a steep learning curve, isn't it?
Did I miss something?
Probably yes. I missed unit testing for UI, clusterization problem, HARRRRD to DEBUG UI (does your IDE provide good means to debug JSF code? Place your ads here ;-) ).
What will happen with Java developer if he choose different Web2.0 component based framework, let's say GWT.
He will be able understand framework in one day.
With GWT he will be able to write UI in a language he already knows - java.
He will be able to do unit testing for UI.
He will be able to debug UI just like you debug your AWT/SWT/SWING application.
He won't write 100K xml mappings files.
He will be able to store client state on client(in this case he won't need to use distributed cache and the clustering will be peace of cake).
He won't have to learn complex client states (just like he does when he develops AWT/Swing applications).
Did I miss something?
Probably there are better choices?
That's a good questions. Right now, I am exploring our next generation of front-end technology. Yesterday, I spent a few hours playing with GWT, putting up a simple page that uses a service to integrate with an existing Spring/Struts/Hibernate based app's business object.
Except for the 70% of that time spent figuring out how to get the thing to deploy on Tomcat, it seemed pretty straightforward. The next step will be to put a GWT page into an existing app and see how this goes.
Then, repeat the process with JSF/MyFaces/Icefaces.
What's next, zk?
If you want to reproduce your Struts application try Stripes.
If you need web2.0 GWT seems the best.
Echo 2 uses same approach but it is too slow.
--Mark
|
|
|
Message #228614
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
I haven't had a chance to use BEA Workshop Studio/Nitrox yet. A year ago I looked for reviews comparing Nitrox to Exadel Studio Pro, but found nothing comparing the two.
My current project uses Adobe Flex 2.0 so it will be a while before I get to use BEA/Nitrox on a real project, but for $99 I'll buy it now.
|
|
|
Message #228615
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
Not much ... I've always thought of JSF as being little more than JSP 3.0.
There are some comparisons that are so odd, it is hard to know where to start commenting.
"JSF little more than JSP 3.0"??
|
|
|
Message #228617
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Both [JSF and GWT] are used in same problem domain. Building Web2.0 applications.
As much as I like GWT, it requires Javascript + XHR. I had thought that JSF does too, but JSF proponents have explained -- and not just once -- that JSF in its puriety does not depend on Javascript. Therefore JSF app can be compatible with older or less capable browsers and more accessible. It is another question how many users have their Javascript disabled.
On the other hand, I believe JSF could have become a better spec/framework if it were in fact made on top of JSP, not as a parallel spec. They are so different that on early stages of JSF development some suggested to part with JSP at all. I don't get why J2EE needs two similar but different view technologies. The latest JSP 2.1 spec tries to integrate JSP and JSF better, but these technologies are still different.
Nevertheless, I want to congratulate Exadel and Red Hat guys for strengthening Java server market. Appears that with JBoss, Seam, Hibernate, RichFaces and with development tools, Red Hat can become a viable one-stop shopping mall. This may threaten other Java frameworks but should make server-side Java more attractive when compared to well-integrated ASP.Net offering.
|
|
|
Message #228619
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
I agree with author and totally disagree with you.
Both technologies are used in same problem domain.
Building Web2.0 applications.
I'm going to have to go ahead and disagree with you there.. JSF is NOT a Web 2.0 app framework - it is a web application framework. Due to its pluggable nature, you can add Web 2.0 capabilities (ajax4jsf) or even make complete Web 2.0 apps (ICEfaces). Comparing JSF to GWT to is apples and oranges - comparing ICEfaces to GWT might make a little more sense.
At any rate, I think GWT is cool, and some of the widgets might be useful, but I think the approach JSF takes is better in a lot of cases. Writing your webapp in Java kind of keeps your designers less in the process. With JSF, all our view code is in xhtml, meaning that it is very easy for designers to go in and modify look and feel of the app, change text, move stuff around, etc..
There very well may be specific cases where GWT is a better choice for a project, but to argue that it is generally a direct "competitor" to JSF is not even remotely accurate.
|
|
|
Message #228618
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Thanks Sergey, I'm glad you saved those links :-)
There are a lot of overlaps between GWT and JSF. But there are also a lot of potential synergies. Very frequently in the open source world, people become emotionally invested in false dichotomies ("why use X when you can just use Y?"). It's even easier to fall into this mindset when both X and Y are fairly complex -- GWT doesn't exactly have a short learning curve if you're just getting started with it! But over time, as more examples of integrating GWT and JSF come out, and as the tools for both GWT and JSF get better, all of those barriers to entry will start to fall. Once upon a time, JSP was black magic too....
I think this Exadel / JBoss announcement is great. The Java world has really needed an open source answer to .NET, and I think this is a big step in the right direction. That said, it's true that any JSF IDE is going to wind up building apps that keep most of their state on the server. Seam makes that a whole lot easier to manage (which is a huge Seam selling point -- all your persistence synchronization problems are greatly alleviated), but it's still a potential scalability issue.
GWT, on the other hand, keeps all your state on the client, but is essentially unsearchable (since it's all Javascript, search engines can't see it) and is designed using a custom widget set, not using HTML / DOM tools. Also, since all your state is on the client, you have to manage all the client/server state management yourself -- you've got to prune your object graph when sending from the server, and then you've got to reassociate everything yourself when replying from the client.
Of course, all of that is fixable with more software :-) Over time, there's no reason why the GWT / JSF / Seam integration can't be made tighter and tighter, to the point where one day you can design GWT applications inline in your JSF IDE, and to where the GWT client state management can use infrastructure support to simplify all the reassociation / synchronization problems. This is particularly possible because GWT is based on Java source, so (especially once GWT supports Java 5) you can use Java components in your GWT app, and you can write Java state management code that can run on both client and server. (And of course GWT's huge advantage over Swing is that all major browsers can run it with no JDK.)
Anyway, all of this is really to say that JSF and GWT have many overlaps but different focuses, and that there are all kinds of integration possibilities that haven't been deeply explored yet. Once GWT, JSF, and Seam can interoperate at a basic level, those possibilities become a lot more accessible.
|
|
|
Message #228620
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Learning JSF,Facelets,ICEFaces + SEAM to make simple WEB2.0 forms works sounds like overengineering .
If that's all you're doing, it probably is overengineering. But some people are doing a lot more than that.
Your post above reminds me of someone saying, "Learning Hibernate just to store some form data in a database sounds like overengineering." Well, yes, it probably is. That doesn't mean there aren't a lot of business problems that do need Hibernate.
Large frameworks are built for those who need them. All technologies have tradeoffs. The best situation is when major frameworks have good interoperability, so each can be used (or not used) where most appropriate, and so they can be integrated gracefully when that makes sense for the business problem.
|
|
|
Message #228621
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Posted by Spencer Uresk:
With JSF, all our view code is in xhtml I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.
Posted by Rob Jellinghaus:
GWT, on the other hand, keeps all your state on the client, but is essentially unsearchable (since it's all Javascript, search engines can't see it). Why would you need searchable application output? Websites should be searchable, webapps don't have to.
|
|
|
Message #228623
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Websites should be searchable, webapps don't have to.
One site should be searchable, but the other ones might be not. Do not say you believe all sites equal to each other and all of them are just a bunch of hyperlinked text page. The world is not b/w
|
|
|
Message #228624
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.
Not really. The only time you use a JSF tag is when you are using a component. So, for example, if you have someone filling out a registration form, typically you'll only have a few components: one for the form, one for each input element, and one for the submit.
So, the upside is that a designer can hand me an html prototype (so long as it is xhtml compliant - which it should be anyway ;) )of this registration form, and I can simply replace the form elements with JSF tags, and then I am done with the view code.
Should a designer decide to change the layout, change some text, or whatever, then they can just edit that same xhtml file. It is even pretty simple and straightforward for someone with no Java experience to change certain attributes on JSF components by simply editing attributes in the tag.
Now, you certainly can run into situations where you have a really complex or poorly designed custom component that makes it difficult for a designer to work with, but the vast majority of the time, I've found it quite possible to let the Java devs do their job and the designers do theirs :)
|
|
|
Message #228627
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
I don't get why J2EE needs two similar but different view technologies. The latest JSP 2.1 spec tries to integrate JSP and JSF better, but these technologies are still different.
That is because JSF is not a view technology. It is a framework that can use different technologies to render the view. JSP is just one of these. Perhaps it would have been wiser for JSF to use a different approach for its HTML rendering.
|
|
|
Message #228628
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
can u CPL please?
hi all,and congrates to JBOSS
ok,i know that it,s ur assets and it's completely ur rights to do what u want with it ,but in order to use it (my company) it has to be an apache friendly licence (oh... lawyers) and as i know, the CPL has the same spirit as LGPL so can i ask u to consider a switch?
actually if u ask the public , alot will have the same request
thanx in advance
joe
|
|
|
Message #228632
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: can u CPL please?
Hi Joe,
Sorry, but that will not happen for the new tooling. The GPL-based licenses is there to make sure it stays in the opensource space and won't be hijacked by companies that leaches on the good faiths in opensource.
JBoss and hence Red Hat have had great sucess with keeping software available as opensource by using the LGPL license for projects like JBoss AS, Hibernate, Seam, etc. and it has great adoption.
p.s. you do know that the next version of Java is being made available under GPL; will that also prevent your company from developing java based software ?
/max
|
|
|
Message #228634
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.
Not really. The only time you use a JSF tag is when you are using a component. So, for example, if you have someone filling out a registration form, typically you'll only have a few components: one for the form, one for each input element, and one for the submit.
So, the upside is that a designer can hand me an html prototype (so long as it is xhtml compliant - which it should be anyway ;) )of this registration form, and I can simply replace the form elements with JSF tags, and then I am done with the view code.
Should a designer decide to change the layout, change some text, or whatever, then they can just edit that same xhtml file. It is even pretty simple and straightforward for someone with no Java experience to change certain attributes on JSF components by simply editing attributes in the tag.
Now, you certainly can run into situations where you have a really complex or poorly designed custom component that makes it difficult for a designer to work with, but the vast majority of the time, I've found it quite possible to let the Java devs do their job and the designers do theirs :)
I think the original poster was referring to the verbatim problem in jsf 1.0 and 1.1 where you had to push the thml code into verbatim to be placed correctly.
This problem is solved, in JSF 1.1 you can use facelets instead of jsp as view technology, jsf 1.2 does not need verbatims anymore as well.
Facelets also have the advantage that you can work with standard components and you can map them into their jsf counterparts with a jsfc attribute in the tag, which is even designer friendlier.
But in the end I do not see a big deal in giving jsf to designers, dreamweaver tools are available so that dreamweaver can work with facelets and jsf and that is basically what most designers need, because they rely on this program heavily.
|
|
|
Message #228637
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Posted by Spencer Uresk:
With JSF, all our view code is in xhtml I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.
Posted by Rob Jellinghaus:
GWT, on the other hand, keeps all your state on the client, but is essentially unsearchable (since it's all Javascript, search engines can't see it). Why would you need searchable application output? Websites should be searchable, webapps don't have to.
Hi Micheal,
You're partially right and partially wrong. The layout using facelets is in XHTML and of course the visual aspect is provided by the css but of course the components are designed using Java or Velocity in my case.
This makes the collaboration with a web designer a lot more simple. For instance, in my previous job, the web designer used to provide me some XHTML prototypes and the only thing left to do was to give life to the page, replacing the at the moment "static" components by JSF's one. It's quite easy using facelets.
|
|
|
Message #228644
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
For one I'd like to see a lot more components in the GWT.
Thanks for an opinion.
Can you please list components that You use in your JSF applications that GWT miss?
After that, I think it is, in a large part, a matter of preference.
I agree, everything is matter of preference.
Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)?
Do you like to spend a month on education of your team (JSF,Facelets,SEAM + MyFaces,HisFaces,YourOwnFaces) or you want to have a framework that allows to do same things but doesn't have such steep learning curve (GWT)?
If you're a swing programmer I think GWT is far more intuitive.
Yes, indeed. But I think it is more intuitive in anyway because if JSF approach was more intuitive we'd already have such framework over AWT/SWT/SWING.
Here is my experience.
I spent one week to teach PHP programmer to write web apps with with GWT(she knew nothing about debugger at that time, knew nothing about AWT/Swing for sure, she new nothing about servlets/jsp).
After that she was able to do quite complex stuff including Trees, Tables with Paging and even Tree Tables ;-).
This proves that using GWT is quite simple even if you haven't written a single Swing/AWT/SWT application.
I for one have quite often found myself working with a team where the site was designed as an HTML prototype by a design team and our job was to add life to it. Doing this with JSF, or even JSP for that matter, is a lot easier than doing it with GWT.
One question, have you tried to do the same with GWT? ;-)
|
|
|
Message #228647
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
JSF and GWT are not competitive, but complementary technologies.
Why they can't be competitive? ;-)
Both technologies can live without each other and solve same problems. But one(GWT) can do it with a lot of benefits
Unit testing for UI, debuging, writing UI in java (not xml), easy clustering,easy to maintain...
The other(JSF) brings a lot of complexity - developer have to know JSP,JSF,Facelets, SEAM + IceFaces,MyFaces and others. Have to deal with huge XML files, have to write UI in XML.
So, my question remains: what benefits does JSF have over GWT?
|
|
|
Message #228650
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
For one I'd like to see a lot more components in the GWT.
Thanks for an opinion.
Can you please list components that You use in your JSF applications that GWT miss?
After that, I think it is, in a large part, a matter of preference.
I agree, everything is matter of preference.
Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)?
Do you like to spend a month on education of your team (JSF,Facelets,SEAM + MyFaces,HisFaces,YourOwnFaces) or you want to have a framework that allows to do same things but doesn't have such steep learning curve (GWT)?
If you're a swing programmer I think GWT is far more intuitive.
Yes, indeed. But I think it is more intuitive in anyway because if JSF approach was more intuitive we'd already have such framework over AWT/SWT/SWING.
Here is my experience.
I spent one week to teach PHP programmer to write web apps with with GWT(she knew nothing about debugger at that time, knew nothing about AWT/Swing for sure, she new nothing about servlets/jsp).
After that she was able to do quite complex stuff including Trees, Tables with Paging and even Tree Tables ;-).
This proves that using GWT is quite simple even if you haven't written a single Swing/AWT/SWT application.
I for one have quite often found myself working with a team where the site was designed as an HTML prototype by a design team and our job was to add life to it. Doing this with JSF, or even JSP for that matter, is a lot easier than doing it with GWT.
One question, have you tried to do the same with GWT? ;-)
Then, it's like you said, if you believe so.
Can we continue now with Exadel & JBoss story, please?
|
|
|
Message #228655
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Congrats!
I always knew that something like that could happen.
The community needs only ONE faces library.
One of the great strengths of Java over alternatives is choice. The whole point of standards like JSF and JPA is to allow competing implementations, which is good for both vendors and developers.
What I mean is that we need ONE useful and stable library. I'm tired of search, test, configure and learn libraries in every single new proyect. I want the definitive one.
|
|
|
Message #228656
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)
This is totally untrue. Unfortunately since I am at work I don't have the time to post the details.
|
|
|
Message #228659
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
The other(JSF) brings a lot of complexity - developer have to know JSP,JSF,Facelets, SEAM + IceFaces,MyFaces and others.
Plain FUD again...
JSP and Facelets are exclusive and are almost used the same way. The big difference is behind the scene : Facelet process the page to construct a JSF component tree while JSP doesn't have a clue about JSF (BTW JSP doesn't work well with JSF because it is translated as a servlet at runtime, you loose the original page layout which is problematic when you have a loop for instance).
MyFaces is an implementation of JSF. There is nothing almost nothing to learn there except some minor configurations settings if you already know JSF.
IceFaces is a set of components and extension to allow Ajax since JSF is a general Web framework and that Ajax wasn't really out there while JSF was worked on. Every general frameworks as the same kind of extensions. But you have to remember that it's not everyone who is ready to jump in the Ajax ship.
Finally, Seam is much more than a Web framework, and therefore it cover a lot more ground than a view technology as GWT. I guess it could be useful to GWT too. From what I know (I could be wrong), Seam doesn't add anything directly to the presentation tier but just bind it to the business layer. So you shouldn't mention it in your comparaison JSF versus GWT.
As you can see, there isn't that much to learn once we clear the FUD...
|
|
|
Message #228660
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
The other(JSF) brings a lot of complexity - developer have to know JSP,JSF,Facelets, SEAM + IceFaces,MyFaces and others.
Plain FUD again...
JSP and Facelets are exclusive and are almost used the same way. The big difference is behind the scene : Facelet process the page to construct a JSF component tree while JSP doesn't have a clue about JSF (BTW JSP doesn't work well with JSF because it is translated as a servlet at runtime, you loose the original page layout which is problematic when you have a loop for instance).
MyFaces is an implementation of JSF. There is nothing almost nothing to learn there except some minor configurations settings if you already know JSF.
IceFaces is a set of components and extension to allow Ajax since JSF is a general Web framework and that Ajax wasn't really out there while JSF was worked on. Every general frameworks as the same kind of extensions. But you have to remember that it's not everyone who is ready to jump in the Ajax ship.
Finally, Seam is much more than a Web framework, and therefore it cover a lot more ground than a view technology as GWT. I guess it could be useful to GWT too. From what I know (I could be wrong), Seam doesn't add anything directly to the presentation tier but just bind it to the business layer. So you shouldn't mention it in your comparaison JSF versus GWT.
As you can see, there isn't that much to learn once we clear the FUD...
|
|
|
Message #228663
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Can anyone please explain the benefits of using JSF over GWT.
For one I'd like to see a lot more components in the GWT.
Thanks for an opinion.
Can you please list components that You use in your JSF applications that GWT miss?
After that, I think it is, in a large part, a matter of preference.
I agree, everything is matter of preference.
Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)?
Do you like to spend a month on education of your team (JSF,Facelets,SEAM + MyFaces,HisFaces,YourOwnFaces) or you want to have a framework that allows to do same things but doesn't have such steep learning curve (GWT)?
If you're a swing programmer I think GWT is far more intuitive.
Yes, indeed. But I think it is more intuitive in anyway because if JSF approach was more intuitive we'd already have such framework over AWT/SWT/SWING.
Here is my experience.
I spent one week to teach PHP programmer to write web apps with with GWT(she knew nothing about debugger at that time, knew nothing about AWT/Swing for sure, she new nothing about servlets/jsp).
After that she was able to do quite complex stuff including Trees, Tables with Paging and even Tree Tables ;-).
This proves that using GWT is quite simple even if you haven't written a single Swing/AWT/SWT application.
I for one have quite often found myself working with a team where the site was designed as an HTML prototype by a design team and our job was to add life to it. Doing this with JSF, or even JSP for that matter, is a lot easier than doing it with GWT.
One question, have you tried to do the same with GWT? ;-)
I would say that a look at the Icesoft tags may answer that questions. Their stuff looks pretty good and, for me anyway, is the primary reason why JSF is on the table.
|
|
|
Message #228669
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Both [JSF and GWT] are used in same problem domain. Building Web2.0 applications.
As much as I like GWT, it requires Javascript + XHR. I had thought that JSF does too, but JSF proponents have explained -- and not just once -- that JSF in its puriety does not depend on Javascript. Therefore JSF app can be compatible with older or less capable browsers and more accessible. It is another question how many users have their Javascript disabled.
On the other hand, I believe JSF could have become a better spec/framework if it were in fact made on top of JSP, not as a parallel spec. They are so different that on early stages of JSF development some suggested to part with JSP at all. I don't get why J2EE needs two similar but different view technologies. The latest JSP 2.1 spec tries to integrate JSP and JSF better, but these technologies are still different.
Nevertheless, I want to congratulate Exadel and Red Hat guys for strengthening Java server market. Appears that with JBoss, Seam, Hibernate, RichFaces and with development tools, Red Hat can become a viable one-stop shopping mall. This may threaten other Java frameworks but should make server-side Java more attractive when compared to well-integrated ASP.Net offering.
Well the main problem in my opinion is jsp itself, jsf has not really parted which is one of the problems why the component api is overly complicated, the entire taglib binding layer is a pain to use for the component programmer. JSF has only parted so much that they decoupled themselves to some degree from jsp but kept backwards compatibility.
Facelets has been very successful because it departed entirely, while most of the original jsf problems arose from the fact that the departure only was halfway.
(which made problems worse like having two different view layers over a blank jsp page, the classical taglib loop problem and verbatim problem)
JSP has its merits as quick hack technology, but it has its limits and I think somehwere you have to depart from it, to some degree.
Facelets and also Velocity have earned a lot of additional speed in the caching area by handling their own view layers!
|
|
|
Message #228673
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Posted by Spencer Uresk:
With JSF, all our view code is in xhtml I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.
Hi Micheal,
You're partially right and partially wrong. The layout using facelets is in XHTML and of course the visual aspect is provided by the css but of course the components are designed using Java or Velocity in my case.
Don't facelets defeat the original idea of JSF, which is if I understand correctly is defining view with device-independent tags and emitting device-specific markup? In regards to facelets: if you know a good article that compares Tapestry and facelets, I would appreciate the link.
http://java.sun.com/developer/technicalArticles/GUI/JavaServerFaces/
The JSF technology consists of two main components:
1. Java APIs to represent UI components, manage state, handle events, and validate input. The API has support for internationalization and accessibility.
2. Two JSP custom tag libraries for expressing user interface (UI) components within a JSP page, and for wiring components to server-side objects. Page authors can easily add UI components to their pages. Is it correct to assume that facelets is a new view technology for JSF and replace JSP custom libraries? If this is the case, will JSF/JSP tags be deprecated in favor of facelets?
|
|
|
Message #228674
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ONE library
What I mean is that we need ONE useful and stable library. I'm tired of search, test, configure and learn libraries in every single new proyect. I want the definitive one.
You've missed the point. An API specification, as Steve mentioned, DEFINES the API. You have no more to learn. All implementations of a specification *have* that API. How hard is it ? That is why specifications are important.
There is no such thing as a "definitive" library, that implements a specification, because they all do it internally in their own way to give particular benefits. So some run faster etc. That is why a specification is important and that is also why multiple implementations is a good thing because they push each other to implement it better and add on value
|
|
|
Message #228676
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF tags vs JSP tags
I don't get why J2EE needs two similar but different view technologies. The latest JSP 2.1 spec tries to integrate JSP and JSF better, but these technologies are still different. That is because JSF is not a view technology. It is a framework that can use different technologies to render the view. JSP is just one of these. Perhaps it would have been wiser for JSF to use a different approach for its HTML rendering.
My bad. I meant to say that the "JSF engine" could be used together with JSP presentation technology instead of developing proprietary JSF tags. Current JSP 2.1 spec with Unified EL shows that this is entirely possible.
You would probably mention different page lifecycle, but I think this is a weak justification for a totally different tag set of JSF. After all, if looking at the big picture it is all the same: request comes in, processed on the server, the markup is returned back. The internal differences of the lifecycle could be worked out using new JSP actions instead of creating separate tags.
|
|
|
Message #228675
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSP vs Facelets for JSF
(Changed the subject as it's no longer about GWT vs. JSF, which has been thoroughly discussed in this thread.)
Is it correct to assume that facelets is a new view technology for JSF and replace JSP custom libraries? If this is the case, will JSF/JSP tags be deprecated in favor of facelets?
Certainly the Seam team strongly recommends using facelets exclusively, and the majority of new JSF development (including most of the JSF users in this thread) are using facelets. So effectively, yes, I see JSP being de facto deprecated as a view layer for JSF.
|
|
|
Message #228677
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
The feature I think would be most useful for JSF/Seam development is allowing the view layer to participate in refactoring operations - ie, if I refactor a method name on a managed bean, I have the option of having that changed in all the xhtml pages it is referenced.
Hi there,
Actually, with SeamTools for Dreamweaver you can already do this.
It supports site-wide JSF EL validation, and you can run a global find/replace to fix EL problems.
http://www.jsftoolbox.com/products/seam
Ian
--
JavaServer Faces for Dreamweaver
http://www.jsftoolbox.com
|
|
|
Message #228679
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: can u CPL please?
p.s. you do know that the next version of Java is being made available under GPL; will that also prevent your company from developing java based software ?
/max
Correction, Java is being made available under a couple different licenses - one which is GPL.
|
|
|
Message #228680
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Posted by Spencer Uresk:
With JSF, all our view code is in xhtml I had an impression that with JSF all view code is made up with JSF tags, or at least this is how it is supposed to be.
Hi Micheal,
You're partially right and partially wrong. The layout using facelets is in XHTML and of course the visual aspect is provided by the css but of course the components are designed using Java or Velocity in my case.
Don't facelets defeat the original idea of JSF, which is if I understand correctly is defining view with device-independent tags and emitting device-specific markup? In regards to facelets: if you know a good article that compares Tapestry and facelets, I would appreciate the link.
I know that is one of the features of JSF, but I personally don't know of a single project that has actually uses it. I'd be surprised if very many people were.
In any case, if you actually need to support multiple output types, your problem isn't necessarily that you are using facelets - it is that you are mixing in device-specific code into the view. You could run into the exact same issue using JSPs.
On the projects I've been on that use JSF, this is fine - we have almost a 0% chance of needing to support anything but a web browser on a pc, and we gain a lot of benefit by mixing in HTML. If you did have a need to support mutliple devices, you'd approach it differently, and perhaps in that case a different view technology may be better than facelets.
|
|
|
Message #228682
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: can u CPL please?
Yes, but none of them is Apache like as the poster initially implied as a requirement to use software ;)
|
|
|
Message #228683
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: can u CPL please?
Yes, but none of them is Apache like as the poster initially implied as a requirement to use software ;)
And that's still wrong. Obviously, his company would not be using Java if the requirement was Apache-like license.
|
|
|
Message #228685
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: can u CPL please?
Yes, but none of them is Apache like as the poster initially implied as a requirement to use software ;)
And that's still wrong. Obviously, his company would not be using Java if the requirement was Apache-like license.
Original quote from the original poster was:
in order to use it (my company) it has to be an apache friendly licence
Of course, there is absolutely no reason to avoid the use of GPL tooling. The license of the toolset is in no way viral to your code.
|
|
|
Message #228686
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)
This is totally untrue. Unfortunately since I am at work I don't have the time to post the details.
Nice arguments you have ;-)
Probably you should post when you get home.
And by the way do you have GWT background?
|
|
|
Message #228687
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: can u CPL please?
Yes, but none of them is Apache like as the poster initially implied as a requirement to use software ;)
And that's still wrong. Obviously, his company would not be using Java if the requirement was Apache-like license.
Original quote from the original poster was:
in order to use it (my company) it has to be an apache friendly licence
"It" does not refer to Java. Because if it did, then his company wouldn't be using Java.
Of course, there is absolutely no reason to avoid the use of GPL tooling. The license of the toolset is in no way viral to your code.
I find it pretty silly, but that doesn't change the fact that Java will be under a couple licenses and not just a GPL license.
|
|
|
Message #228704
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: can u CPL please?
hi dear
i didn't men the eclipse based studio, it is a tool and u may use it but will never distribute it (so no viral effect) if u like u can GPL it or make it any thing ,that does not affect me, i mean the ajax4jsf and richfaces which required to b bundled with the final product,
considering java, its dual license and we use it under the binary license so no viral effect of the GPL is applied
note: personally ,i am not against the GPL or any license,as i said in my first post ,the software is yours and u can do what u like with it,but the lawyers have another opinion considering the runtime libs we redistribute
thanx
joe
|
|
|
Message #228707
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF tags vs JSP tags
I don't get why J2EE needs two similar but different view technologies. The latest JSP 2.1 spec tries to integrate JSP and JSF better, but these technologies are still different. That is because JSF is not a view technology. It is a framework that can use different technologies to render the view. JSP is just one of these. Perhaps it would have been wiser for JSF to use a different approach for its HTML rendering.
My bad. I meant to say that the "JSF engine" could be used together with JSP presentation technology instead of developing proprietary JSF tags. Current JSP 2.1 spec with Unified EL shows that this is entirely possible.
You would probably mention different page lifecycle, but I think this is a weak justification for a totally different tag set of JSF. After all, if looking at the big picture it is all the same: request comes in, processed on the server, the markup is returned back. The internal differences of the lifecycle could be worked out using new JSP actions instead of creating separate tags.
See this article, explains the issues :
http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html
Some of them come directly from JSP main responsability, rendering and not interpreting the page layout so I think some of the problems are quite unsolvable.
Actually, JSF doesn't need tags in the sense of a piece of rendering code but a way to define the view composition in a declarative way, something JSP has never meant to be.
|
|
|
Message #228708
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Don't facelets defeat the original idea of JSF, which is if I understand correctly is defining view with device-independent tags and emitting device-specific markup?
I never understood this goal in JSF. Anyone who has made a new frontend to an existing webapp for, say, a mobile device, can tell you that the user-interface of the mobile device (no keyboard?) demands that the UI/flow must be reconsidered. So many the JSF components that were uses in the original webapp are rendered useless.
Hans
|
|
|
Message #228709
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)
This is totally untrue. Unfortunately since I am at work I don't have the time to post the details.
Nice arguments you have ;-)
Probably you should post when you get home.
And by the way do you have GWT background?
Thank. Glad you like it. Actually, it was so big that I couldn't let this pass and of course I was going to come back latter to discuss it further.
About GWT, no I don't have any experience with it but I know the concept : translating Java code in Javascript. My point is not about GWT but about the false facts spread around about JSF.
Unit testing a JSF application is pretty simple. Managed beans are regular pojos and therefore are easy to test. Components and renderers don't have any dependency on the container object so they are also quite easy to test. The only tricky part is testing the view definition, you have to instantiate the application ViewHandler using mock objects (included in Seam) and invoke the createView() method and test the result. Of course, you can't unit test your Javascript in Java but this is considering you have a lot which is not always the case.
If you want to do integration testing without having to start a web container, Seam makes it quite easy to do so :
http://docs.jboss.com/seam/1.1GA/reference/en/html/testing.html
About debugging using the debugger, I find this point kind of arrogant because it's not everyone who has jump on the Ajax ship (a lot haven't from what I know) so there isn't going to be a tons of JavaScript in every JSF applications. Also, GWT might be very nice and I am going to give it a try
in the future but don't forget you aren't really debugging
the real code. There may be translation issues you weren't expecting between your Java code and Javascript. It would be like pretending you can use Hibernate without knowing any SQL, only HSQL. Also, there are a lot of Javascript debuggers out there to those not using GWT. My point is not
to say that GWT is not a nice tool but that it may have its own issues too, that it gets very useful only in a Ajax application and that it is totally untrue to pretend it's impossible to debug using a debugger in a JSF application.
Finally, about the huge mapping files. This is plain FUD.
My xml file has never been that big and I was using plain vanilla JSF with Facelets. Actually, if you are using Spring 2.0, your beans should be declared in the Spring context file so it doesn't add a lot of config. Finally, a Seam application declare its managed beans using annotations so there is zero, nada extra configuration involved in a xml file for this part.
Well, hope I made it clears what I was disagreeing with.
|
|
|
Message #228712
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Don't facelets defeat the original idea of JSF, which is if I understand correctly is defining view with device-independent tags and emitting device-specific markup?
I never understood this goal in JSF. Anyone who has made a new frontend to an existing webapp for, say, a mobile device, can tell you that the user-interface of the mobile device (no keyboard?) demands that the UI/flow must be reconsidered. So many the JSF components that were uses in the original webapp are rendered useless.
Hans
I totally agree with you, the application pages will have to be changed in order to make it accessible on a different device but at least you can use the same tags to do it so which makes the task a little bit easier. Actually, I find the possibility to use different renderers quite useful when I want to support two different outputs of a same component in the same technology. For instance, JSF use it to represent a list of choices as a combo box or as a list box.
I did the same kind of things too to integrate an external component since the outputted markup wasn't really what we wanted. It was great to not have to rewrite the entire component but just the renderer in order to do so.
|
|
|
Message #228713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF tags vs JSP tags
I meant to say that the "JSF engine" could be used together with JSP presentation technology instead of developing proprietary JSF tags. Current JSP 2.1 spec with Unified EL shows that this is entirely possible.
You would probably mention different page lifecycle, but I think this is a weak justification for a totally different tag set of JSF. After all, if looking at the big picture it is all the same: request comes in, processed on the server, the markup is returned back. The internal differences of the lifecycle could be worked out using new JSP actions instead of creating separate tags. See this article, explains the issues :
http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html
I've read this article. It explains integration issues of JSP and JSF as these technologies have got developed to date, I don't argue with that. My point was that these discrepancies could have been avoided if JSF was developed as next version of JSP instead of becoming an external band-aid to servlet engine.
Some of them come directly from JSP main responsability, rendering and not interpreting the page layout so I think some of the problems are quite unsolvable.
Actually, JSF doesn't need tags in the sense of a piece of rendering code but a way to define the view composition in a declarative way, something JSP has never meant to be. Come on, you can do better than that. Who cares what it was or was not meant to be? While time passes new approaches and techniques are developed, so if they can be applied to old technology without breaking it -- why not?
I am pretty much sure that JSP could have been extended to what JSF is now without breaking compatibility with legacy JSP code, while gaining new features like declaring view composition. Old applications would not have known about new tags and everyone would have been happy. Instead, JSP is de-facto being pushed into oblivion by the shiny JSF.
Anyway, too late ranting now, because of the subject of this thread ;-)
|
|
|
Message #228718
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: can u CPL please?
LGPL does not restrict you from distributing your project closed source. Works for Hibernate, Seam and a lot of other major frameworks in Java.
You should contact JBoss/Red Hat to get any issues you have resolved ;)
|
|
|
Message #228732
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Red Hat, Exadel partner around open source tools for JBoss
I might be wrong.. But sounds to me like Exadels business hasn't worked out, and they are winding down business by open sourcing and letting JBoss/Red Hat take over the development..
Seems like their business has actually worked out pretty damn well, given that we just paid them a whole bundle of money to get this deal done. ;-)
This is not a typical case of a commercial vendor deciding to give away a product they couldn't sell, in a last-ditch attempt to get users. Rather, this is an acquisition of successful technology, for money.
My day at EclipseCon revealed a somewhat different perspective. I overheard an Exadel exec commenting on the fact that this deal was largely 'an admission of throwing in towel' with regards to non profitable tools and Ajax components in exchange for guaranteed services from JBoss for some period of time. Not exactly a grandiose exit and definitely an over hyped representation of the situation.
While this may prove to be a decent strategy for JBoss over time, I'm somewhat disappointed in the JBoss selection of Ajax4JSF over Icefaces which I believe is a far superior solution that provides distinctive advantages. A superior component offering, Ajax push, and a common Ajax bridge that completely isolates us Java heads from the JavaScript nightmare, just to name a few. Let's hope the Icefaces guys will continue to support Seam moving forward.
Bob
|
|
|
Message #228742
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax4JSF vs GWT
IMO, GWT is a new model of web development which is different than MVC based frameworks. It's not just matter of learning new APIs and tools. It needs new design patterns and best practices.
Just think of EJBs and other JEE technologies. AFAIR, it took years for Java community to come up with the required design patterns and trade-offs.
For now, I would prefer to go with well known MVC based frameworks and keep an eye on GWT.
|
|
|
Message #228743
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF tags vs JSP tags
I meant to say that the "JSF engine" could be used together with JSP presentation technology instead of developing proprietary JSF tags. Current JSP 2.1 spec with Unified EL shows that this is entirely possible.
You would probably mention different page lifecycle, but I think this is a weak justification for a totally different tag set of JSF. After all, if looking at the big picture it is all the same: request comes in, processed on the server, the markup is returned back. The internal differences of the lifecycle could be worked out using new JSP actions instead of creating separate tags. See this article, explains the issues :
http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html
I've read this article. It explains integration issues of JSP and JSF as these technologies have got developed to date, I don't argue with that. My point was that these discrepancies could have been avoided if JSF was developed as next version of JSP instead of becoming an external band-aid to servlet engine.
Some of them come directly from JSP main responsability, rendering and not interpreting the page layout so I think some of the problems are quite unsolvable.
Actually, JSF doesn't need tags in the sense of a piece of rendering code but a way to define the view composition in a declarative way, something JSP has never meant to be. Come on, you can do better than that. Who cares what it was or was not meant to be? While time passes new approaches and techniques are developed, so if they can be applied to old technology without breaking it -- why not?
I am pretty much sure that JSP could have been extended to what JSF is now without breaking compatibility with legacy JSP code, while gaining new features like declaring view composition. Old applications would not have known about new tags and everyone would have been happy. Instead, JSP is de-facto being pushed into oblivion by the shiny JSF.
Anyway, too late ranting now, because of the subject of this thread ;-)
Well the problem is that JSP is an imperative programming language by nature. There is nothing interpreting the whole page but this is what JSF needs. In JSF, a page is a definition not a program as in JSP. For instance, how would you deal with c:if (even if you are supposed to used the rendered attribute in jsf)? The tag c:if doesn't execute the nested code in jsp if the condition is not met which is what we want normally but this isn't the case in jsf. In Jsf, we want the component to be created even when it isn't displayed as in Swing. I'm not sure how you can solve this problem without rewriting every c:if tags implementation out there and this is only one simple example.
It's not that jsp model is not useful but it isn't made to deal with component based framework since it is mainly a programming language used to render a view which is in contradiction with the component approach needing only a view definition, the logic being handled by components.
Hope I made it clear, it's kind of hard to explain in a foreign language ;-)
|
|
|
Message #228749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
exciting news
I think that the combination of Seam, facelets and now the rich Ajax JSF components and Eclipse plugin are exciting.
I hope this will work not only on jBoss server.
|
|
|
Message #228773
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
IMO, GWT is a new model of web development which is different than MVC based frameworks. It's not just matter of learning new APIs and tools. It needs new design patterns and best practices.
Just think of EJBs and other JEE technologies. AFAIR, it took years for Java community to come up with the required design patterns and trade-offs.
For now, I would prefer to go with well known MVC based frameworks and keep an eye on GWT.
Well, this is where the innovation comes in. While I'm the first to look to the past to determine how best to succeed and avoid potholes, there is also something to be said for taking a calculated risk via pioneering. My personal belief is that GWT has reached the level needed to take off. Time will tell...
Regardless,I think that a well-considered strategy and perhaps, some balls( or to be more PC, vision), is now necessary to reach the next plateau. I would submit that this combination catapulted the likes of Hibernate, Spring, etc to the top.
|
|
|
Message #228777
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
I know that is one of the features of JSF, but I personally don't know of a single project that has actually uses it. I'd be surprised if very many people were.
I am working on a project that will be using this feature, and the ability to render the same page to different document types is, for me, an exciting feature of Seam 1.1.
|
|
|
Message #228788
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Bob, you must have "overheard an Exadel exec" wrong
Bob,
I'm confident that you DID NOT overhear an Exadel exec discussing tht contributing its products to open source represents "throwing in the towel". Quite the contrary. Exadel has always embraced open source software and this plan demonstrates our committment to open source and improving the lives and efficiencies of developers who use these products.
Should you have any continued doubts, I invite you to attned our talk this afternoon at Eclipsecon. The talk is titled "JBoss introduces New Open Source Tools and Frameworks for building Rich Internet Applications and will take place Wednesday, 4:30 p.m. Red Hat and Exadel will discuss the motivations for executing this strategy and what benefits there are to Exadel, Red Hat and the developer community.
We will be happy to entertain any discussions with you after the session.
|
|
|
Message #228795
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Some confusion
Really excited about this announcement, as I've been increasingly frustrated with MyEclipse, but have been turned off by the cost of other solutions. I'm going to start looking at Exadel immediately.
However, I'm a little confused at the scope and ultimate licensing situation. Sacha states in his blog entry: "Once fully opensourced, binaries for all of the individual plugins will be made available for free while the "Red Hat Developer Studio" will only be made available as part of a Developer Subscription." What does this mean exactly? What will be the difference between Developer Studio and the individual features/plugins? Differences in functionality, or in support only?
Also, is Gavin or Max able to clarify the relationship between the Exadel tools and JBoss IDE at this time? Will JBoss IDE be deprecated in favor of RHDS?
Thanks
- Eric
|
|
|
Message #228799
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Some confusion
Hi Eric,
All the plugins that will take part of Red Hat Developer Studio will be available in opensource (we are a opensource company after all ;)
The most interesting plugins we will packaged up as eclipse features and be made available at least from an update site.
You can get that for free and you can ensemble your own favorite eclipse configuration (but it is then your "headache" to figure out which plugins you want and what work together etc.)
The differentatior for RHDS is that it will be available in a integrated and test bundle which is certified against the already supported JBoss/Red Hat runtimes. Releaving you from the headache.
So the difference is in support/certification.
With respect to JBoss IDE then that project + Exadel Studio Pro is what will end up in RHDS. Thus JBoss IDE and Exadel Studio Pro is both being deprecated in favor of RHDS.
|
|
|
Message #228832
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)
This is totally untrue. Unfortunately since I am at work I don't have the time to post the details.
Nice arguments you have ;-)
Probably you should post when you get home.
And by the way do you have GWT background?
Thank. Glad you like it. Actually, it was so big that I couldn't let this pass and of course I was going to come back latter to discuss it further.
About GWT, no I don't have any experience with it but I know the concept : translating Java code in Javascript.
;-)
The concept is to let Java developers to write AJAX application not in XML neither in JavaScript but in Java.
I suggest you to try GWT first and than participate in topic named Ajax4JSF vs GWT.
PS The most funny thing guys who advocate JSF here didn't try GWT.
|
|
|
Message #228835
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Do you prefer do Unit Testing for UI(GWT) or you prefer to find bugs manually (JSF)?
Do you prefer to be able to debug UI (GWT) or you don't like to use debugger (JSF)?
You prefer to play with huge XML mappingfiles(JSF) or you prefer to keep everything in pure Java Code(GWT)
This is totally untrue. Unfortunately since I am at work I don't have the time to post the details.
Nice arguments you have ;-)
Probably you should post when you get home.
And by the way do you have GWT background?
Thank. Glad you like it. Actually, it was so big that I couldn't let this pass and of course I was going to come back latter to discuss it further.
About GWT, no I don't have any experience with it but I know the concept : translating Java code in Javascript.
;-)
The concept is to let Java developers to write AJAX application not in XML neither in JavaScript but in Java.
I suggest you to try GWT first and than participate in topic named Ajax4JSF vs GWT.
PS The most funny thing guys who advocate JSF here didn't try GWT.
I suggest you to take some reading lesson as I specifically said that I was not advocating JSF over GWT since I have zero experience using it but merely correcting completely false facts about JSF and pointout out that not everyone is building entire Ajax-based applications...
|
|
|
Message #228844
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Let's not go crazy over GWT.
It does have a few drawbacks (at least last time I checked):
a) calling Java business logic from the client is cumbersome compared to JSF where it is straightforward. Requires custom interfaces, JSON, etc. Not just a straight method call.
b) does not support regular Serializable interface, need to implement a CUSTOM GWT interface on all your objects in order to be able to pass them between the server and the client.
This means for example I may have to add GWT-specific code to my entity objects, which theoretically should have no view-related code in them.
c) potentially exposes your internal Java code when translated to openly viewable Javascript. Maybe that's something you would prefer to avoid.
I think a MUCH better option than GWT is Echo2: 100% Ajax, 100% Java. No Java->Javascript translation:
http://nextapp.com/platform/echo2/echo/demo/
Why Echo2 has not caught on while GWT gets all the hype, I really don't understand. It just seems like a superior solution.
And why Eclipse is re-developing Echo2 from scratch under the name Ajax Toolkit is beyond me too. You have a great implementation already but due to "not invented here syndrome" they will do it again from the beginning. Pointless waste of resources.
|
|
|
Message #228860
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax4JSF vs GWT
Let's not go crazy over GWT.
It does have a few drawbacks (at least last time I checked):
a) calling Java business logic from the client is cumbersome compared to JSF where it is straightforward. Requires custom interfaces, JSON, etc. Not just a straight method call.
b) does not support regular Serializable interface, need to implement a CUSTOM GWT interface on all your objects in order to be able to pass them between the server and the client.
This means for example I may have to add GWT-specific code to my entity objects, which theoretically should have no view-related code in them.
c) potentially exposes your internal Java code when translated to openly viewable Javascript. Maybe that's something you would prefer to avoid.
I think a MUCH better option than GWT is Echo2: 100% Ajax, 100% Java. No Java->Javascript translation:
http://nextapp.com/platform/echo2/echo/demo/
Why Echo2 has not caught on while GWT gets all the hype, I really don't understand. It just seems like a superior solution.
And why Eclipse is re-developing Echo2 from scratch under the name Ajax Toolkit is beyond me too. You have a great implementation already but due to "not invented here syndrome" they will do it again from the beginning. Pointless waste of resources.
I've just started working with GWT, but I don't think those drawbacks are a big deal...
a)It is a pretty straightforward callback. I had not problem picking it up. And it is only located in the actual GWT client. And the service itself is just a servlet. All in all, I think, pretty clean separation.
b)True. They have something called IsSerialiable. Worst case, I figure I can extend my existing classes and add the interface and cast in the GWT client to the IsSerializable version. Your service code can use the original one with no problems. Or you can copy stuff from into a GWT version. Plenty of ways to do that, included a library I saw in this site.
I tried adding a GWT page to an existing app, and I did not have to add any GWT-specific code to my existing objects. In fact, I from what I see and what I have, I would say that you don't have to do that.
c)I don't think this is so. The only thing that is translated, at least what I've done, is the GWT client. This is strictly take, say, a list of items, and add it into a tree control. I don't believe any internal code would be necessary. In fact, considering they GWT supports a subset of JDK 1.4x, I don't think you can do all that much.
I bigger drawback, IMO, is no layout manager out the box.
|
|
|
Message #228867
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Echo2
I still like the Echo2 approach much more: no mess of crossing the Javascript and Java domain. Pure Java, 100% of the time.
And so far I have to yet see a single GWT demo that impresses me as much as the Echo2 demo, in particular this one:
http://demo.nextapp.com/Demo/app
When you can do this in GWT, let us know and show us a sample.
|
|
|
Message #228872
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Echo2
I still like the Echo2 approach much more: no mess of crossing the Javascript and Java domain. Pure Java, 100% of the time.
And so far I have to yet see a single GWT demo that impresses me as much as the Echo2 demo, in particular this one:
http://demo.nextapp.com/Demo/app
When you can do this in GWT, let us know and show us a sample.
Shrug. I'm not selling it, I'm just addressing what you wrote based on my, admitedly limited experience.
I've seen Echo2, aa couple of times, over the past couple of years. It looks good. I haven't used it and I just haven't heard enough people using it to have a level enough level of comfort. GWT "seems" to have more traction. It is certainly backed by a company with deep pockets,and that is always a selling point.
Have you written an app in Echo2? Do you have customers using it? What was their feedback?
|
|
|
Message #228875
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Echo2
I agree on the traction thing, it seems the Google name just can't be beat.
No, I have not written a full Echo2 app yet (but neither have I done a full one in GWT either). However, in the Echo2 forums quite a few people have and they seemed quite satisfied with it.
It's just a pity that such a promising Java framework seems to be so low under the radar, where it offers a pretty revolutionary approach to web development, IMHO.
|
|
|
Message #228877
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Echo2
I still like the Echo2 approach much more: no mess of crossing the Javascript and Java domain. Pure Java, 100% of the time.
And so far I have to yet see a single GWT demo that impresses me as much as the Echo2 demo, in particular this one:
http://demo.nextapp.com/Demo/app
When you can do this in GWT, let us know and show us a sample.
Shrug. I'm not selling it, I'm just addressing what you wrote based on my, admitedly limited experience.
I've seen Echo2, aa couple of times, over the past couple of years. It looks good. I haven't used it and I just haven't heard enough people using it to have a level enough level of comfort. GWT "seems" to have more traction. It is certainly backed by a company with deep pockets,and that is always a selling point.
Have you written an app in Echo2? Do you have customers using it? What was their feedback?
Another one not yet mentioned is ZK. ( http://www.zkoss.org/ ) Alot of components, coding is pure Java and it works very well. I experimented alot with it last year and wrote an intro article http://www.developer.com/design/article.php/3610476 . I don't think I've ever built a java-based web app in less amount of time. It's really a good framework. However, my concern (then and even moreso now) is it will be squeezed out by the increasingly free, standards-based platforms.
Mike
|
|
|
Message #228879
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Echo2
Interesting.
From a look-and-feel issue, doesn't seem quite as polished as the Echo2 demo (but that is probably just minor CSS issues). I am not quite sure if I like the XML UI approach vs. Swing-type UI coding (Echo2's approach), I guess it's a matter of personal preference.
How was the ZK performance in your test? I recall checking it out a long time ago and it seemed a lot more sluggish than Echo2, so I didn't look much further into it, but maybe that was just a server issue...
|
|
|
Message #228881
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Echo2
I agree on the traction thing, it seems the Google name just can't be beat.
No, I have not written a full Echo2 app yet (but neither have I done a full one in GWT either). However, in the Echo2 forums quite a few people have and they seemed quite satisfied with it.
It's just a pity that such a promising Java framework seems to be so low under the radar, where it offers a pretty revolutionary approach to web development, IMHO.
Maybe they need a better PR guy! I'm most likely going for it on the GWT front on my next project. JSF and Icesoft is still a contender, but I still have close to two months to iron it all out.
We see how I feel about GWT when the dust settles.
|
|
|
Message #228882
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Echo2
I agree on the traction thing, it seems the Google name just can't be beat.
No, I have not written a full Echo2 app yet (but neither have I done a full one in GWT either). However, in the Echo2 forums quite a few people have and they seemed quite satisfied with it.
It's just a pity that such a promising Java framework seems to be so low under the radar, where it offers a pretty revolutionary approach to web development, IMHO. GWT portlets look simple to program and are visually unintrusive, while Echo2 (as well as Laszlo) showcases a whole windowing system inside a browser page. Thanks, but no thanks. I have my native windowing system in the host OS and I don't want another one inside a page. This is the major reason why I would prefer simpler and leaner GWT approach to heavyweight Echo2 or Laszlo. And these frameworks are slow!
I mean ok, the machine I am working on is seven years old, it is 900MHz Athlon with built-in graphics, but it is more than enough for native Windows app, it is enough for Java Swing, but Echo2 or Flash UI is slow. I can see the window content, frame and the header moving independently, looks really ugly. I believe that for intranet usage with known client hardware Echo2 is a good fit, but native Windows app is an even better fit. For internet usage, one cannot assume that every user has a machine with powerful graphics card. Maybe in a year or two when the majority upgrades to Vista, Echo2 will shine.
|
|
|
Message #229504
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Are you biting the hands that feed?
From the desk of Genuitec (creators of MyEclipse) CEO, Maher Masri...
It's been said that the key to happiness is to set your expectations so low that no matter what happens, it is never a surprise. And, we do our best to do exactly that with respect to the public behavior of many of our competitors. However, the latest astro-turfing in this thread by the JBoss clan failed to clear even the lowest-set bar. You may think that I'm writing this to retaliate, or perhaps defend, Genuitec against the ensuing "Pick on MyEclipse" banter by the JBoss clan in the above comments. No, not really. Being singled out as the IDE to beat in this industry sounded more like a compliment to me than criticism.
Regarding the announcement itself; it was not a big surprise that RedHat needed a vendor lock-in solution for its application stack. IBM, BEA and Oracle all have their own flavor, so the news doesn't fall in the terribly shocking category. It's also no surprise that: “For its part, Exadel is basically looking for a way to get out of product development and software support and get back to its professional services business.” (The Linux Beacon).
So why even address this announcement? Because I think the surrounding behavior exposes a much larger issue. I'm writing this because I truly believe many people who wear the open source badge completely miss the intent and spirit behind it. And, in the case of JBoss, even use it as a sharp stick to poke, bully and intimidate those that disagree with them.<p>Don't get me wrong, I was one of Mark Fleury's biggest fans when he cashed out of JBoss. But Mark didn't build a company, a brand and a community based solely on intimidation tactics. Mark understood that he had a snow-ball's chance in hell of competing in the Application Server market through a proprietary technology or by protecting content. Mark had to create a pseudo-religious following through the simple notion of enlightened self-interest; we both give a little and win at the end. If enough people believe in the idea, it creates a virtuous cycle that benefits all participants and gives JBoss a large enough lever to move the world.
Reflecting back on Genuitec's part in this equation, I could not help but highlight our role in feeding this virtuous cycle and helping Mark become a multi-millionaire. So here is a short list:- Genuitec was the first company to provide an Eclipse-based application server connector for JBoss, and have shipped more than 4 million downloads for this connector since 2002.
- Through MyEclipse, Genuitec has shipped more than 3 million downloads for the JBoss Hibernate framework and provided extensive support and tooling for this fledgling technology.
- Genuitec commissioned a number of training documents, supported a number of distance-learning portals and published a series of tutorials based on using MyEclipse with the JBoss application server.
- MyEclipse support engineers have answered more than 10,000 questions on how to configure and use the JBoss application server. Many had little to do with how to use MyEclipse itself.
I could go on, but that is not the intent of this response. And there's nothing altruistic here. Genuitec gladly supported JBoss technologies with our time, money and energy because enough people used them to warrant our attention. We adopted the various technologies such as XDoclet and Hibernate because we believed they had promise. Other IDEs and tooling companies did the same, and in doing so endorsed JBoss and created brand awareness that no marketing department or budget could have ever accomplished alone.
So, you can imagine my surprise when the partnership announcement by RedHat quickly degenerated into finger-pointing and name calling all under the guise of the "purity" of open source. The conversation became even more surreal as the debate raged over what open source license would provide more protection from adopters that "leech" off the open-source code base. Talk about penny wise and pound foolish. Someone should really pick up the GNU manifesto one more time and realize that people who build tall Cathedrals made out of glass should not be throwing rocks at others.
But, I'm not completely surprised. History has shown that children almost always squander their inherited fortunes because they did not live in the same conditions that gave rise to their legacy, and Mark Fleury's left-behinds are no different. Children (young or lacking experience) simply don't understand why it is in their best interest to share. They mistake popularity with power, and assume success is based entirely on their own actions. Possessiveness quickly gives rise to behavior that we expect from thugs and school yard bullies.
In an admittedly sweeping generalization, that could explain the latest finger pointing and name calling. I expected more from people like Gavin King, who should clearly know better. I expected people that tout "Professional open source" should at minimum actually be professional. Apparently, I might have put Gavin on an undeserved pedestal.
The more interesting conclusion in this discussion, and follow-on news coverage, is RedHat's decision to place all development tools under the GPL license. It worked for the Linux distribution, so why not apply the same approach to development tools? That makes about as much sense as using the same material to build both cars and space shuttles. As an enterprise developer, every line of code written that links to GPL software is now subject to the copy-left viral license and must be made public as the result of any modicum of distribution. So where do I sign up? ;-) I can almost hear the screaming from the legal department, and the mandate for audits and compliance. I can't possibly see how all of this will be attractive for enterprises looking for reliable solutions without a vendor or license lock-in. All done under the banner of protecting the "virtue" of open source.
My final conclusion in this long reply is simply this: If your business is based on open source, don't bite the hands that feed your success. And, if you don't want others to use your code then don't put it out as open source to begin with. Doing anything else is either plainly disingenuous or naively following the siren's call down a road paved with promise, but only littered with broken dreams.
- Maher Masri, CEO, Genuitec, LLC
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
