Weld + Scala (+JSP)

[luxspes]

Well, I decided that it was possible (and easy) to integrate Weld with JSP, I was going to do the same thing but now with Scala.
It turns out is very easy, all I had to do was create a dynamic web project in Eclipse 3.5 (with the scala plugin already installed), add
the Scala nature to the project, and configure everything as I did form my Weld + JSP project, but write the bean in Scala:

package testingscalaweld

import java.io.Serializable;

import javax.enterprise.context.SessionScoped;
import javax.inject.Named;

@Named{val value="greeter"}
@SessionScoped
class Greeter extends Serializable {
     
  @scala.reflect.BeanProperty
  var message="Hello Scala!";

}

And it worked perfectly!

[asookazian]

you live on the bleeding edge.  what is the probability of a corporate project using Weld and Scala in the next 6-12 months?

[luxspes]

LOL. Well today is saturday, so today I can play in the bleeding edge. BTW my next post will be about the numberguess app migrated to Scala/Weld!

[luxspes]

And of course using JSP for the UI!

[nickarls]

Francisco Peredo wrote on Nov 14, 2009 21:37:


And of course using JSP for the UI!

Pagan! ;-)

[gavin.king]

Nicklas Karlsson wrote on Nov 14, 2009 21:38:

Francisco Peredo wrote on Nov 14, 2009 21:37:


And of course using JSP for the UI!

Pagan! ;-)

Hehe, I know. I always hated JSP :-)

[gavin.king]

LOL. Well today is saturday, so today I can play in the bleeding edge. BTW my next post will be about the numberguess app migrated to Scala/Weld!

That would actually be pretty interesting to see. I want to see how Scala can actually improve the code...

[asookazian]

Gavin King wrote on Nov 14, 2009 21:41:

Nicklas Karlsson wrote on Nov 14, 2009 21:38:

Francisco Peredo wrote on Nov 14, 2009 21:37:


And of course using JSP for the UI!

Pagan! ;-)

Hehe, I know. I always hated JSP :-)

I detest JSP as well (well, nowadays, not back in 2000).  We are using this library now with Struts (something else which makes me gag):

http://displaytag.sourceforge.net/1.2/

It's difficult to go back to projects using action-based frmwks like Struts or SpringMVC after you've used JSF...

[asookazian]

Oh, hey, Francisco.  Since you're from another dimension like me, you should integrate Tapestry with Weld as well.

oh hey, Weld.NET!

[luxspes]

Arbi Sookazian wrote on Nov 14, 2009 23:09:


Oh, hey, Francisco.  Since you're from another dimension like me, you should integrate Tapestry with Weld as well.

That could be interesting, but first let me finish to learn how to play with JSP/Weld...

oh hey, Weld.NET!

That would be even more interesting... if I had the time, I'd try to do it ;-)

[luxspes]

Gavin King wrote on Nov 14, 2009 21:41:

Nicklas Karlsson wrote on Nov 14, 2009 21:38:

Francisco Peredo wrote on Nov 14, 2009 21:37:


And of course using JSP for the UI!

Pagan! ;-)

Hehe, I know. I always hated JSP :-)

Ha! I do not love JSP either... but I just have been unable to see a big advantage in JSF...take CRUD for example, JBSEAM-3903, yes that is a seam-gen bug, but lets ask ourselves why CRUD is so hard to get right with JSF... I feel this kind of bugs happen simply because we refuse to accept the fact that some kind of jobs are better done client-side in JavaScript...

I feel JSP is good for html document manipulation, JavaScript is good for applications in a single page... JSF... I am just not sure of its purpose anymore...

One thing I want to try is how Railo and Weld could play together... but I guess I'll have to leave that for another weekend...

[asookazian]

JSP is basically a servlet with UI tags (presentation tier component).

JSF is a component-based MVC framework with UI components.  Not sure what exactly it has to do directly with CRUD b/c the model portion can be pluggable in JSF (JPA, Hibernate, iBATIS, JDBC, etc.) and is thus independent of the view and controller.

I don't want to be able to use scriptlet code in my view components, hence xhtml templates.

[luxspes]

Arbi Sookazian wrote on Nov 15, 2009 05:53:


JSP is basically a servlet with UI tags (presentation tier component).

JSF is a component-based MVC framework with UI components.  Not sure what exactly it has to do directly with CRUD b/c the model portion can be pluggable in JSF (JPA, Hibernate, iBATIS, JDBC, etc.)

Read the bug... why the value gets lost? It is not because JPA made its work incorrectly, it is because...

and is thus independent of the view and controller.

... because this guys are not doing the job they should. They should be preserving information that maybe is not ready to be sent to the database, but that the user certainly expects to be preserver (at least until the conversation ends) but they fail to do it... the JSF abstraction leaks, and information gets lost

I don't want to be able to use scriptlet code in my view components, hence xhtml templates.

You do not have to use scriptlet  code in JSP either, if fact, I am not going to use a single line of scriptlet in my NumberGuess port to JSP. (And if I were porting it to JavaScript... well I guess then I would have to write javascript code, but I can also achieve good MVC separation using jQuery then...)

[luxspes]

So Arbi... have you downloaded the scriptlet free  NumberGuess port to JSP?

Were you able to see the abstraction leak in JSF? Remember, CRUD is not just not something for the model to deal, CRUD are 4 actions (Create, Read, Update, Delete) that should be available for the user to play with, in a safe way, are 4 actions that should be easy to implement in 2009 with JSF/Seam/JPA, but that, in fact, is still very hard to get right. To avoid misunderstandings, from now on, I will refer to this CRUD that involves all the layers in the application as MVC-CRUD.

The priciples that seam-gen should be following are detailed at the NakedObjects project... it should be as easy as defining the model and have seam-gen do all the job... but it turns that generating the UI is not such an easy thing to do, because models are complex. It would be funny (if it were not such a monumental waste of time), that when someone asks how hard is to do an MVC-CRUD everybody says it is easy, and when you ask them to do it for a complex model, they answer they will have it in a few hours or days... that after real QA testing become weeks, and then months, and then...

And that is what makes me distrust JSF, if people with a lot more experience than me with it are not able to generate an application from a complex model, that means (to me) that the viability of the technology is compromised. JSF might look good under small controlled situations, but in my experience, outside, in the complex real world, its abstraction leaks over-complicating an already difficult task: To create CRUD-VC from CRUD-M ;-).

Some people have asked me how I dare to be preferring JSP over JSF in 2009... and all I can answer is: Because I have no better standard choice. At least with JSP I have full control over what happens, and lots of developers available to do manually what should be the job of a tool like seam-gen. WebObjects had something like seam-gen (called Direct2Web) that could deal with with complex models 10 years ago, it could dynamically (at runtime) present a CRUD UI that could deal with any model, and you were able to ask it to freeze in to manually modifiable source... Maybe I should be the one asking others about anachronisms... ;-)

Of course, it is quite possible that the next version of seam-gen does a much better job at dealing with complex models, maybe by getting integrated with something like Metawidget. Who knows, maybe I'll get to be proven wrong... or maybe not.... it is very important to be careful with this things, because it could seem as if JSF found a solution for this problem when in reality what we are getting is an application in a single page and in that case, the credit goes to javascript, not to JSF.