• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Struts JSF Design Flaw (who is to blame)

 
HockeyPlayer NewHampshire
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Folks,

I have been operating struts and web gui for a while coming from past java graphical awt raw graphics development environment and I wanted to point out a couple of things.

GUI has migrated from client to server... with the exception of JavaScript.

We all know that going to the server is bad, but this design model of Struts and JSF appears to be operating exclusively off of the server. This appears to be generally OK for MVC applications and if you are able to segregate your navigation away from your controller operation then you have succeeded in making the GUI operate smoothly with little flickering.

MONKEY tree is a bad example though. Every click goes to the action servlet (hello, we are going to the server)... even for navigation.

The JSF Tree sample does the exact same thing.

What am I suppose to do for raw graphics widgets?

JSF and Struts has omitted any room for accomodating any raw graphics gui components.

JavaScript widgets have been the only way to segregate and modularize/self-contain component oriented GUI in any sane manner rather than spread it out all over the place in XML config files, Java Actions, JSP's and whatever javascript that comes along with your GUI.. not to mention that every single action has to go to the server again and again even if it does not need to or should not or is generally not suppose to.

Actions are classified as follows:
o Navigation (Navigate)
o Operation (CreateReadUpdateDelete - CRUD)

Struts and JSF combine both of these and force them to goto the server. The monkey tree nested tag is a case in point.

I am able to give credit to the fine MVC that comes out of the Struts or JSF. But I cannot prevent the thing from flickering on every button click without having to migrate my GUI into JavaScript. Struts Forms perform distributed MVC beautifully but there is no support for micro graphics on the client without having to goto the server for every time you touch the component.

So I have a question. Do any of the struts/jsf design folks out there have a solution? I do not want to have to implement my GUI in swing or applets.

I am not convinced that the event model they are advocating emulates the swing event model without haveing to operate off of the server for every event.

Component developers prefer to navigate their GUI off of the client and operate state changes off of the server.

Where is the support for client side raw graphics ?
 
Jason Menard
Sheriff
Posts: 6450
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"HockeyPlayer NewHampshire",

Welcome to JavaRanch. We don't have many rules here, but we do have a naming policy. Please re-read this policy and change your display name accordingly.
 
Thomas Paul
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should note that posts that don't follow the naming policy can't win a book!
 
Hans Bergsten
Author
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by HockeyPlayer NewHampshire:
Folks,

I have been operating struts and web gui for a while coming from past java graphical awt raw graphics development environment and I wanted to point out a couple of things.

GUI has migrated from client to server... with the exception of JavaScript.

We all know that going to the server is bad, but this design model of Struts and JSF appears to be operating exclusively off of the server.

[...]
So I have a question. Do any of the struts/jsf design folks out there have a solution? I do not want to have to implement my GUI in swing or applets.

[...]
Where is the support for client side raw graphics ?


Sorry for cutting down the quote som much, but I like to focus on the main points.

JSF and Struts are server-side technologies, typically using a regular HTML browser as the client. An HTML client has lots of limitations in terms of the widgets they support and, unless you use JavaScript or applets, you have to go to the server to get something done. Not sure what you mean with "client side raw graphics", but HTML offers only the <img> tag.

That said, a JSF component can generate JavaScript code in addition to the HTML markup. It's possible to develop custom JSF components that use JavaScript to provide a smother, non-flickering interface, for instance a tree control that expands/collapses nodes with JavaScript, or a calendar that can be scrolled through using JavaScript. The fact that they don't exist yet (AFAIK), is that JSF is still a very new technology. Wait until the fall, and I'm sure you'll see a lot of things like this.

In order to avoid JavaScript, we need more powerful browsers, e.g., browsers with XForms support, so that tree controls, sliders etc. can be handled natively by the browser. A UML browser is another alternative. JSF can, in theory at least, work with an XForms or UML browser instead of an HTML browser, so that's another development we may see in the future.
 
HockeyPlayer NewHampshire
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Hans... it is good to at least know what I am dealing with.

At one point I thought to myself... how could they continue to go this far without even accomodating client side navigation? The pains I have had to go thru for best of breed tree functionality remains unfinished with a whole can of worms opened up with refresh and model state.

I cannot wait 6 months.

For now it seems JavaScript widgets are the best of breed mechanics.

I think I will write a book on these babies.

- cheers
 
bas duijzings
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
oh thomas, that is unfair ! Now nobody will react to this thread...
 
sunitha reghu
Ranch Hand
Posts: 937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I won a book last time, Thomas asked me to show my drivers license to verify my name. Anyway I am happy to know there is a Hockey Player in New Hampshire.


Originally posted by bas duijzings:
oh thomas, that is unfair ! Now nobody will react to this thread...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic