Frustrated with the Roo JSP Implementation

[henryve]

I have decided to use Roo with JSF because I wanted to use PrimeFaces, however, the way Roo has implemented it frustrates me.

All the forms are implemented as Dialogs and although it works with Firefox, I can't get it to work for IE. I have attempted to change the Dialogs to Panels, but the behaviour is very inconsistent. For example, I set the closeable attribute to TRUE, but no Close button displays.

I must admit I am no JSF expert, so any pointer would help, or should I just can this whole JSF idea. I am sold on the JPA implementation of Roo though, so would like to stick to that.

BTW, thread title should not have JSP, but rather JSF.

[spgmx]

My expirience with the ROO generated UI (Jsp's + Controllers):
It fits perfectly for simple CRUD UI's but as soon as you need more it becomes hard.
You should better build the UI yourself if you need more than simple CRUD, but you can use Roo still up to the service layer level. Further more I would really recommend everybody to use Roo generated DAOs and not ActiveRecord-entities since Spring JPA data is much more capable then the AR-approach.

Other alternative could be to extend the UI addons. I looked into the code, but it is still very abstract for me what's going on here with all this metadata stuff, AspectJ and code generators

Just my 2 ct...

[delgad9]

My expirience with the ROO generated UI (Jsp's + Controllers):
It fits perfectly for simple CRUD UI's but as soon as you need more it becomes hard.
You should better build the UI yourself if you need more than simple CRUD, but you can use Roo still up to the service layer level. Further more I would really recommend everybody to use Roo generated DAOs and not ActiveRecord-entities since Spring JPA data is much more capable then the AR-approach.

Other alternative could be to extend the UI addons. I looked into the code, but it is still very abstract for me what's going on here with all this metadata stuff, AspectJ and code generators

Just my 2 ct...

1) I agree on "You should better build the UI"... part. But you can still leverage a great percentage of what SR generates for you. Please review: http://pragmatikroo.blogspot.com/201...rspective.html
2) I don't agree on "Further more I would really recommend everybody to use Roo generated DAOs and not ActiveRecord". The convenience of AR is the fact that avoids tons of "don't repeat yourself" plumbing code. I think DAOs are a legacy of the EJB 1.0-2.1 mentality era and it is going to stay with us for while.


B. Roogards
jD @ http://pragmatikroo.blogspot.com

[spgmx]

2) I don't agree on "Further more I would really recommend everybody to use Roo generated DAOs and not ActiveRecord". The convenience of AR is the fact that avoids tons of "don't repeat yourself" plumbing code. I think DAOs are a legacy of the EJB 1.0-2.1 mentality era and it is going to stay with us for while.

This shows me that you don't know Spring JPA Data

[delgad9]

This shows me that you don't know Spring JPA Data

I believe any developer has the right to use whatever approach, She/He is convenient for handling their projects...

B. and apologetic Roogards
jD @ http://pragmatikroo.blogspot.com

[henryve]

Thanks, yes, I have used the DAO pattern. If now I could just get past this JSF hurdle. I seemed to have managed somewhat in replacing the PF Dialogs with Panels by adding some helpful methods to the UI Bean class, and it seems that JSF does not like it when more than one form is contained per page. This usage of JSF where all the UI elements are contained in one page is giving me a hard time.