JBossDeveloper

and no books out on AribaWeb on amazon.com?  this website is so damn slow...

Guys, back to the topic,
In the urls that you posted, all the applications that I saw don't use Richfaces. Nobody uses Richfaces with Seam?

Question to all, do you know Javascript too or not?

It's only a question because Richfaces use Prototype and Scriptaculous, or sometimes JQuery, nobody of you who knows these javascript libraries feels like: 'hey, I can do this without strange tags with JS in 2 lines of code!'.
With Seam remoting I have to write interfaces and tons of code in surplus just for a simple ajax call. Then the converter for comboboxes, why? all objects have a toString() method!

There's someone here that like me comes from PHP/Ruby/Perl world? How do you feel with Seam? I'm interested in a serious comparison, with no prejudices like j2ee is enterprise and all others must die :)

Luke Simon wrote on Mar 20, 2009 13:10:


Guys, back to the topic,
In the urls that you posted, all the applications that I saw don't use Richfaces. Nobody uses Richfaces with Seam?

I have always wondered about that... (I do use Richfaces, I guess that is because I just don't like Javascript)

Question to all, do you know Javascript too or not?

I know Javascript, but not a lot.

It's only a question because Richfaces use Prototype and Scriptaculous, or sometimes JQuery, nobody of you who knows these javascript libraries feels like: 'hey, I can do this without strange tags with JS in 2 lines of code!'.

Well, jQuery can do a lot of things with almost no javascript (that is why I like it a lot), but in general, in my experience one needs to write more lines of code with the javascript approach than with the JSF approach (and also, the issue with javascript is that if you write to much logic with it, you run in to the risk  of forgetting that you must never trust your clients, and then forget to have validation code on the server side, and so you become an easy target for hackers).
Of course, a big problem right now is that to write a JSF component is just many orders of magnitude harder than hack a solution in javascript, one just have too do a quick Google search to realize that, I hope that JSF 2.0 makes creating AJAX enabled components a lot easier, but I wonder if it isn't too little too late (just compare the amount of code vs features in ExtJs vs Richfaces or ICEfaces, or try to find a tutorial in internet that makes you feel that it is easy to write an ajax enabled JSF component, both Ricfaces and ICEfaces are blackboxes when it comes to creating you own components, that may change with Richfaces CDK, but again, maybe it is too late).

With Seam remoting I have to write interfaces and tons of code in surplus just for a simple ajax call.

So you write no server side code? you connect directly to your database from Javascript? I guess then you are safe from crackers because they think it is so easy to destroy your database that they do not even bother trying ;-) (interesting approach, but I 'll keep using Seam WebRemoting and Ajax4Jsf, thanks)

Then the converter for comboboxes, why? all objects have a toString() method!

The converter is not only to convert from an object to a string, but to convert from a string in to an object, all objects do not have a parse method... or do they?

There's someone here that like me comes from PHP/Ruby/Perl world? How do you feel with Seam? I'm interested in a serious comparison, with no prejudices like j2ee is enterprise and all others must die :)

I think that seam, as it is right now, it is just not agile enough (thanks EJBs!), specially if you com from a PHP/Ruby/Perl world (or even a plain write it all in the JSP file world). I really think that the priorities for the next version of seam should be:

1. zero turnaround development (for any code on any layer of the applications, for components and for entities)


2. make seam-gen powerful enough to be considered a functionally complete crud generator (ask Richfaces team to help build a really stunning UI for seam-gen applications)


3. improved validation, that plays well with AJAX (for this, ask Hibernate team to fix the entityManager.persist too early validation) and that works for persisting new objects (validate for insert), updating existing objects (validate for insert) and removing existing objects (validate for delete) and that can be called on demand (validate all pojos with new, changes or that will be deleted in current entityManager), or transactionally (on commit)

Of course, Seam has other advantages, I think that in general the kind of architecture that Seam proposes is good (specially if you do not want to build and easy to crack and destroy website), but it really needs to improve its agility, I waste to much time waiting for my application to restart each time I make a change, and I hate having to violate OAOO/DRY each time I have to write validation code (In my experience must PHP/Perl developers do not care much about good architectural principles (Ruby developers do care, but I just prefer languages with static typing), but of course, you might be the exception).

So, anyone here know or use anything else than Seam?

Yes, lots of other stuff... but I fail to see the goal of your question...

Francisco Peredo wrote on Mar 23, 2009 16:09:


Yes, lots of other stuff... but I fail to see the goal of your question...

Ok, Francisco, I've got your answer...but anyone else? only 1 answer? wow...great community!

So sorry we didn't all rush in to cater to your needs. Your opinion of us is very important ;-)

I've done home-rolled frameworks, Struts and Spring Framework before Seam.

I got around the no support for regenerating entities by hacking up the jboss tools templates. I made the generator generate MyTableGenerated.java, that is annotated with @MappedSuperClass rather than @Entity, I then add my own MyTable.java entity with next to no code in it (90% have none at all). If I need to change a property in the base class I copy it to the main class and then edit hibernate.revenge.xml to exclude generating that property in the future. It saves a lot of time on simple crud screens, however for tables with lots of complicated relationships I usually create my entity from scratch as the defaults are almost never correct. If I add columns to existing tables all I have to do is generate-entities and add in a textbox (or whatever).

Nicklas Karlsson wrote on Mar 23, 2009 21:02:


So sorry we didn't all rush in to cater to your needs. Your opinion of us is very important ;-)

nobody really cares about stack (API) developers really.  redhat may eventually file for bankruptcy or get bought out by another larger company.  .NET rules all (reality).

;-)

don't you just love the cute grins?

fix this damn board so we get notified of posts man.

We use the whole Seam/JE5 stack here in a production real-time trading system.   We use many Seam / EJB3 features including Conversations, Extended Persistence Contexts, Seam Remoting, RichFaces, etc.

• Learning curve - Similar to other technology stacks, especially for anyone who has some J2EE experience.  Seam has a very logical design and that helps keep the learning curve down.


• Performance - Like any powerful framework, you can make performance mistakes.   Seam has reasonable performance out of the box, and if you avoid pitfalls you can get very high performance from Seam/Hibernate/JBoss.   Our system uses Seam Remoting to provide real time market information to our customers.   Over 1 million AJAX requests per day on modest clustered hardware.


• Features - Seam gets rid of most 'data transfer objects' and other 'adapter' code.   We write less framework code, so we can focus on business features.  Conversations and extended persistence contexts are easy to use and make users happy because the app behaves like they think it should.


• Future - I chose Seam because it integrates existing standards rather than trying to be it's own standard.  WebBeans is the next step in the evolution of Java Enterprise.

I have used plenty of other frameworks.  They all have their strengths and weaknesses. I think the main strength of Seam is it's integration with the JE5, structured way of doing things (less dynamic binding, more static binding), which is my preference for larger, more complex applications.

lucius yu wrote on Mar 26, 2009 07:25:


I used .NET in 2001 during it's BETA stage and I was impressed then.

I used Apple WebObject in 2000 during it's transition to Java and I was impressed then. ;-)

That was before my professional life.  My first job was a JAVA web developer and boy was I disappointed at how crappy JAVA web development was.

I felt the same, but for both Java and .NET development (when compared to WebObjects)

At that time 2002, the JSF specs just came about and at first glance I thought we finally have something comparable to ASP.NET, but nope... it was until 2009 that JAVA web finally caught up to how .NET WAS back in 2001.  I'm guessing .NET has improved a whole lot the past 8 years so filling in the gap, I think we're still way behind.  That explains why there are so many companies adopting .NET these days.

I felt the same way about JSF, and about ASP.NET 1.x, ASP.NET 2.x...

I've been contemplating the past few days about investing my time in seam.  I have used it on a project in 2006 and I really liked it.

I like it too... it is the best opensource frameworks I have used so far (but I still miss WebObjects, Seam is the closes thing to webobjects I have used, but lately I have been tempted by AribaWeb)

  I think it would be something I'd invest more time in just for fun if I had extra time, but professionally I think it might not be worth it at this time only because no companies out there are adopting it. Although, I seriously don't think the learning curve is as steep as people here say it is and I seriously don't find spring better with all the XML crapfiguration.

Well, I believe Seam still has too much XML crapfiguration inherited from JSF.

Could it be because most people are not accustomed to the component based way of thinking yet?

Maybe, in fact, even Seam is not as componentized as it could be, maybe it is because JSF 1.x is not componentized enough (just compare it to Wicket, Tapestry, AribaWeb, or even JSF 2.0 ), and do not even get my started with the XML/String based navigation... why we can not have an object oriented navigation API?

Well in our company,we liked SEAM so much that all of our applications/products are now moved to Seam from different frameworks and our applications are deployed at clients with the SEAM framework only.

We have an application deployed that is used by around 1,000 users, we made conversations as small as possible, we avoid passing anything other than core parameters around in pages.xml, and we use our own entity query with parameters in the page itself (you can read why at my blog linked below).  Oh, and we use Richfaces.

Regarding the question of Seam alternatives :

Since implementing things with Seam, I have had doubts, and re-looked at alternatives from PHP, .net, Spring MVC and webflow, non-Seam JSF and even plain old servlets. I wanted to try and find an easier way with something more mainstream, something that had jobs in the 3 or 4 digits range. However, at the end of the day, I ended up coming back to Seam. It's just so easy to use and be productive in if you want to write good OOP systems using a nice stateful framework.

.net - JSF data binding rocks compared to ASP.net, good luck getting started with entities and hibernate and trying to hook controls to entities, and then throwing pagination in the mix. It can be done, it's just ugly.

PHP and Servlets - It's like assembler for the web, not that Assembler is bad (I used to code for the 68K and Z80), but you don't want to go writing anything really complex in it. Coding a single paginated search page with multiple parameters feels like a whole project in itself. In Seam it would take about 5 minutes. It'll also sort out how to handle queries with empty criteria.

Spring MVC and Spring Web Flow - Spring MVC doesn't bring too much to the table other than organizing your pages, the code behind them and doing some form binding. You still end up doing a lot of the manual stuff as in PHP and servlets. However, with Web Flow, it really comes up to par with Seam in a number of ways. JSF and Spring Web Flow is a good combo and in some way it improves upon Seam. However, it also has a number of glitches (as does Seam). Why didn't we go with SWF over Seam? Well, it's close, but Seam feels more like a completely integrated package. Spring stuff is built so you can interchange the pieces, which means that integration is dependent on the lowest common denominator which is the interface expected to be implemented by the pieces.

Ultimately, we stuck with JSF and Seam since there was far more to be lost than gaine by moving away from Seam. Could we have implemented it in other frameworks. Sure, but it would have been a lot more hassle.
As an ex-Borland Delphi user, using a less popular, but far superior toolset is familiar territory