JSF Vs Struts (Portlets perspective)

[Gaurav Jain]

Hi,

What are the major differences between the two?
The client wants to go the prtal way in the future and hence we need to decide that whether to develop the application using JSF or Struts.Which wpould be more easier in this regard that is going the JSF way or the Stry=uts way?
How difficult is it to convert struts to portlets in comparision to converting JSF to portlets?

[garth schneider]

Gaurav,
JSF is the way to go. I have already used JSF inside IBM Websphere Portal.
The JSF is really portable. You write JSF and it just fits into the portal. It is almost like a container agnostic framework. You can write JSF for standard web development and then turn around and put it into a portlet with little if any change. If you are going to want to go to portal down the road use JSF. JSF is the future.
Garth
IBM Certified Enterprise Developer for WSAD 5.0

[Dushy Inguva]

I do agree that JSF "might" be the future. But certainly, it is not for the PRESENT.

It has totally under cooked, and raw. Has many important features missing and you would want to use a layer over JSF (custom built or something like Oracle's ADF).

Here are some features you cannot do with JSF without writing loads of custom code.

1. Customized errors for empty fields (Like "Please select atleast one state" or "Please enter the name"). It always throws "Validation Error: Value is required". Yes, you can change the message by specifying a message bundle, but the same message will appear for checkboxes, radios and text fields etc. Have fun trying to come up with a inert message for all :-)
2. JSF components invoke the getter methods more than once and if the order in which your database returns a list changes, well buddy.. u're screwed (because it does not match rows by key, but assumes you return the same list every time it calls the getter)
3. Most solutions to the problem you are facing would be to make the bean a "session" scope. Thats just plain dumb as you're dead if you have more than browser window trying to manipulate state.
4. Most solutions (try asking in the forums) for common problems would require you to "cache" the data in the beans without loading it every time in the getters. Thats just violates every architectural caching principle. Caching has to be done not by the programmer but by using an optimizes database cache (Tangosol Coherence or JCache etc)
5. How do you have line breaks for your check box component descriptions?? - h:selectManyCheckbox ? You can't. Yes.. you cant unless you put it inside a datatable. Now, the validations are screwed as it will invoke the validator many times.
6. Its very confusing for the users as every page submits to itself (heard its this way in .NET also). Example: You will see URLs in the browser like DeleteMail.jsp that lists all the mail ;-)
7. All of your beans have to have application level unique names, as there is no way to divide your application into sub-modules like struts.
8. How do you do tiles with JSF? Simple. For EVERY single page, create another page that dictates the tile layout. Suddenly, you have twice the number of pages with half of them doing nothing at all.
9. Using JSTL in JSF produces un-specified results. It works sometimes and does not work others. Try it out if you want.
10. And, WSAD generates IBM specific code if you try to use it's drag and drop JSF build features.

Now that list is just from the top of my head. JSF has the capacity to be a cool framework (Say in JSF 3.0 or something), but right now, it just plain sucks.

My advise: Try a non trivial sample project with JSF and analyze for yourself.

Thanks,
Dushy

p.s: This response by me does not consider the "Portlets Perspective", this is just plain JSF. Imagine how many "wonders" you will come across with Portlets :-)
[ January 30, 2005: Message edited by: Dushy Inguva ]

[Varun Khanna]

1. Customized errors for empty fields (Like "Please select atleast one state" or "Please enter the name"). It always throws "Validation Error: Value is required". Yes, you can change the message by specifying a message bundle, but the same message will appear for checkboxes, radios and text fields etc. Have fun trying to come up with a inert message for all :-)

You can play around, without loads of code. Use component's "id" property to fetch label if you want. Now your messages will contain field's name
OR if you want conponent specific different message, pick the message from properties file mapped with formName:ComponentId combination. That wont be a "loads of code".

2. JSF components invoke the getter methods more than once and if the order in which your database returns a list changes, well buddy.. u're screwed (because it does not match rows by key, but assumes you return the same list every time it calls the getter)

Can you explain ? Which key you talking about ?

3. Most solutions to the problem you are facing would be to make the bean a "session" scope. Thats just plain dumb as you're dead if you have more than browser window trying to manipulate state.

true.

5. How do you have line breaks for your check box component descriptions?? - h:selectManyCheckbox ? You can't. Yes.. you cant unless you put it inside a datatable. Now, the validations are screwed as it will invoke the validator many times.

Customization in rendered doesnt worked? ... wont be loads of code probably. You might need to play with few TDs & TRs.

6. Its very confusing for the users as every page submits to itself (heard its this way in .NET also). Example: You will see URLs in the browser like DeleteMail.jsp that lists all the mail ;-)

?

7. All of your beans have to have application level unique names, as there is no way to divide your application into sub-modules like struts.

Why you want to give two beans a same name?

9. Using JSTL in JSF produces un-specified results. It works sometimes and does not work others. Try it out if you want.

Agreed.

10. And, WSAD generates IBM specific code if you try to use it's drag and drop JSF build features.

Don't use properitery components, if possible. Also get rid of that "generateCode" tag at the top of each page. That will make your life simpler and wont create hx: tag un-necessarily.
But don't blame JSF for this. It's WSAD's fault

Now that list is just from the top of my head. JSF has the capacity to be a cool framework (Say in JSF 3.0 or something),

Lets hope it will go better only.

[Abioye Bankole]

Struts vs JSF? Dont use either. Use Tapestry. It is much better than both. And it has an awesome component framework, too!! Struts does not really have a component framework for writing and using reusable components on a web page. I hv not lookd @ d portlet perspective, anyways.

[Dushy Inguva]

Abioye,

I haven't given a serious thought about Tapestry until TheServerSide.com used it - see this discussion I gotta check it out one of these days.

It sounds and looks like a really productive framework. But, thinking in a long term, I do not know if there will be as many Tapestry aware developers (say 2-3 years from now... if we need to add some functionality to an existing product of ours). I might be wrong though!!! So, convincing my company might be a big challenge :roll:

[Dushy Inguva]

Varun,

You can play around, without loads of code. Use component's "id" property to fetch label if you want. Now your messages will contain field's name OR if you want conponent specific different message, pick the message from properties file mapped with formName:ComponentId combination. That wont be a "loads of code".

I am not sure how you can achieve the following with a required="true" attribute (I am not talking about validator="" because, a validator is NOT invoked if the component is empty)
1. UserName text field: Please enter your user name
2. Password confirmation text field: Password has to be entered twice.

Can you explain ? Which key you talking about ? (Regarding getters methods...)

Well, this is a LONG story. The JSF spec does not specify how many times the components on the screen can call getter methods on the beans. (ill be surprised if i read this part of the spec wrong).

Suppose you have a <h ataTable value="#{myBean.someList}" ... >
Now, assume your database list keeps changing (contents might be added or deleted to the list but the individual items themselves remain the same.. and assume the list you get from the database does not follow any order. The only thing you have to associate is a unique key)

1. Browser requests for the page.
2. our getSomeList() method is invoked.
3. JSF displays the page (we're all happy and greatful )
4. assume our row contents are editable. (User changes the content of the 5th row.. lets call this row Bob)
5. User presses Submit.
6. JSF invokes getSomeList() (in the second phase)
7. We query database. Bob is present. But he is not the 5th row anymore. He is the 6th row)
8. JSF invokes the setter on the 5th row, which is NOT Bob
9. were screwed

The components in JSF do not have a link to the model. And, unlike in Swing (which i Love) there is no comprehensive model lifecycle management (I am referring to all those cute rowsAdded() rowsRemoved() events in Swing - i am not comparing JSF to swing!!!)
And, it is unfortunate that the default JSF components choose to associate the model items with index and NOT with a primary key (EJB does not work this way.. there is a primary key in Entity Beans - anyway, entity beans are outside the scope of this topic)

Ok long story short.. this is the reason why My Faces has components which remember the model and do not invoke the getters atleast in the second phase of the lifecycle.

Customization in rendered doesnt worked? ... wont be loads of code probably. You might need to play with few TDs & TRs.

Thats what I am saying. For something as simple as i was referring to, I have to write a custom component. (With swing, i can extend an existing component and write my new flashy component with much ease. Legal Disclaimer: I am not comparing JSF to swing. ) Anyway, what i wanted to point out is that it is fairly non trivial to write a custom component.

Why you want to give two beans a same name?

Why do we have packages in java? So that just in case we have 2 classes named the same, it offers scope resolution. The same reason. Anyways, I was also trying to point out the lack of sub-modules like in Struts.

Don't use properitery components, if possible. Also get rid of that "generateCode" tag at the top of each page. That will make your life simpler and wont create hx: tag un-necessarily. But don't blame JSF for this. It's WSAD's fault

Totally right. But, JSF was supposed to be tooled. And, all these tool vendors try to tie you down. Its unfortunate. (There are a couple of tools that provide clean implementations, but I was not impressed by their features. example: Exadel studio and something else that I can't remember.) Sun's Creator is nice but is useless except for real small applications. I cannot understand why the creator is not a full fledged IDE or why it is not part of the Sun's IDE suite.

Oh boy !!! Look what 3 months of JSF did to me.. For the next project, I am going to fight my way out of a JSF using application or so I hope...
[ January 31, 2005: Message edited by: Dushy Inguva ]

[Abioye Bankole]

Originally posted by Dushy Inguva:
Abioye,

It sounds and looks like a really productive framework. But, thinking in a long term, I do not know if there will be as many Tapestry aware developers (say 2-3 years from now... if we need to add some functionality to an existing product of ours). I might be wrong though!!! So, convincing my company might be a big challenge :roll:

You hv a point, convincing your company might be difficult even after convincing urself. This is 1 of the reasons i resigned from my former company. I am just 2 critical about the technologies i use.

However, if u evaluate Tapestry and u eventually agree its the preferred framework, what stops it from becoming the most-widely used? It's in our hands - the community. it's up 2 us 2 spread d news and convince programmers that the more pple adopt it, the more standard, it would be..

[Varun Khanna]

quote:
--------------------------------------------------------------------------------
You can play around, without loads of code. Use component's "id" property to fetch label if you want. Now your messages will contain field's name OR if you want conponent specific different message, pick the message from properties file mapped with formName:ComponentId combination. That wont be a "loads of code".
--------------------------------------------------------------------------------



I am not sure how you can achieve the following with a required="true" attribute (I am not talking about validator="" because, a validator is NOT invoked if the component is empty)
1. UserName text field: Please enter your user name
2. Password confirmation text field: Password has to be entered twice.

Look out for validateValue() method in the UIInputClass :
Inside the following if block :

if (isValid() && isRequired() && isEmpty(newValue)) {
 
}
 

You can get the component id, for which you are doing the "required" check.
And once you have the component, you can pick the messages the way you want.

quote:
--------------------------------------------------------------------------------
Can you explain ? Which key you talking about ? (Regarding getters methods...)
--------------------------------------------------------------------------------



Well, this is a LONG story. The JSF spec does not specify how many times the components on the screen can call getter methods on the beans. (ill be surprised if i read this part of the spec wrong).

Suppose you have a <h ataTable value="#{myBean.someList}" ... >
Now, assume your database list keeps changing (contents might be added or deleted to the list but the individual items themselves remain the same.. and assume the list you get from the database does not follow any order. The only thing you have to associate is a unique key)

1. Browser requests for the page.
2. our getSomeList() method is invoked.
3. JSF displays the page (we're all happy and greatful )
4. assume our row contents are editable. (User changes the content of the 5th row.. lets call this row Bob)
5. User presses Submit.
6. JSF invokes getSomeList() (in the second phase)
7. We query database. Bob is present. But he is not the 5th row anymore. He is the 6th row)
8. JSF invokes the setter on the 5th row, which is NOT Bob
9. were screwed

The components in JSF do not have a link to the model. And, unlike in Swing (which i Love) there is no comprehensive model lifecycle management (I am referring to all those cute rowsAdded() rowsRemoved() events in Swing - i am not comparing JSF to swing!!!)
And, it is unfortunate that the default JSF components choose to associate the model items with index and NOT with a primary key (EJB does not work this way.. there is a primary key in Entity Beans - anyway, entity beans are outside the scope of this topic)

Ok long story short.. this is the reason why My Faces has components which remember the model and do not invoke the getters atleast in the second phase of the lifecycle.

Don't make any selection from dataTable based upon the index.
In addition to the scenario you mentioned, if you are doing sorting - well you will be in mess.
We have a identifier (unique) for each row of datatble. And do operation based upon the identifier. Don't rely upon the index as any row can hold a particular index depending upon the sorting, or say if database refreshes.

quote:
--------------------------------------------------------------------------------
Customization in rendered doesnt worked? ... wont be loads of code probably. You might need to play with few TDs & TRs.
--------------------------------------------------------------------------------

Thats what I am saying. For something as simple as i was referring to, I have to write a custom component.

Yes and only once

Anyways, I was also trying to point out the lack of sub-modules like in Struts.

Haven't worked on struts (Not sure what sub-modules are)

quote:
--------------------------------------------------------------------------------
Don't use properitery components, if possible. Also get rid of that "generateCode" tag at the top of each page. That will make your life simpler and wont create hx: tag un-necessarily. But don't blame JSF for this. It's WSAD's fault
--------------------------------------------------------------------------------



Totally right. But, JSF was supposed to be tooled. And, all these tool vendors try to tie you down. Its unfortunate.

Agreed

[Diego Duarte]

I think that jsf it's realy more fast to make web applications, but only when good visual tools be finished. At the moment i dont see a realy big diference!
But remenber, jsf will be best choice soon!
It�s just that i think!

sory for bad english!

Di�go Gon�alves Duarte
[email protected]
Belo Horizonte/MG - Brasil

[Dushy Inguva]

Varun,

My point was really not to ask for solutions to say "7 things that I cannot do with JSF". It was more to point out the inherent short comings of the spec. Like say, no decent integration with tiles (or any other tiling framework support) etc !!!

JSF might one day become the default way to build webapps. And I certainly hope it does. But, after what the JCP spec members did to EJB(EJB 3 is still a long way to go ), I am very very doubtful it will.

Infact, I spoke to the a big guy involved with JSF from Sun, and he did point out that one of the problems was that Craig had to do a lot of sizing down of the spec to satisfy all the big guys(read IBM,BEA et al) in the spec committee.

Its truly pathetic that something that took nearly 3 years is so poorly defined. Hope it will change for the better in version 3 (As you can see, I have hardly any hopes it will really fly in version 2 ;-) )

Cheers,
Dushy

[Varun Khanna]

Originally posted by Dushy Inguva:
Varun,

My point was really not to ask for solutions ...

And this you are telling me now after I've done so much of typing and messed my head around formatting the replies



Okey even I support you in what you said about the technology, but more than the implementation it's the idea that's more catchy and fascinating for me.
Lets give SUN sometime to mature this technology and since you have already seen how pain it is,as of now, in some of the aspects I hope you are probably going to enjoy most of its growth. I hope RI team must be gathering the feedback from people like you and would be working on making this the next big thing ...

[Dushy Inguva]

And this you are telling me now after I've done so much of typing and messed my head around formatting the replies

Oops!!! My Bad... I'm Sorry
I truly respect you patiently trying to answer all of them.

Right now, I can only hope JSF will mature into a really productive framework and in the mean time, try to convince my company to use Tapestry / Struts for the next project

[Gregg Bolinger]

Originally posted by Dushy Inguva:
Like say, no decent integration with tiles (or any other tiling framework support) etc !!!

I know you were just throwing this into the wind, however, why should Sun have to create a technology that integrates well with some other open source technoclogy? There is no reason for this to be done. And with that being said, MyFaces has built in Tiles support.

[Scott Duncan]

why should Sun have to create a technology that integrates well with some other open source technoclogy?

Too true, they shouldn't. I think that the point should be focused on integrating tiles like functionality into JSF though. When making a comparison, the lack of customizable templetes via mappings is a shortcoming of JSF. JSF needs to give developers the ability to focus on the content of the page. Writing the look and feel of the application should only need to be done once. This means less JSP/html code to write and also makes pages/applications easier to maintain.

[Gregg Bolinger]

Originally posted by William Duncan:


Too true, they shouldn't. I think that the point should be focused on integrating tiles like functionality into JSF though. When making a comparison, the lack of customizable templetes via mappings is a shortcoming of JSF. JSF needs to give developers the ability to focus on the content of the page. Writing the look and feel of the application should only need to be done once. This means less JSP/html code to write and also makes pages/applications easier to maintain.

See, I don't see it as a shortcomming. This is what CSS was designed for. Create the page and anything that needs to be visually spruced up, use CSS. You can do page layouts really easily with CSS. Don't give me yet another XML file to maintain.

[Scott Duncan]

Don't give me yet another XML file to maintain.

Cannot argue with that.

[Rigel Kentaurus]

Originally posted by K Varun:


Lets hope it will go better only.

Could you elaborate in how to do the customized error messages for fields. Right now I am using a <h:message for="componentId" /> for printing the error message, but I can't find some way to print a non-default jfc message for each textfield

[Varun Khanna]

Originally posted by Rigel Kentaurus:


Could you elaborate in how to do the customized error messages for fields. Right now I am using a <h:message for="componentId" /> for printing the error message, but I can't find some way to print a non-default jfc message for each textfield

If you have noticed, the generic exception message is always thrown from methods having access to UIcomponent object. Now since you have the access to UIComponent, you actually have an access to component whose validation, conversion or xyz has resulted in an error message. Call the getId() method on UIComponent to generate component specific messages or call getType() to generate type specific or, or ... anything you want.

[Joe San]

So, What would be the Climax?? JSF or Struts??