Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JSF: What UI components are available?  RSS feed

 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66141
141
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since JSF ultimately relies upon the browser to render the user-facing interface, is it correct to assume that the UI components are limited to the HTML-defined form controls and other elements? Or does JSF provide some client-side technology to extend the UI component set?
 
Bill Dudney
Author
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bear,
Well that is one of the cool things about JSF. The spec and the RI expect that you will be doing JSF through JSP's and going out HTML to a browser. But JSF does not require that. In fact you could have JFS serve up XUL.
But there is no magic...
So for the time being with the RI we are limited (as you said) to the HTML defined controls.
Hope this helps!
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66141
141
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, since the capabilities of the user-facing UI are not extended, would you say that the major benefit of JSF over a traditional Model 2/servlet/JSP approach is organizational? (At least when it comes to web applications)
 
Bill Dudney
Author
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bear,
Well I'd say that the major benefit of JSF is architectural. With JSF you get a component based server side programming model. Events are fired and listeners listen etc. Also since you have a component on the back end its got extension points. Lets say you wanted a custom UIOutput that spit out the html <code> element (I know why would anyone do that with CSS, go with me for a minute to see the point ). With JSF all you have to do is implement a renderer. If you want to change the HTML that a Struts tag outputs you are more or less out of luck.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66141
141
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Got it. Thanks.
 
Prakash Dwivedi
Ranch Hand
Posts: 452
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lets say you wanted a custom UIOutput that spit out the html <code> element (I know why would anyone do that with CSS, go with me for a minute to see the point ). With JSF all you have to do is implement a renderer.
Hello Bill,
I am having small confusion, it appears in JSF it will be developer's job to make sure how the JSP looks. That is, Developer's will be doing UI Design. Also every time there is some change in UI, java code will be changed. Is it true?
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Prakash Dwivedi:

Hello Bill,
I am having small confusion, it appears in JSF it will be developer's job to make sure how the JSP looks. That is, Developer's will be doing UI Design. Also every time there is some change in UI, java code will be changed. Is it true?

I hope there should be JSF developers and JSP developers, which seperates the job of UI design and coding...
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
However, honestly, nowadays, we are all one-man-bank!
In my company, I need to work from high level design work to low level programming work, in addition with test plans and test cases creation.
Thus, we finally need to do everything.
Nick.
 
Prakash Dwivedi
Ranch Hand
Posts: 452
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my company, I need to work from high level design work to low level programming work,
Hello Nicholas Cheung,
High Level Design is different from designing UI Component in Html, taking care of color combination, spaces between two text fields etc. Normally this part is done by a designer, and that was the main reason why JSPs were introduced, to seperate design work from development, this makes life little easier for Java Developer .
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66141
141
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
that was the main reason why JSPs were introduced, to seperate design work from development

But Nicholas' point is quite true. I've never worked anyplace where there were 'page authors' that were separate from the Java developers. Most everyone works at all levels of the application. While there may be places where there is a layered separation of effort, I'd say they're the exception rather than the rule.
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bear Bibeault:

But Nicholas' point is quite true. I've never worked anyplace where there were 'page authors' that were separate from the Java developers. Most everyone works at all levels of the application. While there may be places where there is a layered separation of effort, I'd say they're the exception rather than the rule.

I do agree with Bear as well. That's why we, previously used to develop JSP, are willing to learn JSF and we will finally become person like Bear has just mentioned above...
It is very less likely that a company will hire two seperate developers to handle JSF and JSP development...
 
Ben Poole
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bear Bibeault:

But Nicholas' point is quite true. I've never worked anyplace where there were 'page authors' that were separate from the Java developers. Most everyone works at all levels of the application. While there may be places where there is a layered separation of effort, I'd say they're the exception rather than the rule.

Thirded! Although I'm aware of the reasoning behind the development of JSP technology, I've not witnessed developers working on code whilst designers work on UI - most organisations seem to expect both from one person / team of developers.
I'd be interested to know of any contrary cases, and how well they worked.
 
Prakash Dwivedi
Ranch Hand
Posts: 452
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While there may be places where there is a layered separation of effort, I'd say they're the exception rather than the rule.
Well at least in my organization we have seperation of works. A prototype comprising od JSPs is developed first. These JSPs doesn't contains any scriplet or java code. Once this layout is approved by the client Java Developers add their code. As we are using struts, all we have to do is change html tags to struts tag. java developers never go into designing part.
Personally i feel web-designing is a very challenging job. I have found, every time professional designers design a web-page it is far superior than the page designed by a java Developer. Also when we have frameworks which totally seperate your presentation layer, than why not take advantage of it?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66141
141
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I didn't say such places do not exist, or say that separation is a bad thing. I merely pointed out that most shops don't operate that way.
Personally, even though I write everything from the DB access layer to the DHTML, I code my web apps as if every layer were a separate entity. That's just good architecture. And with the advent of JSTL, it becomes much more feasible to eliminate Java scriptlets from JSP pages which, even for someone who is highly Java-savvy, makes them easier to maintain.
So please do not think that I am advocating no separation -- quite the opposite. Just keep in mind that it's possible to layer an app appropriately, even if there are not separate developers writing each layer.
 
Bill Dudney
Author
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
Great discussion!
JSF does provide the separation between View and other stuff. Changes in UI do not require java changes if your view is build in JSP. If you view is build in java code then obviously you'd need to change the java code. It will be very atypical for at least the foreseeable future that views will be done in anything except JSP so I think it is safe to say that changes in UI will not require changes in Java code.
On the separation front. I have worked in a place where the UI team was separate from the business logic & persistence team. The UI developers though were fluent java programmers that also knew JSP so there was not the separation that is discussed in many JSP related writings. I'm not sure that is all together practical to expect those roles to be separate. However I am hopeful that some day we can reach the point where it is practical. And in shooting for that ideal we end up with better frameworks that help us separate out concerns. The worst thing for a UI is to have business logic imbedded in it (well maybe not the absolute worst thing but its really awful ). So shooting for the ideal separation points us to the separation that is necessary to build maintainable robust web apps.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66141
141
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The worst thing for a UI is to have business logic imbedded in it (well maybe not the absolute worst thing but its really awful

Yeah, my list of things that are more awful than that is pretty short, and mostly involve the terms "inoperable" and "audit".
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!