-
1. Re: Weld + Scala (+JSP)
asookazian Nov 14, 2009 8:15 PM (in response to luxspes)you live on the bleeding edge. what is the probability of a corporate project using Weld and Scala in the next 6-12 months?
-
2. Re: Weld + Scala (+JSP)
luxspes Nov 14, 2009 9:31 PM (in response to 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!
-
3. Re: Weld + Scala (+JSP)
luxspes Nov 14, 2009 9:37 PM (in response to luxspes)And of course using JSP for the UI!
-
4. Re: Weld + Scala (+JSP)
nickarls Nov 14, 2009 9:38 PM (in response to luxspes)
Francisco Peredo wrote on Nov 14, 2009 21:37:
And of course using JSP for the UI!Pagan! ;-)
-
5. Re: Weld + Scala (+JSP)
gavin.king Nov 14, 2009 9:41 PM (in response to luxspes)
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 :-)
-
6. Re: Weld + Scala (+JSP)
gavin.king Nov 14, 2009 9:42 PM (in response to 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!That would actually be pretty interesting to see. I want to see how Scala can actually improve the code...
-
7. Re: Weld + Scala (+JSP)
asookazian Nov 14, 2009 11:08 PM (in response to 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 :-)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...
-
8. Re: Weld + Scala (+JSP)
asookazian Nov 14, 2009 11:09 PM (in response to luxspes)Oh, hey, Francisco. Since you're from another dimension like me, you should integrate Tapestry with Weld as well.
oh hey, Weld.NET!
-
9. Re: Weld + Scala (+JSP)
luxspes Nov 15, 2009 4:47 AM (in response to 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 ;-)
-
10. Re: Weld + Scala (+JSP)
luxspes Nov 15, 2009 5:14 AM (in response to 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 toget 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 isgood
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...
-
11. Re: Weld + Scala (+JSP)
asookazian Nov 15, 2009 5:53 AM (in response to luxspes)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.
-
12. Re: Weld + Scala (+JSP)
luxspes Nov 15, 2009 3:14 PM (in response to 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...)
-
13. Re: Weld + Scala (+JSP)
luxspes Nov 17, 2009 2:23 PM (in response to 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.