the future of web frmwks and impact on CDI, etc.

[asookazian]

With rich Ajax applications and HTML5 on the horizon, are web frameworks still relevant? Java web frameworks like Struts and Spring MVC were all the rage 5 years ago. Component-based frameworks like Tapestry, JSF and Wicket made it easier to create re-usable applications. But what about the Mobile Web and offline applications?

Are Titanium, Adobe Air and Gears the future? If you're embracing the RESTfulness of the web, do you even need a web framework, or can you use use JAX-RS with an Ajax toolkit?

These questions and many more are examined, answered and debated in this lively session. Bring your opinions and experiences to this session to learn about what's dead, what's rising and what's here to stay. If you're a web framework fan, this session is sure to please.

http://javasymposium.techtarget.com/html/frameworks.html

How will Weld/Seam3 fit into this landscape???  Perhaps this is irrelevant b/c Seam works integrates seemingly with almost any MVC frmwk including Flex but I noticed that Seam/Weld is not mentioned in any of those presentations (Spring of course is)...

You would think Seam/BPM would be mentioned in the context of JBoss at least...

[luxspes]

Arbi Sookazian wrote on Dec 01, 2009 17:23:


Are Titanium, Adobe Air and Gears the future?

And Silverlight, do not forget it. Oh, and Java applets (now renamed JavaFX), the worse waste of an opportunity by Sun.

If you're embracing the RESTfulness of the web, do you even need a web framework, or can you use use JAX-RS with an Ajax toolkit?

JAX-RS with an Ajax toolkit  (like Cappuchino, or ExtJS, or Exr3, or OpenLazslo) will be the future, JSF, ASP.NET or any other server side component technology doesn't stand a chance.

These questions and many more are examined, answered and debated in this lively session. Bring your opinions and experiences to this session to learn about what's dead, what's rising and what's here to stay. If you're a web framework fan, this session is sure to please.

http://javasymposium.techtarget.com/html/frameworks.html

How will Weld/Seam3 fit into this landscape???  Perhaps this is irrelevant b/c Seam works integrates seemingly with almost any MVC frmwk including Flex but I noticed that Seam/Weld is not mentioned in any of those presentations (Spring of course is)...

Not sure, but now that I have integrated Weld with DWR I plan to create a Hotel Booking application that uses Capucchino for its UI and perhaps helps me determine if conversations are really something that makes sense to administer server side... although if I had to bet I would say that my final conclusion will be that they are not.

[nickarls]

I think the winner of the UI wars will be the first Big Player to have a pretty RIA UI and a complete Java 6 / JSF integration layer. So that if you have a running JSF 2, JPA 2, CDI, BV app, you can automagically hook in the UI to use ValueChangeListeners, have exceptions and validations propagate completely and so on...

[asookazian]

or use the Flex with the entire EE6 stack minus JSF 2?

but I guess you may be right.

[luxspes]

Arbi Sookazian wrote on Dec 02, 2009 20:24:


or use the Flex with the entire EE6 stack minus JSF 2?

or use the Capuchinno/OpenLaszlo/ExtJs/AnythingElseThatIsClientSide with the entire EE6 stack minus JSF 2 ;-)

[nickarls]

Yes but when it comes to industry adoption, Big Names have the upper hand. You can explain to management that this is from the guys that make Flash etc. but it's much more difficult to sell them Capuchinno (you know, like the drink, but misspelled) and this has nothing to do with the technical merit of the technology...

[asookazian]

Nicklas Karlsson wrote on Dec 02, 2009 20:48:


Yes but when it comes to industry adoption, Big Names have the upper hand. You can explain to management that this is from the guys that make Flash etc. but it's much more difficult to sell them Capuchinno (you know, like the drink, but misspelled) and this has nothing to do with the technical merit of the technology...

good point.  it's hard enough to sell Seam.

this is interesting:

http://www.infoq.com/news/2009/12/Google-Stops-Gears

HTML5 aims to reduce the use of proprietary plug-in-based rich Internet application (RIA) technologies such as Adobe Flash, Microsoft Silverlight, and Sun JavaFX, though it would take many years to do so.

HTML5 sounds like a very good idea.....

[asookazian]

This is just downright ludicrous!

Ian Hickson, editor of the HTML5 specification, expects the specification to reach the W3C Candidate Recommendation stage during 2012, and W3C Recommendation in the year 2022 or later.

http://en.wikipedia.org/wiki/HTML5

We'll be dead by 2022

or, there will be no more HTML/web as we know it (we'll visualize all UIs cyborg/android-style and there's no more monitors, keyboards, etc.)

or, else....

why does it take that long?  that's not cloning, weather pattern analysis and forecasting, or rocket science or theoretical physics, etc...

[william.drai]

Nicklas Karlsson wrote on Dec 02, 2009 20:03:


I think the winner of the UI wars will be the first Big Player to have a pretty RIA UI and a complete Java 6 / JSF integration layer. So that if you have a running JSF 2, JPA 2, CDI, BV app, you can automagically hook in the UI to use ValueChangeListeners, have exceptions and validations propagate completely and so on...

That's interesting because that's exactly what we're trying to achieve with GraniteDS by integrating Flex + CDI + JPA + BV, and we are very close to having the full stack with complete typesafety across Flex and Java. The main missing piece that we are currently working on is using the BV annotations on the Flex side to automatically handle validation, but pretty much of the other necessary stuff (client-side DI, exceptions, server-side validation, detached entities, ...) are already here.

Concerning the future of Web framework, I mostly agree with Francisco that server-side UI frameworks like JSF or Wicket are going to disappear but that probably won't happen very soon. A rich client should handle all the presentation layer itself and directly interact with services though REST, Web services or any other protocol.

All I can say is that we are extremely satisfied with our decision to switch from JSF to Flex two years ago. Developing a UI with Flex is a real pleasure, it's very fast, nice looking and handling of browser incompatibilities is a thing of the past. If we had to choose right now, I think we maybe would also give a try to Silverlight, GWT and Ext.

[asookazian]

William Draï wrote on Dec 03, 2009 02:59:


That's interesting because that's exactly what we're trying to achieve with GraniteDS by integrating Flex + CDI + JPA + BV, and we are very close to having the full stack with complete typesafety across Flex and Java. The main missing piece that we are currently working on is using the BV annotations on the Flex side to automatically handle validation, but pretty much of the other necessary stuff (client-side DI, exceptions, server-side validation, detached entities, ...) are already here.

Concerning the future of Web framework, I mostly agree with Francisco that server-side UI frameworks like JSF or Wicket are going to disappear but that probably won't happen very soon. A rich client should handle all the presentation layer itself and directly interact with services though REST, Web services or any other protocol.

All I can say is that we are extremely satisfied with our decision to switch from JSF to Flex two years ago. Developing a UI with Flex is a real pleasure, it's very fast, nice looking and handling of browser incompatibilities is a thing of the past. If we had to choose right now, I think we maybe would also give a try to Silverlight, GWT and Ext.

that was a very interesting post.  When you say we are extremely satisfied with our decision to switch from JSF to Flex two years ago does that mean your GraniteDS team?

The one possible issue I see with Flex is the use of ActionScript, sort of like adding possibly un-reusable Javascript functions to a JSP.  And so there's a learning curve there as well.  But the binary transfer (AMF3 protocol) has an advantage over JSF/RichFaces XML text over the wire...

The interesting thing is how you're handling/integrating BV in Flex. Not sure how that works but we use <s:validate/> in xhtml pages in Seam.

So when will there be a working frmwk download of your stack?  I'm curious to see a Flex+CDI+JPA+BV+GraniteDS example project similar to Seam booking...  handling cross-browser DOM, javascript, etc. issues is a real pain.  hopefully HTML5 will solve that.

[nickarls]

Yes, GraniteDS was one of the things I had in mind

I'm not familiar with the lifecycle of Flex/GraniteDS, how are you dealing with transactions (namely, avoiding LazyLoadingExceptions)? And can you have entities directly in your dropdowns etc?

PS. Anyone else come to think Granite Data Source when they see the name? ;-)

[asookazian]

Nicklas Karlsson wrote on Dec 03, 2009 07:37:




Yes, GraniteDS was one of the things I had in mind

I'm not familiar with the lifecycle of Flex/GraniteDS, how are you dealing with transactions (namely, avoiding LazyLoadingExceptions)? And can you have entities directly in your dropdowns etc?

You avoid LIEs by using SMPC and Hibernate manual flush (i.e. keep the persistence manager (PC) open for the duration of the LRC; LIEs occur when entities become detached from PC when persistence manager closes and object graph navigation occurs in a JSF, for example).  I thought this has nothing to do with the presentation layer or MVC frmwk you use.

PS. Anyone else come to think Granite Data Source when they see the name? ;-)

Yes.  What does the DS stand for?  There is BlazeDS as well, no?  What's the diff b/n the two?

[luxspes]

Arbi Sookazian wrote on Dec 02, 2009 20:55:

Nicklas Karlsson wrote on Dec 02, 2009 20:48:


Yes but when it comes to industry adoption, Big Names have the upper hand. You can explain to management that this is from the guys that make Flash etc. but it's much more difficult to sell them Capuchinno (you know, like the drink, but misspelled) and this has nothing to do with the technical merit of the technology...

good point.  it's hard enough to sell Seam.

Actually, it is not a good point, JavaScript is an entirey different ecosystem and management sees it only as javascript they do not care if you use Prototype, Dojo, jQuery or low level DOM, you can even have some of you pages with Prototype, some with Dojo, some with jQuery and some with plain DOM, and management couldn't care less. And other developers? the also do not care! if you try to switch a project from NotNormalizedTables+JDBC+StoredProcs to NormalizedTables+JPA you are going to fight the development team, the dbas, management, etc. If you decide to use whatever jscript framework you like nobody cares.

this is interesting:

http://www.infoq.com/news/2009/12/Google-Stops-Gears

HTML5 aims to reduce the use of proprietary plug-in-based rich Internet application (RIA) technologies such as Adobe Flash, Microsoft Silverlight, and Sun JavaFX, though it would take many years to do so.

HTML5 sounds like a very good idea.....

HTML (and any of its derivatives like JavaScript) is (IMO) the worst development environment ever, I can not wait for it to die, sadly, it is going the way of COBOL, and it is probably going to be here for quite a long time...

[luxspes]

Arbi Sookazian wrote on Dec 03, 2009 04:41:


The one possible issue I see with Flex is the use of ActionScript, sort of like adding possibly un-reusable Javascript functions to a JSP.

I do not see any relationship between un-reusable Javascript functions in JSPs and ActionScript. ActionScript 3 is very powerful and complete language with full support for the creation of reusable component libraries. The Javascript in browsers is nothing when compared with ActionScript 3.

And so there's a learning curve there as well.  But the binary transfer (AMF3 protocol) has an advantage over JSF/RichFaces XML text over the wire...

A great advantage, the JSF1.x/RichFaces3.x wastes bandwith as if everybody had Gigabit connections. Hope that gets better with JSF2/Richface4...

The interesting thing is how you're handling/integrating BV in Flex. Not sure how that works but we use <s:validate/> in xhtml pages in Seam.

In Flex, you validate with client side code, no need to go all the way to the server just to know if a is a letter or a number. Since Flex has support for metadata, I guess an equivalent to bean validation could be generated form the metadata of JavaBeans.

Of course, this kind of replication is what makes me feel that real future of enterprise aplication development is in something like Dataphor, where you can define the metadata at the database level, and then generate all the upper layers from that (they are now creating a new presentation layer generator based on Silverlight).

So when will there be a working frmwk download of your stack?  I'm curious to see a Flex+CDI+JPA+BV+GraniteDS example project similar to Seam booking...  handling cross-browser DOM, javascript, etc. issues is a real pain.  hopefully HTML5 will solve that.

In a perfect world Flex or Silverlight (or even JavaFx) would kill HTML5 and end this nightmare, but I am to old to believe in fairy tales :'(

[william.drai]

Nicklas Karlsson wrote on Dec 03, 2009 07:37:


Yes, GraniteDS was one of the things I had in mind

I'm not familiar with the lifecycle of Flex/GraniteDS, how are you dealing with transactions (namely, avoiding LazyLoadingExceptions)? And can you have entities directly in your dropdowns etc?


PS. Anyone else come to think Granite Data Source when they see the name? ;-)

The name GraniteDS (Granite Data Services) has been derived from the various Adobe similar products named Flex Data Services (FDS), now LiveCycle Data Services (LCDS) and BlazeDS. It gives better understanding to Flex folks of what the project is (but obviously not for Java folks :-)).

We simply avoid LIEs in GraniteDS by using our own AMF serialization implementation that is aware of the various JPA providers internals. When our serializer detects a non loaded association (Hibernate proxy or persistent collection, EclipseLink weaved object or whatever else), it does not try to go deeper in the object graph and simply sends on the wire in AMF formats the necessary information that will allow to rebuild the proxy or association when deserializing the same object sent back from Flex. This custom serialization of JPA entities to Flex is the main reason why we started the GraniteDS project at the beginning and why we can't use BlazeDS right now because it cannot support this.

Concerning the other question, developing in Flex can be completely typesafe and use the exact same data model in ActionScript than the JPA model (GraniteDS provide an AS3 code generator to keep all this in sync). So yes you can use entities in drop down lists, and in fact it is a lot more typesafe than JSF/Facelets because you never use String-based expressions. It's really very much like Swing (even simpler with basic closure support in AS3 to define event handlers) with an optional XML description language (that is also typesafe because it is compiled to ActionScript by the Flex compiler).

That said this kind of client side type safety is also possible with Silverlight and GWT.