In this article I will demonstrate how such manipulation can be implemented. The case here is a prototype for an Evaluation Application for our technische sessions. The session coordinator can predefine the questions he wants to put to the attendants. Based on these question-definitions, each session attendant will be presented with a web-page with all the questions and (multiple choice) answer options. This same approach can be used for Quiz and on Line Exam applications. The JSF implementation used is the standard JSR (Sun) Reference Implementation (1.1).Is this feature of JSF useful for you? Why or why not?
-
Changing JSF Pages Programmatically (59 messages)
- Posted by: Joseph Ottinger
- Posted on: May 11 2006 12:13 EDT
One of the features in Java Server Faces that distinguishes it is the ability to access UI Components programmatically, at run-time. In this article, Lucas Jellema shows how components can be created and manipulated via a question-and-answer form.Threaded Messages (59)
- Changing JSF Pages Programmatically by Daniel Selman on May 11 2006 14:20 EDT
- Changing JSF Pages Programmatically by Mark N on May 11 2006 20:00 EDT
- Learn JSF 1.2 by Deepak Kumar on June 11 2007 10:27 EDT
- JSF is a steaming pile by Michael Cohen on May 11 2006 14:24 EDT
- JSF is a steaming pile by Alexandre Poitras on May 11 2006 15:46 EDT
-
JSF is a steaming pile by Michael Cohen on May 11 2006 04:39 EDT
- JSF is a steaming pile by Michael Jouravlev on May 11 2006 04:55 EDT
- JSF is a steaming pile by George Jiang on May 11 2006 08:12 EDT
-
JSF is a steaming pile by Werner Punz on May 12 2006 06:13 EDT
-
JSF is a steaming pile by Michael Cohen on May 12 2006 10:20 EDT
-
JSF is a steaming pile by Jacob Hookom on May 12 2006 10:37 EDT
-
JSF is a steaming pile by Eelco Hillenius on May 12 2006 11:05 EDT
- JSF is a steaming pile by Dennis Bekkering on May 12 2006 12:15 EDT
-
JSF is a steaming pile by Eelco Hillenius on May 12 2006 11:05 EDT
-
JSF is a steaming pile by Steve Zara on May 12 2006 10:41 EDT
- JSF is a steaming pile by Eelco Hillenius on May 12 2006 11:15 EDT
-
JSF is a steaming pile by Michael Cohen on May 12 2006 11:24 EDT
- JSF is a steaming pile by Alexandre Poitras on May 12 2006 12:21 EDT
-
JSF is a steaming pile by Eelco Hillenius on May 12 2006 12:21 EDT
-
JSF is a steaming pile by Dennis Bekkering on May 12 2006 12:55 EDT
-
JSF is a steaming pile by Alexandre Poitras on May 12 2006 01:09 EDT
- JSF is a steaming pile by Dennis Bekkering on May 12 2006 01:21 EDT
-
JSF is a steaming pile by Alexandre Poitras on May 12 2006 01:09 EDT
-
JSF is a steaming pile by Dennis Bekkering on May 12 2006 12:55 EDT
- JSF is a steaming pile by Steve Zara on May 12 2006 12:23 EDT
- JSF is a steaming pile by Dennis Bekkering on May 12 2006 12:13 EDT
-
Re: JSF is a steaming pile by George Jiang on May 16 2006 12:22 EDT
-
Re: JSF is a steaming pile by Steve Zara on May 16 2006 05:15 EDT
-
Re: JSF is a steaming pile by Dennis Bekkering on May 16 2006 12:33 EDT
-
Re: JSF is a steaming pile by George Jiang on May 16 2006 06:59 EDT
- Re: JSF is a steaming pile by Dennis Bekkering on May 17 2006 09:35 EDT
- Re: JSF is a steaming pile by Dennis Bekkering on May 17 2006 09:42 EDT
-
Re: JSF is a steaming pile by George Jiang on May 16 2006 06:59 EDT
-
Re: JSF is a steaming pile by George Jiang on May 16 2006 07:28 EDT
- Re: JSF is a steaming pile by Steve Zara on May 16 2006 08:08 EDT
-
Re: JSF is a steaming pile by Dennis Bekkering on May 16 2006 12:33 EDT
- Re: JSF is a steaming pile by Mark N on May 16 2006 09:48 EDT
-
Re: JSF is a steaming pile by Steve Zara on May 16 2006 05:15 EDT
-
JSF is a steaming pile by Jacob Hookom on May 12 2006 10:37 EDT
-
JSF is a steaming pile by Michael Cohen on May 12 2006 10:20 EDT
- JSF is a steaming pile by Alexandre Poitras on May 12 2006 07:52 EDT
-
JSF is a steaming pile by Michael Cohen on May 11 2006 04:39 EDT
- JSF is a steaming pile by Werner Punz on May 12 2006 06:05 EDT
- JSF is a steaming pile by Alexandre Poitras on May 11 2006 15:46 EDT
- Changing JSF Pages Programmatically by Dmitry Namiot on May 11 2006 15:26 EDT
- Changing JSF Pages Programmatically by Alexandre Poitras on May 11 2006 15:57 EDT
-
Changing JSF Pages Programmatically by Dmitry Namiot on May 11 2006 04:16 EDT
-
Changing JSF Pages Programmatically by Sergey Smirnov on May 11 2006 07:44 EDT
-
Changing JSF Pages Programmatically by Michael Cohen on May 11 2006 07:58 EDT
-
Changing JSF Pages Programmatically by Sergey Smirnov on May 11 2006 08:48 EDT
-
Changing JSF Pages Programmatically by Michael Cohen on May 11 2006 09:20 EDT
-
Changing JSF Pages Programmatically by Sergey Smirnov on May 11 2006 10:06 EDT
-
Changing JSF Pages Programmatically by George Jiang on May 11 2006 11:36 EDT
-
Changing JSF Pages Programmatically by Craig McClanahan on May 12 2006 12:07 EDT
- Changing JSF Pages Programmatically by George Jiang on May 12 2006 02:25 EDT
- Changing JSF Pages Programmatically by Sergey Smirnov on May 12 2006 12:07 EDT
-
Changing JSF Pages Programmatically by Craig McClanahan on May 12 2006 12:07 EDT
-
Changing JSF Pages Programmatically by George Jiang on May 11 2006 11:36 EDT
-
Changing JSF Pages Programmatically by Sergey Smirnov on May 11 2006 10:06 EDT
-
Changing JSF Pages Programmatically by Michael Cohen on May 11 2006 09:20 EDT
- Changing JSF Pages Programmatically by Dennis Bekkering on May 12 2006 12:10 EDT
-
Changing JSF Pages Programmatically by Sergey Smirnov on May 11 2006 08:48 EDT
- Changing JSF Pages Programmatically by Marina Prikaschikova on May 12 2006 04:30 EDT
-
Changing JSF Pages Programmatically by Michael Cohen on May 11 2006 07:58 EDT
- Changing JSF Pages Programmatically by Dennis Bekkering on May 12 2006 12:11 EDT
-
Changing JSF Pages Programmatically by Sergey Smirnov on May 11 2006 07:44 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Michael Jouravlev on May 11 2006 04:41 EDT
- Changing JSF Pages Programmatically OR Back To Servlets by Alexandre Poitras on May 12 2006 07:54 EDT
- Changing JSF Pages Programmatically OR Back To Servlets by Alexandre Poitras on May 12 2006 11:18 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Werner Punz on May 12 2006 01:27 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Dennis Bekkering on May 12 2006 01:44 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Eelco Hillenius on May 12 2006 02:03 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Dennis Bekkering on May 12 2006 03:46 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Eelco Hillenius on May 12 2006 04:56 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Eelco Hillenius on May 12 2006 04:58 EDT
- Re: Changing JSF Pages Programmatically OR Back To Servlets by Dennis Bekkering on May 15 2006 10:25 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Eelco Hillenius on May 12 2006 04:58 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Eelco Hillenius on May 12 2006 04:56 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Dennis Bekkering on May 12 2006 03:46 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Eelco Hillenius on May 12 2006 02:03 EDT
-
Changing JSF Pages Programmatically OR Back To Servlets by Dennis Bekkering on May 12 2006 01:44 EDT
-
Changing JSF Pages Programmatically by Dmitry Namiot on May 11 2006 04:16 EDT
- Changing JSF Pages Programmatically by Alexandre Poitras on May 11 2006 15:57 EDT
-
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Daniel Selman
- Posted on: May 11 2006 14:20 EDT
- in response to Joseph Ottinger
This might be a useful capability for rules-based forms (questionnaires). We sometimes see customers building such applications with ILOG JRules. One answer on a page drives the generation of a second question, that was dependent on the first answer.
Does anyone know whether the technique described by the author would integrate neatly with an Ajax-based approach? Anyone know the story on JSF and XForms integration?
Daniel Selman -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Mark N
- Posted on: May 11 2006 20:00 EDT
- in response to Daniel Selman
I have an application that does this (uses Drools). I decided to go with Swing because I wanted the rules to run on the client (plus other things).
I am now faced with a slightly different user base. So I might have to do a subset of the app with a browser app. I would like to use JSF, it it can be coded easily, or will go with Echo2. I am not even sure it will work in a browser. Some of the rules fire "follow-on" questions while other popup instructional messages (the part that might not work). -
Learn JSF 1.2[ Go to top ]
- Posted by: Deepak Kumar
- Posted on: June 11 2007 10:27 EDT
- in response to Daniel Selman
Hi, Learn JSF 1.2 at http://www.roseindia.net/jsf/jsf1.2/index.shtml Site is providing many examples of JSF 1.2 Thanks -
JSF is a steaming pile[ Go to top ]
- Posted by: Michael Cohen
- Posted on: May 11 2006 14:24 EDT
- in response to Joseph Ottinger
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core_rt" %>
<%@ page import="java.util.List, java.util.ArrayList"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Untitled</title>
</head>
<body>
<form method="post">
<table>
<tr>
<td>Question</td>
<td><input name="question"/></td>
</tr>
<tr>
<td>Answer Style</td>
<td><input type="radio" name="answerStyle" value="o"/>Open Answer
<input type="radio" name="answerStyle" value="s"/>Single Answer
<input type="radio" name="answerStyle" value="m"/>Multiple Answer
</td>
</tr>
<tr>
<td>Widget Style</td>
<td><input type="radio" name="widgetStyle" value="tick"/>Radio/Check
<input type="radio" name="widgetStyle" value="list"/>List
<input type="radio" name="widgetStyle" value="menu"/>Menu
</td>
</tr>
<tr>
<td>Answer Options</td>
<td><textarea rows="5" cols="40" name="options"></textarea></td>
</tr>
<tr>
<td><input type="submit" value="Rephrase Question"/></td>
<td></td>
</tr>
</table>
</form>
<hr/>
<%
String[] lines = request.getParameter("options").split("\n");
List pairs = new ArrayList();
for (String s : lines) {
String[] pair = s.split(",");
pairs.add(pair);
}
pageContext.setAttribute("size", pairs.size());
pageContext.setAttribute("answers", pairs);
%>
<form method="post">
<table>
<tr><td colspan="2">Could you please answer the following question:</td></tr>
<c:if test="${! empty param.question}">
<tr>
<td>Question</td>
<td>${param.question}</td>
</tr>
<tr>
<td>Answer</td>
<td>
<c:if test="${param.answerStyle == 'o'}">
<input name="answer" />
</c:if>
<c:if test="${param.answerStyle != 'o'}">
<c:if test="${param.widgetStyle == 'tick'}">
<c:forEach items="${answers}" var="pair">
${pair[1]}
<c:if test="${param.answerStyle == 's'}">
<input type="radio" name="answer" value="${pair[0]}"/>
</c:if>
<c:if test="${param.answerStyle == 'm'}">
<input type="checkbox" name="answer" value="${pair[0]}"/>
</c:if>
</c:forEach>
</c:if>
<c:if test="${param.widgetStyle != 'tick'}">
<select name="answer" <c:if test="${param.widgetStyle == 'list'}">size="${size}"</c:if> <c:if test="${param.answerStyle == 'm'}">multiple</c:if>>
<c:forEach items="${answers}" var="pair">
<option value="${pair[0]}">${pair[1]}</option>
</c:forEach>
</select>
</c:if>
</c:if>
</td>
</tr>
<tr>
<td colspan="2"><input type="submit" value="Post Your Answer" /></td>
</tr>
</c:if>
</table>
</form>
</body>
</html> -
JSF is a steaming pile[ Go to top ]
- Posted by: Alexandre Poitras
- Posted on: May 11 2006 15:46 EDT
- in response to Michael Cohen
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core_rt" %><%@ page import="java.util.List, java.util.ArrayList"%><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head> <title>Untitled</title></head><body><form method="post"><table> <tr> <td>Question</td> <td><input name="question"/></td> </tr> <tr> <td>Answer Style</td> <td><input type="radio" name="answerStyle" value="o"/>Open Answer <input type="radio" name="answerStyle" value="s"/>Single Answer <input type="radio" name="answerStyle" value="m"/>Multiple Answer </td> </tr> <tr> <td>Widget Style</td> <td><input type="radio" name="widgetStyle" value="tick"/>Radio/Check <input type="radio" name="widgetStyle" value="list"/>List <input type="radio" name="widgetStyle" value="menu"/>Menu </td> </tr> <tr> <td>Answer Options</td> <td><textarea rows="5" cols="40" name="options"></textarea></td> </tr> <tr> <td><input type="submit" value="Rephrase Question"/></td> <td></td> </tr></table></form><hr/><% String[] lines = request.getParameter("options").split("
"); List pairs = new ArrayList(); for (String s : lines) { String[] pair = s.split(","); pairs.add(pair); } pageContext.setAttribute("size", pairs.size()); pageContext.setAttribute("answers", pairs); %><form method="post"><table> <tr><td colspan="2">Could you please answer the following question:</td></tr> <c:if test="${! empty param.question}"> <tr> <td>Question</td> <td>${param.question}</td> </tr> <tr> <td>Answer</td> <td> <c:if test="${param.answerStyle == 'o'}"> <input name="answer" /> </c:if> <c:if test="${param.answerStyle != 'o'}"> <c:if test="${param.widgetStyle == 'tick'}"> <c:forEach items="${answers}" var="pair"> ${pair[1]} <c:if test="${param.answerStyle == 's'}"> <input type="radio" name="answer" value="${pair[0]}"/> </c:if> <c:if test="${param.answerStyle == 'm'}"> <input type="checkbox" name="answer" value="${pair[0]}"/> </c:if> </c:forEach> </c:if> <c:if test="${param.widgetStyle != 'tick'}"> <select name="answer" <c:if test="${param.widgetStyle == 'list'}">size="${size}"</c:if> <c:if test="${param.answerStyle == 'm'}">multiple</c:if>> <c:forEach items="${answers}" var="pair"> <option value="${pair[0]}">${pair[1]}</option> </c:forEach> </select> </c:if> </c:if> </td> </tr> <tr> <td colspan="2"><input type="submit" value="Post Your Answer" /></td> </tr> </c:if></table></form></body></html>
This is exactly one of the problem JSF solves. No more horrible long pages full of JSTL. There is no encapsulation at all with this technic and no separation of concerns. Good luck trying to reuse this piece of code... -
JSF is a steaming pile[ Go to top ]
- Posted by: Michael Cohen
- Posted on: May 11 2006 16:39 EDT
- in response to Alexandre Poitras
This is exactly one of the problem JSF solves. No more horrible long pages full of JSTL. There is no encapsulation at all with this technic and no separation of concerns. Good luck trying to reuse this piece of code...
fine, so put the 20 lines of jstl in a custom tag. you're not going to get any more reuse out of the jsf component in this example than you would a jsp custom tag.
but the point was really that jsf is basically a rube goldberg machine. in the end we're dealing with html elements and request params. i think the component based approach is misguided. a leaky abstraction as they say. not to mention that the more ajaxy the interface is the more useless jsf is rendered (no pun intended). -
JSF is a steaming pile[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: May 11 2006 16:55 EDT
- in response to Michael Cohen
the more ajaxy the interface is the more useless jsf is rendered (no pun intended).
I agree. What is the point to generate JSF markup using println's, then to parse it to make HTML+Javascript out it, then to parse HTML on the browser and to build some stuff on the browser using loaded Javascript. Too much processing.
Using XML analogy, you can either create an XML file and then parse it with a parser, or you can create a binary DOM tree and parse it. Unless a tree is really-really huge, the latter approach is obviously better. Same here. Ok, JSF defines components, events, stuff like this. Define it in an object tree and send this tree off to the browser using JSON.
Oh, the tree is actually already there, this is what JSF does on "restore view" phase, right? Does a regular user of JSF have a programmatic access to this tree, so the tree could be manipulated without writing all those <h:...> tags into text stream? If yes, here you go, the very minor thing that is left ;) is to convert this tree into usable Javascript structure, then send it to the browser. Event handlers, message resources: if they can be handled client-side, send them too. If not, use Ajax to process them. Umm, now I am thinking: how this is different from a distributed Swing application, where UI is controlled by Javascript? -
JSF is a steaming pile[ Go to top ]
- Posted by: George Jiang
- Posted on: May 11 2006 20:12 EDT
- in response to Michael Cohen
but the point was really that jsf is basically a rube goldberg machine. in the end we're dealing with html elements and request params. i think the component based approach is misguided. a leaky abstraction as they say.
Smart developers like to use a rube goldberg machine, but not necessarily good developers. -
JSF is a steaming pile[ Go to top ]
- Posted by: Werner Punz
- Posted on: May 12 2006 06:13 EDT
- in response to Michael Cohen
This is exactly one of the problem JSF solves. No more horrible long pages full of JSTL. There is no encapsulation at all with this technic and no separation of concerns. Good luck trying to reuse this piece of code...
fine, so put the 20 lines of jstl in a custom tag. you're not going to get any more reuse out of the jsf component in this example than you would a jsp custom tag.but the point was really that jsf is basically a rube goldberg machine. in the end we're dealing with html elements and request params. i think the component based approach is misguided. a leaky abstraction as they say. not to mention that the more ajaxy the interface is the more useless jsf is rendered (no pun intended).
If you render against HTML yes, you deal with html elements.
But if you render against something else ;-)
But the componentization does not stop on simple elements and you would lose the entire event handling validation etc... infrastructure if you go for pure jsp taglibs.
As for the ajaxy thing, I do not see it. Ajax introduces a good set of added javascript code, having that and the entire event and validation infrastructure covered in tags and backend side components helps a lot to reduce code bloat.
As for backend side manipulation of a rendering, this is a very valid usecase, which happens very often. The approach really is quite swing like and has the advantage of being able to render uis automatically in a programmatic way, which is often easier than having to deal with myriads of c:ifs in a template.
Another good example is to use the binding code as control parametrizer, you then have one central place where you can adjust the controls within one switch. (but that is somehow out of scope of this article)
The posted example of jsp code really is an antipattern, lots of control flow in the page, scriptlets, no subtemplating which makes a reuse absolutely impossible, even layouting changes.
Believe me I have seen so much of this code in the past and most of it ended in a maintenance nightmare par excellence. -
JSF is a steaming pile[ Go to top ]
- Posted by: Michael Cohen
- Posted on: May 12 2006 10:20 EDT
- in response to Werner Punz
As for backend side manipulation of a rendering, this is a very valid usecase, which happens very often. The approach really is quite swing like and has the advantage of being able to render uis automatically in a programmatic way, which is often easier than having to deal with myriads of c:ifs in a template.
Why are a myriad of if statements any easier to deal with in java code than in template text? any why would i want to make web development more swing-like? i don't think it's controversial to say that swing is inherently more complex than rendering html pages. maybe html with heavy javascript and dom manipulation interacting with the server via ajax approaches the complexity of swing, but you have all that added complexity of the js stuff with jsf too. the fair comparison is with plain old generated html. and comparing the action/request based frameworks like webwork and spring spitting out html with jsf, well, i just don't see the bang for the buck for jsf. too much complexity for what you get in return. and yes, i understand you can render to multiple devices. i've heard that before. and most of us will still only ever render to html.As for the ajaxy thing, I do not see it.
I thought it was fairly obvious. The more of your application you move to the client the less relevant is what's on the server. i saw james strachan questioning on here not too long ago whether ajax would be the end of the web frameworks, just have ajax code calling services. regardless of whether you're willing to go that far, the inverse relationship exists. the more ajaxy my application is the more gui manipulation i'm going to be doing in javascript rather than with server side code. it's interesting that the jsf advocates are fond of pointing out how swing-like jsf is when really, if we are to make a more swing-like *application* (rather than a swing-like framework), we'll move large portions of our code, including the majority of the user interface code, onto the client, and jsf will be of little utility. -
JSF is a steaming pile[ Go to top ]
- Posted by: Jacob Hookom
- Posted on: May 12 2006 10:37 EDT
- in response to Michael Cohen
Why are a myriad of if statements any easier to deal with in java code than in template text? any why would i want to make web development more swing-like? i don't think it's controversial to say that swing is inherently more complex than rendering html pages.
That's everyone's problem. They are all about quick ways to render a page then treat the related postback of information-- the whole 'application' aspect of development as an afterthought.it's interesting that the jsf advocates are fond of pointing out how swing-like jsf is when really, if we are to make a more swing-like *application* (rather than a swing-like framework), we'll move large portions of our code, including the majority of the user interface code, onto the client, and jsf will be of little utility.
This is a major misstep in your analysis. The services approach with AJAX solves only a fraction of the overall problem: you can't marshall business logic, and once you have the data you still have to coordinate it in the presentation, I'm not even going to go into the security issues involved.
The whole presentation/business separation is a joke. What if doing something in the UI, based on business logic, affects multiple parts of the page? Where's that logic going to go? Even then, how are you going to coordinate the request/response? Pre-specifying updated parts of the page that are interelated over multiple AJAX requests is innefficient over the network and only works for segregate examples.
Start thinking about the bigger picture-- AJAX is only a way of communicating between the client and server. Not some golden hammer that will fix the deficiencies of traditional Model 2/Action frameworks. -
JSF is a steaming pile[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: May 12 2006 11:05 EDT
- in response to Jacob Hookom
That's everyone's problem. They are all about quick ways to render a page then treat the related postback of information-- the whole 'application' aspect of development as an afterthought.
+1it's interesting that the jsf advocates are fond of pointing out how swing-like jsf is
I wish it was more like Swing actually.when really, if we are to make a more swing-like *application* (rather than a swing-like framework), we'll move large portions of our code, including the majority of the user interface code, onto the client, and jsf will be of little utility.
Potentially that is true. However, as long as things like session management (the current user etc?) count, and you don't want to make everything into a service (which imo is useful in its' flexibility of utilization but aweful in it's rigidness/ maintainability and it's procedural nature), you still can benefit from using 'server side' frameworks. I think it remains to be seen whether every web application that will be build the next few years will be 100% ajax. More likely, it will be a mix, where some don't use ajax at all, some go all the way and most just use ajax for some of the extras, while at the same time making sure they provide backwards compatibility. -
JSF is a steaming pile[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 12 2006 12:15 EDT
- in response to Eelco Hillenius
I wish it was more like Swing actually.
this one too -
JSF is a steaming pile[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 12 2006 10:41 EDT
- in response to Michael Cohen
any why would i want to make web development more swing-like?
Because GUI APIs like Swing are based on years of experience of how users actually use interfaces and of good practices of how to develop such interfaces.we'll move large portions of our code, including the majority of the user interface code, onto the client, and jsf will be of little utility
This doesn't follow. JSF components can automate the generation of client-side user interface code - why should I have to explicitly code and test client-side code when I can use an off-the-shelf JSF component that does all this for me?
Also, as Jacob Hookum recent blogged, putting lots of code client side is a bad idea in some ways - it is yet another tier of development, perhaps involving yet more DTOs. -
JSF is a steaming pile[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: May 12 2006 11:15 EDT
- in response to Steve Zara
any why would i want to make web development more swing-like?
Because GUI APIs like Swing are based on years of experience of how users actually use interfaces and of good practices of how to develop such interfaces.
I think the concepts that you can find in most GUI kits - buttons, labels, panels, etc - proved to be meaningful abstractions for reasoning about user interfaces the last decades. And the interesting thing is that ajax/ javascript libraries also provide sets of widgets, while a massive part of Java webapp developers are stuck in the document/ action/ request parameter mindset for some reason. -
JSF is a steaming pile[ Go to top ]
- Posted by: Michael Cohen
- Posted on: May 12 2006 11:24 EDT
- in response to Steve Zara
Because GUI APIs like Swing are based on years of experience of how users actually use interfaces and of good practices of how to develop such interfaces.
Right, but web development and the user interface as realized in the browser is not the same as building a desktop gui. a request/response paradigm where the interface is dissolved and reconsituted many times throughout the application is quite different than a swing environment. in fact, i question if it even makes since to use swing as a comparison here. if we were emulating swing in a web environment wouldn't our "framework" be written entirely in javascript? with the actual full page changes in response to say a form submission be akin to transitioning to another JFrame?why should I have to explicitly code and test client-side code when I can use an off-the-shelf JSF component that does all this for me?
ok, if you want to put a little google suggest type component on the page sure. i think more probably requirements will dictate that you have some custom interface with some custom interaction. you're not going to go get some prebuilt jsf component which generates the javascript interaction for that.Also, as Jacob Hookum recent blogged, putting lots of code client side is a bad idea in some ways - it is yet another tier of development, perhaps involving yet more DTOs.
well, i'm not sure that the conclusion of jacob's post is that lots of client side code is inherently bad. i think more accurately it's that it represents tremendous effort. i totally agree with him on the latter. he makes an excellent point about how to handle all that business logic we've always coded in java. right now i'm still handling it in java. most of the time it's not too bad. as far as the security issue he raises, i don't really the issue here. to take his example of the dao that returns objects by key, no , of course you're not going to blindly expose this via dwr, the same way you don't blindly expose it in your web framework and pass it whatever id comes in off the request. dwr has access to the httpsession, the same as jsf. finally, i totally agree with him that dom manipulation sucks. this is where a ui framework can help ;) -
JSF is a steaming pile[ Go to top ]
- Posted by: Alexandre Poitras
- Posted on: May 12 2006 12:21 EDT
- in response to Michael Cohen
Because GUI APIs like Swing are based on years of experience of how users actually use interfaces and of good practices of how to develop such interfaces.
Right, but web development and the user interface as realized in the browser is not the same as building a desktop gui. a request/response paradigm where the interface is dissolved and reconsituted many times throughout the application is quite different than a swing environment. in fact, i question if it even makes since to use swing as a comparison here. if we were emulating swing in a web environment wouldn't our "framework" be written entirely in javascript? with the actual full page changes in response to say a form submission be akin to transitioning to another JFrame?why should I have to explicitly code and test client-side code when I can use an off-the-shelf JSF component that does all this for me?
ok, if you want to put a little google suggest type component on the page sure. i think more probably requirements will dictate that you have some custom interface with some custom interaction. you're not going to go get some prebuilt jsf component which generates the javascript interaction for that.
Properties and css allows to customize the interface and in the more extreme cast when it not enough you can still developp a new renderer
http://myfaces.apache.org/sandbox/inputSuggestAjax.html
http://myfaces.apache.org/sandbox/inputSuggest.html
Backing beans allows to customize the interaction. So yes you are going to have prebuilt jsf component for that. -
JSF is a steaming pile[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: May 12 2006 12:21 EDT
- in response to Michael Cohen
but web development and the user interface as realized in the browser is not the same as building a desktop gui. a request/response paradigm where the interface is dissolved and reconsituted many times throughout the application is quite different than a swing environment.
It is very different. And if I may compare with OO <-> RDBMS, one could say you either keep close to that paradigm, and have full control, no surpises and optimal performance, or you try to achieve the ideal of component orientation - for the sake of having a nicer programming model and things like better reuse etc - and choose a framework that tries to bridge the paradigm gap.
Now, in general ORM frameworks like Hibernate made things better for me, but there are days I curse it to the deepest pit I can think off. Same goes for component oriented frameworks in my opinion, though the alternatives differ quite a bit.
-- Eelco -
JSF is a steaming pile[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 12 2006 12:55 EDT
- in response to Eelco Hillenius
but web development and the user interface as realized in the browser is not the same as building a desktop gui. a request/response paradigm where the interface is dissolved and reconsituted many times throughout the application is quite different than a swing environment.
It is very different. And if I may compare with OO <-> RDBMS, one could say you either keep close to that paradigm, and have full control, no surpises and optimal performance, or you try to achieve the ideal of component orientation - for the sake of having a nicer programming model and things like better reuse etc - and choose a framework that tries to bridge the paradigm gap.Now, in general ORM frameworks like Hibernate made things better for me, but there are days I curse it to the deepest pit I can think off. Same goes for component oriented frameworks in my opinion, though the alternatives differ quite a bit.-- Eelco
I dont see the difference between a desktop and a browser, they are both containers with a lot of nested squares. In a abstract GUI API the implementation for swing sets the background by means of a proxy call to the underlying method of a swing component. For an html renderer the implementations writes css rules. I agree that from a low level everything is very different, it is however achievable to hide this completely, i know because i did so. This applies also for persistance. If the criteria API is abstract you can query everything through the interface having your code not only agnostic about database vendor but also of paradigm, i know because i did so. I found a way to switch between OJB, Hibernate and db4objects by setting one configuration parameter, the application code is agnostic about the paradigm and vendor. For the rest i can say that i agree with you on almost everything, i enjoyed the discussion regarding wickets lack of respect a lot. It is good to see some sanity ones in a while. -
JSF is a steaming pile[ Go to top ]
- Posted by: Alexandre Poitras
- Posted on: May 12 2006 13:09 EDT
- in response to Dennis Bekkering
I dont see the difference between a desktop and a browser, they are both containers with a lot of nested squares. In a abstract GUI API the implementation for swing sets the background by means of a proxy call to the underlying method of a swing component. For an html renderer the implementations writes css rules. I agree that from a low level everything is very different, it is however achievable to hide this completely, i know because i did so. This applies also for persistance. If the criteria API is abstract you can query everything through the interface having your code not only agnostic about database vendor but also of paradigm, i know because i did so. I found a way to switch between OJB, Hibernate and db4objects by setting one configuration parameter, the application code is agnostic about the paradigm and vendor. For the rest i can say that i agree with you on almost everything, i enjoyed the discussion regarding wickets lack of respect a lot. It is good to see some sanity ones in a while.but web development and the user interface as realized in the browser is not the same as building a desktop gui. a request/response paradigm where the interface is dissolved and reconsituted many times throughout the application is quite different than a swing environment.
It is very different. And if I may compare with OO <-> RDBMS, one could say you either keep close to that paradigm, and have full control, no surpises and optimal performance, or you try to achieve the ideal of component orientation - for the sake of having a nicer programming model and things like better reuse etc - and choose a framework that tries to bridge the paradigm gap.Now, in general ORM frameworks like Hibernate made things better for me, but there are days I curse it to the deepest pit I can think off. Same goes for component oriented frameworks in my opinion, though the alternatives differ quite a bit.-- Eelco
Well, I agree on the ORM comparaison. There is a big difference between client ui and web browser if you don't use something like AJAX. You can't update just a part of the screen, you have to completely regenerate the page each time. This is why component frameworks were hard to write at first but this is also why they are truly worth it in my opinion. -
JSF is a steaming pile[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 12 2006 13:21 EDT
- in response to Alexandre Poitras
Well, I agree on the ORM comparaison. There is a big difference between client ui and web browser if you don't use something like AJAX. You can't update just a part of the screen, you have to completely regenerate the page each time. This is why component frameworks were hard to write at first but this is also why they are truly worth it in my opinion.
I dont see the difference between a desktop and a browser, they are both containers with a lot of nested squares. In a abstract GUI API the implementation for swing sets the background by means of a proxy call to the underlying method of a swing component. For an html renderer the implementations writes css rules. I agree that from a low level everything is very different, it is however achievable to hide this completely, i know because i did so. This applies also for persistance. If the criteria API is abstract you can query everything through the interface having your code not only agnostic about database vendor but also of paradigm, i know because i did so. I found a way to switch between OJB, Hibernate and db4objects by setting one configuration parameter, the application code is agnostic about the paradigm and vendor. For the rest i can say that i agree with you on almost everything, i enjoyed the discussion regarding wickets lack of respect a lot. It is good to see some sanity ones in a while.but web development and the user interface as realized in the browser is not the same as building a desktop gui. a request/response paradigm where the interface is dissolved and reconsituted many times throughout the application is quite different than a swing environment.
It is very different. And if I may compare with OO <-> RDBMS, one could say you either keep close to that paradigm, and have full control, no surpises and optimal performance, or you try to achieve the ideal of component orientation - for the sake of having a nicer programming model and things like better reuse etc - and choose a framework that tries to bridge the paradigm gap.Now, in general ORM frameworks like Hibernate made things better for me, but there are days I curse it to the deepest pit I can think off. Same goes for component oriented frameworks in my opinion, though the alternatives differ quite a bit.-- Eelco
Well then we agree on the gui thing also, because with non-ajax technique i also wouldn't have a clue how to achieve gui independence. Thats why i dont understand when people say that ajax makes development more complex, that is exactly what it does not, it makes development easy and natural. Offcourse one should not hand code every ajax request but if one still does so one was lying in bed too much lately. -
JSF is a steaming pile[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 12 2006 12:23 EDT
- in response to Michael Cohen
Right, but web development and the user interface as realized in the browser is not the same as building a desktop gui. a request/response paradigm where the interface is dissolved and reconsituted many times throughout the application is quite different than a swing environment.
Why should we let how the interface is realised in the browser influence things to this extent? Seems to be a form of premature optimisation to me.in fact, i question if it even makes since to use swing as a comparison here. if we were emulating swing in a web environment wouldn't our "framework" be written entirely in javascript? with the actual full page changes in response to say a form submission be akin to transitioning to another JFrame?
Surely then you would potentially have to dispatch a huge amount of information to the client, for the Javascript to render?why should I have to explicitly code and test client-side code when I can use an off-the-shelf JSF component that does all this for me?
ok, if you want to put a little google suggest type component on the page sure. i think more probably requirements will dictate that you have some custom interface with some custom interaction. you're not going to go get some prebuilt jsf component which generates the javascript interaction for that.
Sorry, but I don't understand what you mean here. -
JSF is a steaming pile[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 12 2006 12:13 EDT
- in response to Steve Zara
Because GUI APIs like Swing are based on years of experience of how users actually use interfaces and of good practices of how to develop such interfaces.
comments like these sound like music to my ears, keep m comin -
Re: JSF is a steaming pile[ Go to top ]
- Posted by: George Jiang
- Posted on: May 16 2006 00:22 EDT
- in response to Steve Zara
The widespread development of HTML fronted J2EE Intranet applications in the last couple of years is only proof of the failure of Swing.any why would i want to make web development more swing-like?
Because GUI APIs like Swing are based on years of experience of how users actually use interfaces and of good practices of how to develop such interfaces. -
Re: JSF is a steaming pile[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 16 2006 05:15 EDT
- in response to George Jiang
No, it isn't. It is no more proof of the failure of Swing that it is proof of the failure of any other client-side GUI. I would like to see someone try and implement a major Swing application like NetBeans via a web interface! But even if it were, this is nothing to do with my arguments, which is that MVC GUI development with components and events, and the ability to present dialog-box type windows, as used in Swing and countless other GUI systems, is good for both developers and end users. JSF attempts (generally successfully in my view) to implement this approach. Some future continuations-based system (probably in combination with JSF) is likely to do it better. Trying to limit user interface APIs and design based only on how the web works is to ignore 30 years of experience of interface design and implementation.any why would i want to make web development more swing-like?
Because GUI APIs like Swing are based on years of experience of how users actually use interfaces and of good practices of how to develop such interfaces.
The widespread development of HTML fronted J2EE Intranet applications in the last couple of years is only proof of the failure of Swing. -
Re: JSF is a steaming pile[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 16 2006 12:33 EDT
- in response to Steve Zara
dont bother steve, some will never get it.any why would i want to make web development more swing-like?
Because GUI APIs like Swing are based on years of experience of how users actually use interfaces and of good practices of how to develop such interfaces.
The widespread development of HTML fronted J2EE Intranet applications in the last couple of years is only proof of the failure of Swing.
No, it isn't. It is no more proof of the failure of Swing that it is proof of the failure of any other client-side GUI. I would like to see someone try and implement a major Swing application like NetBeans via a web interface!
But even if it were, this is nothing to do with my arguments, which is that MVC GUI development with components and events, and the ability to present dialog-box type windows, as used in Swing and countless other GUI systems, is good for both developers and end users. JSF attempts (generally successfully in my view) to implement this approach. Some future continuations-based system (probably in combination with JSF) is likely to do it better. Trying to limit user interface APIs and design based only on how the web works is to ignore 30 years of experience of interface design and implementation. -
Re: JSF is a steaming pile[ Go to top ]
- Posted by: George Jiang
- Posted on: May 16 2006 18:59 EDT
- in response to Dennis Bekkering
Others will be indulged in the ivy tower and refuse to recognize the reality. -
Re: JSF is a steaming pile[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 17 2006 09:35 EDT
- in response to George Jiang
Others will be indulged in the ivy tower and refuse to recognize the reality.
or in the dungon doing something about there situation, freeing thereselves from imposed stupidity. -
Re: JSF is a steaming pile[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 17 2006 09:42 EDT
- in response to George Jiang
Others will be indulged in the ivy tower and refuse to recognize the reality.
btw you have to very carefull about praising new frameworks the coming time, you might praise mine -
Re: JSF is a steaming pile[ Go to top ]
- Posted by: George Jiang
- Posted on: May 16 2006 19:28 EDT
- in response to Steve Zara
The main problem here is that the desktop paradigm is not necessarily the best for the classic DHTML UI, while AJAX is stretching DHTML to the limit and making JSF less relevant. The success of ASP.NET can not be used as an argument for JSF, since ASP.NET does not even try to use a pure desktop model and abstract away HTTP and HTML. Also, the .NET space had not been flooded with popular Web frameworks, and .NET developers were predominantly ex-VB6 (desktop) programmers (Microsoft bent its DHTML solution to this group of people!).any why would i want to make web development more swing-like?
Because GUI APIs like Swing are based on years of experience of how users actually use interfaces and of good practices of how to develop such interfaces.
The widespread development of HTML fronted J2EE Intranet applications in the last couple of years is only proof of the failure of Swing.
No, it isn't. It is no more proof of the failure of Swing that it is proof of the failure of any other client-side GUI. I would like to see someone try and implement a major Swing application like NetBeans via a web interface!
But even if it were, this is nothing to do with my arguments, which is that MVC GUI development with components and events, and the ability to present dialog-box type windows, as used in Swing and countless other GUI systems, is good for both developers and end users. JSF attempts (generally successfully in my view) to implement this approach. Some future continuations-based system (probably in combination with JSF) is likely to do it better. Trying to limit user interface APIs and design based only on how the web works is to ignore 30 years of experience of interface design and implementation. -
Re: JSF is a steaming pile[ Go to top ]
- Posted by: Steve Zara
- Posted on: May 16 2006 20:08 EDT
- in response to George Jiang
The main problem here is that the desktop paradigm is not necessarily the best for the classic DHTML UI, while AJAX is stretching DHTML to the limit and making JSF less relevant.
The situation with web development is moving so fast that to talk of a 'classic DHTML' is pointless. JSF and AJAX work very well together; having pre-written components that can handle AJAX makes things far easier than having to code all that Javascript yourself. AJAX certainly does not make JSF less relevant. And, sorry, but I don't consider Microsoft approaches to any aspect of development to necessarily be the best example of the way things should be, having had personal experience of their development tools since I used their MASM on my TRS-80 in the mid 70s.
The success of ASP.NET can not be used as an argument for JSF, since ASP.NET does not even try to use a pure desktop model and abstract away HTTP and HTML. Also, the .NET space had not been flooded with popular Web frameworks, and .NET developers were predominantly ex-VB6 (desktop) programmers (Microsoft bent its DHTML solution to this group of people!). -
Re: JSF is a steaming pile[ Go to top ]
- Posted by: Mark N
- Posted on: May 16 2006 09:48 EDT
- in response to George Jiang
It is proof of the Baaaaaa factor.any why would i want to make web development more swing-like?
Because GUI APIs like Swing are based on years of experience of how users actually use interfaces and of good practices of how to develop such interfaces.
The widespread development of HTML fronted J2EE Intranet applications in the last couple of years is only proof of the failure of Swing. -
JSF is a steaming pile[ Go to top ]
- Posted by: Alexandre Poitras
- Posted on: May 12 2006 07:52 EDT
- in response to Michael Cohen
This is exactly one of the problem JSF solves. No more horrible long pages full of JSTL. There is no encapsulation at all with this technic and no separation of concerns. Good luck trying to reuse this piece of code...
fine, so put the 20 lines of jstl in a custom tag. you're not going to get any more reuse out of the jsf component in this example than you would a jsp custom tag.
Totally untrue, a jsp tag at is basic level is only a component that participate in the rendering process (well you can do more but going this way is just reinventing a component model) while a jsf component participates in all the lifecycle phases. For instance, the component controls itself its response to event while in a tradtionnal Action framework, you would do that in a global action or in the jsp page. Smell like procedural code to me. -
JSF is a steaming pile[ Go to top ]
- Posted by: Werner Punz
- Posted on: May 12 2006 06:05 EDT
- in response to Michael Cohen
Thank you for posting an unmaintainable codemess without any separation of concerns ;-) -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Dmitry Namiot
- Posted on: May 11 2006 15:26 EDT
- in response to Joseph Ottinger
So, depending on the choice we need to render the different views. And view in this example is actually generated in our Java code. Like old servlets: out.println(...)
Sure it will work, but I prefer to keep code for controls in JSP. It is just much more easy to update. So this condition could be checked in JSP for example:
if ("s".equalsIgnoreCase(getAnswerStyle()))
Dmitry
Coldbeans -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Alexandre Poitras
- Posted on: May 11 2006 15:57 EDT
- in response to Dmitry Namiot
So, depending on the choice we need to render the different views. And view in this example is actually generated in our Java code. Like old servlets: out.println(...)Sure it will work, but I prefer to keep code for controls in JSP. It is just much more easy to update. So this condition could be checked in JSP for example:if ("s".equalsIgnoreCase(getAnswerStyle()))DmitryColdbeans
Well the backing bean is manipulating complete UI components (like you do in Swing) which is different from only performing some basic markups string concatentation. To me there is a big difference since the separation of concerns is more respected in JSF (the view definition code is separated from the view processing code). -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Dmitry Namiot
- Posted on: May 11 2006 16:16 EDT
- in response to Alexandre Poitras
So all the HTML design goes back to Java code ...
Dmitry -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Sergey Smirnov
- Posted on: May 11 2006 19:44 EDT
- in response to Dmitry Namiot
So all the HTML design goes back to Java code ...Dmitry
Do you see any html tag hardcoded into the code in the original article? Author manipulates with components, but not with the tags. I know people with SWING background who are very happy to have such possibility in JSF.
--
Sergey : https://ajax4jsf.dev.java.net/ -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Michael Cohen
- Posted on: May 11 2006 19:58 EDT
- in response to Sergey Smirnov
Do you see any html tag hardcoded into the code in the original article? Author manipulates with components, but not with the tags.
what's the difference between:
<code>
if ("o".equalsIgnoreCase(getAnswerStyle())) {
answer = (HtmlInputText)application.createComponent(HtmlInputText.COMPONENT_TYPE);
LengthValidator lengthValidator =
(LengthValidator)application.createValidator(LengthValidator.VALIDATOR_ID);
lengthValidator.setMinimum(2); // an answer must have at least two characters
lengthValidator.setMaximum(200); // an answer must be no longer than 200 characters
((HtmlInputText)answer).addValidator(lengthValidator);
// bind the value property to the answer property in the pollPickerBacker bean
answerBinding = application.createValueBinding("#{pollPickerBacker.answer}");
} else {
if ("s".equalsIgnoreCase(getAnswerStyle())) {
if ("tick".equalsIgnoreCase(getWidgetStyle())) {
answer = (HtmlSelectOneRadio)application.createComponent(HtmlSelectOneRadio.COMPONENT_TYPE);
}
if ("list".equalsIgnoreCase(getWidgetStyle())) {
answer = (HtmlSelectOneListbox)application.createComponent(HtmlSelectOneListbox.COMPONENT_TYPE);
}
if ("menu".equalsIgnoreCase(getWidgetStyle())) {
answer = (HtmlSelectOneMenu)application.createComponent(HtmlSelectOneMenu.COMPONENT_TYPE);
}
answerBinding = application.createValueBinding("#{pollPickerBacker.answer}");
} else if ("m".equalsIgnoreCase(getAnswerStyle())) {
if ("tick".equalsIgnoreCase(getWidgetStyle())) {
answer = (HtmlSelectManyCheckbox)application.createComponent(HtmlSelectManyCheckbox.COMPONENT_TYPE);
}
if ("list".equalsIgnoreCase(getWidgetStyle())) {
answer = (HtmlSelectManyListbox)application.createComponent(HtmlSelectManyListbox.COMPONENT_TYPE);
}
if ("menu".equalsIgnoreCase(getWidgetStyle())) {
answer = (HtmlSelectManyMenu)application.createComponent(HtmlSelectManyMenu.COMPONENT_TYPE);
}
answerBinding = application.createValueBinding("#{pollPickerBacker.answers}");
}
answer.getChildren().add(getAnswerOptionItems());
}
</code>
and
<code>
<c:if test="${param.answerStyle == 'o'}">
<input name="answer" />
</c:if>
<c:if test="${param.answerStyle != 'o'}">
<c:if test="${param.widgetStyle == 'tick'}">
<c:forEach items="${answers}" var="pair">
${pair[1]}
<c:if test="${param.answerStyle == 's'}">
<input type="radio" name="answer" value="${pair[0]}"/>
</c:if>
<c:if test="${param.answerStyle == 'm'}">
<input type="checkbox" name="answer" value="${pair[0]}"/>
</c:if>
</c:forEach>
</c:if>
<c:if test="${param.widgetStyle != 'tick'}">
<select name="answer" <c:if test="${param.widgetStyle == 'list'}">size="${size}"</c:if> <c:if test="${param.answerStyle == 'm'}">multiple</c:if>>
<c:forEach items="${answers}" var="pair">
<option value="${pair[0]}">${pair[1]}</option>
</c:forEach>
</select>
</c:if>
</c:if>
</code> -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Sergey Smirnov
- Posted on: May 11 2006 20:48 EDT
- in response to Michael Cohen
Do you see any html tag hardcoded into the code in the original article? Author manipulates with components, but not with the tags.
what's the difference between:<code>.....
You try to compare orange to apple.
In the first case, you have a component tree. I.e. the set of server side components with value binding and other jsf mechanism such as validators associated with the components values. Those component tree will be rendered to the html code if HTML Render Kit is set or to another media.
In the second case, you will have just a pure html code as a result on immediate compilation. No any binding with server side object when the data is submitted. This bunch of code is still ahead.
I do not say that the fist variant is a completed application already, but the level of abstraction is much higher. You do not have to have a deal with request parameters directly. The submitted value are passed defined validators and converters. The model is updated, the appropriate listeners are called and finally, you have a deal with calling the application logic on the Invoke Application phase of the JSF life cycle.
--
Sergey : https://ajax4jsf.dev.java.net/ -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Michael Cohen
- Posted on: May 11 2006 21:20 EDT
- in response to Sergey Smirnov
yes, no databinding or server side validation with the jsp i posted. in practice i doubt many people would write that exactly as i have. it was used to make the point that jsf is needlessly complex. typically we're using someone's framework, like spring, that does the databinding and validation for us, so yes, we're working with domain objects in our java code that have request values bound to them just as you do with a jsf managed bean. we just don't bother with modeling an html element or some arbitrary group of html elements in java code. -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Sergey Smirnov
- Posted on: May 11 2006 22:06 EDT
- in response to Michael Cohen
Actually, the article shows a possibility, but not a necessity to create a component composition in java code like in SWING programming. At the same time, your code snippet can be easily converted to work in the JSF environment using Facelets. You have an opportunity to have best of both worlds. With introducing JSF 1.2 and JSP 2.1 soon, this will be a JavaEE standard.
--
Sergey : https://ajax4jsf.dev.java.net/ -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: George Jiang
- Posted on: May 11 2006 23:36 EDT
- in response to Sergey Smirnov
With introducing JSF 1.2 and JSP 2.1 soon, this will be a JavaEE standard.
What will be a JavaEE standard? -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Craig McClanahan
- Posted on: May 12 2006 00:07 EDT
- in response to George Jiang
With introducing JSF 1.2 and JSP 2.1 soon, this will be a JavaEE standard.
What will be a JavaEE standard?
Both JSF 1.2 and JSP 2.1 are required parts of the Java EE 5 platform specification, which was recently finalized in the JCP voting process. That means any app server conforming to Java EE 5 must provide a JSF 1.2 implementation (along with all of the other required specs like EJB3).
Craig -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: George Jiang
- Posted on: May 12 2006 02:25 EDT
- in response to Craig McClanahan
poor javaee, how can she bear the weight of such a machine while carrying the legacy of j2ee? -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Sergey Smirnov
- Posted on: May 12 2006 00:07 EDT
- in response to George Jiang
With introducing JSF 1.2 and JSP 2.1 soon, this will be a JavaEE standard.
What will be a JavaEE standard?
I mean, since JavaEE 5, JavaServer Faces is a part of JavaEE. JSF and JSP expert groups worked together to avoid incompatibility between JSP and JSF. In particular, the unified EL is introduced. Now, it is possible to use both, immediate ${} and deferred #{} with JSF components. It is possible to use c:forEach c:if and other jstl tags along with JSF tags on the same page.
--
Sergey : https://ajax4jsf.dev.java.net/ -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 12 2006 12:10 EDT
- in response to Michael Cohen
Do you see any html tag hardcoded into the code in the original article? Author manipulates with components, but not with the tags.
what's the difference between:<code>if ("o".equalsIgnoreCase(getAnswerStyle())) { answer = (HtmlInputText)application.createComponent(HtmlInputText.COMPONENT_TYPE); LengthValidator lengthValidator = (LengthValidator)application.createValidator(LengthValidator.VALIDATOR_ID); lengthValidator.setMinimum(2); // an answer must have at least two characters lengthValidator.setMaximum(200); // an answer must be no longer than 200 characters ((HtmlInputText)answer).addValidator(lengthValidator); // bind the value property to the answer property in the pollPickerBacker bean answerBinding = application.createValueBinding("#{pollPickerBacker.answer}"); } else { if ("s".equalsIgnoreCase(getAnswerStyle())) { if ("tick".equalsIgnoreCase(getWidgetStyle())) { answer = (HtmlSelectOneRadio)application.createComponent(HtmlSelectOneRadio.COMPONENT_TYPE); } if ("list".equalsIgnoreCase(getWidgetStyle())) { answer = (HtmlSelectOneListbox)application.createComponent(HtmlSelectOneListbox.COMPONENT_TYPE); } if ("menu".equalsIgnoreCase(getWidgetStyle())) { answer = (HtmlSelectOneMenu)application.createComponent(HtmlSelectOneMenu.COMPONENT_TYPE); } answerBinding = application.createValueBinding("#{pollPickerBacker.answer}"); } else if ("m".equalsIgnoreCase(getAnswerStyle())) { if ("tick".equalsIgnoreCase(getWidgetStyle())) { answer = (HtmlSelectManyCheckbox)application.createComponent(HtmlSelectManyCheckbox.COMPONENT_TYPE); } if ("list".equalsIgnoreCase(getWidgetStyle())) { answer = (HtmlSelectManyListbox)application.createComponent(HtmlSelectManyListbox.COMPONENT_TYPE); } if ("menu".equalsIgnoreCase(getWidgetStyle())) { answer = (HtmlSelectManyMenu)application.createComponent(HtmlSelectManyMenu.COMPONENT_TYPE); } answerBinding = application.createValueBinding("#{pollPickerBacker.answers}"); } answer.getChildren().add(getAnswerOptionItems()); }</code>and <code><c:if test="${param.answerStyle == 'o'}"> <input name="answer" /> </c:if> <c:if test="${param.answerStyle != 'o'}"> <c:if test="${param.widgetStyle == 'tick'}"> <c:forEach items="${answers}" var="pair"> ${pair[1]} <c:if test="${param.answerStyle == 's'}"> <input type="radio" name="answer" value="${pair[0]}"/> </c:if> <c:if test="${param.answerStyle == 'm'}"> <input type="checkbox" name="answer" value="${pair[0]}"/> </c:if> </c:forEach> </c:if> <c:if test="${param.widgetStyle != 'tick'}"> <select name="answer" <c:if test="${param.widgetStyle == 'list'}">size="${size}"</c:if> <c:if test="${param.answerStyle == 'm'}">multiple</c:if>> <c:forEach items="${answers}" var="pair"> <option value="${pair[0]}">${pair[1]}</option> </c:forEach> </select> </c:if> </c:if> </code>
the first is refactorable the latter not -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Marina Prikaschikova
- Posted on: May 12 2006 04:30 EDT
- in response to Sergey Smirnov
Author manipulates with components
author prepares a part of the page in Java code. There could be components as well as markup tags.
Marina
http://www.servletsuite.com -
Changing JSF Pages Programmatically[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 12 2006 12:11 EDT
- in response to Dmitry Namiot
So all the HTML design goes back to Java code ...Dmitry
i hope so -
Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: May 11 2006 16:41 EDT
- in response to Alexandre Poitras
Well the backing bean is manipulating complete UI components (like you do in Swing) which is different from only performing some basic markups string concatentation. To me there is a big difference since the separation of concerns is more respected in JSF (the view definition code is separated from the view processing code).
Yikes! If there is a strong desire to make highly dynamic UI for the Web, it should be done via Javascript. *THAT* would be real separation of concerns.
Removing "if"s from a page and putting "println"s to a bean does not really make a difference. XAML designers apparently feel the same, they allow both markup and code both in XML and in code-behind class, because XML + code-behind is actually one thing split in two just for convenience.
To make a Javascript client tolerant to user's activities I suggest to devise a unified programmatic API for common browser features like navigation. It would allow a webapp to turn THE FREAKING RELOAD AND BACK BUTTONS OFF on any browser to ensure that a customized DOM tree is not accidently reloaded. -
Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]
- Posted by: Alexandre Poitras
- Posted on: May 12 2006 07:54 EDT
- in response to Michael Jouravlev
Well the backing bean is manipulating complete UI components (like you do in Swing) which is different from only performing some basic markups string concatentation. To me there is a big difference since the separation of concerns is more respected in JSF (the view definition code is separated from the view processing code).
Yikes! If there is a strong desire to make highly dynamic UI for the Web, it should be done via Javascript. *THAT* would be real separation of concerns. Removing "if"s from a page and putting "println"s to a bean does not really make a difference. XAML designers apparently feel the same, they allow both markup and code both in XML and in code-behind class, because XML + code-behind is actually one thing split in two just for convenience.To make a Javascript client tolerant to user's activities I suggest to devise a unified programmatic API for common browser features like navigation. It would allow a webapp to turn THE FREAKING RELOAD AND BACK BUTTONS OFF on any browser to ensure that a customized DOM tree is not accidently reloaded.
Well its depend if you want to handle this on the client side or on the server side. Not every organizations are ready to jump on the Ajax wagon. -
Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]
- Posted by: Alexandre Poitras
- Posted on: May 12 2006 11:18 EDT
- in response to Michael Jouravlev
Well the backing bean is manipulating complete UI components (like you do in Swing) which is different from only performing some basic markups string concatentation. To me there is a big difference since the separation of concerns is more respected in JSF (the view definition code is separated from the view processing code).
Yikes! If there is a strong desire to make highly dynamic UI for the Web, it should be done via Javascript. *THAT* would be real separation of concerns. Removing "if"s from a page and putting "println"s to a bean does not really make a difference. XAML designers apparently feel the same, they allow both markup and code both in XML and in code-behind class, because XML + code-behind is actually one thing split in two just for convenience.To make a Javascript client tolerant to user's activities I suggest to devise a unified programmatic API for common browser features like navigation. It would allow a webapp to turn THE FREAKING RELOAD AND BACK BUTTONS OFF on any browser to ensure that a customized DOM tree is not accidently reloaded.
By the way, turn the back button off and you will loose a lot of users on your web site. People are used to use their back button and I include myself in the group. This is one of the main problem of Ajax unfortunately. -
Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]
- Posted by: Werner Punz
- Posted on: May 12 2006 13:27 EDT
- in response to Michael Jouravlev
Well the backing bean is manipulating complete UI components (like you do in Swing) which is different from only performing some basic markups string concatentation. To me there is a big difference since the separation of concerns is more respected in JSF (the view definition code is separated from the view processing code).
Yikes! If there is a strong desire to make highly dynamic UI for the Web, it should be done via Javascript. *THAT* would be real separation of concerns. Removing "if"s from a page and putting "println"s to a bean does not really make a difference. XAML designers apparently feel the same, they allow both markup and code both in XML and in code-behind class, because XML + code-behind is actually one thing split in two just for convenience.To make a Javascript client tolerant to user's activities I suggest to devise a unified programmatic API for common browser features like navigation. It would allow a webapp to turn THE FREAKING RELOAD AND BACK BUTTONS OFF on any browser to ensure that a customized DOM tree is not accidently reloaded.
Javascript is a bad tool for the job. Javascript is a hack which does not even work too well. The language is ok, except for one part, you have not isolation at all. Add to that browser bugs and deficiencies over all current rendering engines which are important add to that that huge singleton which everything outside can influence to a big degree and you have the biggest pile of mess around, which has not even existed in the good old Xerox UI. The combination of Javascript + DOM + Browserbugs is a combination of insanity, which seems to throw every good design practice over board which has been in research for the last 30 years.
Sorry to say that so harshly but that is my feeling. Add to that that it is close to impossible to program decent barrier free sites if you have a pile of javascript on your hands.
Well, for the isolation problem there are several ways to overcome that, but none of them is standardized and works over all browsers.
In the end, you also then have to componentize all this stuff to be able to handle that and you end up with something like JSF or Tapestry. -
Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 12 2006 13:44 EDT
- in response to Werner Punz
Javascript is a bad tool for the job. Javascript is a hack which does not even work too well. The language is ok, except for one part, you have not isolation at all. Add to that browser bugs and deficiencies over all current rendering engines which are important add to that that huge singleton which everything outside can influence to a big degree and you have the biggest pile of mess around, which has not even existed in the good old Xerox UI. The combination of Javascript + DOM + Browserbugs is a combination of insanity, which seems to throw every good design practice over board which has been in research for the last 30 years.Sorry to say that so harshly but that is my feeling. Add to that that it is close to impossible to program decent barrier free sites if you have a pile of javascript on your hands.Well, for the isolation problem there are several ways to overcome that, but none of them is standardized and works over all browsers.In the end, you also then have to componentize all this stuff to be able to handle that and you end up with something like JSF or Tapestry.Well the backing bean is manipulating complete UI components (like you do in Swing) which is different from only performing some basic markups string concatentation. To me there is a big difference since the separation of concerns is more respected in JSF (the view definition code is separated from the view processing code).
Yikes! If there is a strong desire to make highly dynamic UI for the Web, it should be done via Javascript. *THAT* would be real separation of concerns. Removing "if"s from a page and putting "println"s to a bean does not really make a difference. XAML designers apparently feel the same, they allow both markup and code both in XML and in code-behind class, because XML + code-behind is actually one thing split in two just for convenience.To make a Javascript client tolerant to user's activities I suggest to devise a unified programmatic API for common browser features like navigation. It would allow a webapp to turn THE FREAKING RELOAD AND BACK BUTTONS OFF on any browser to ensure that a customized DOM tree is not accidently reloaded.
Agree, we need a standarized way to manipulate the client on the server. If we do setBackground(red) the background should be red for that component without refreshing the whole page. Most ajax frameworks set just one components content per request, but what if we can send a list of components per request and let the browser update all components that have entries in that list. With not only content but also position, style and behaviour specs. When i get to think of it this is actually a great idea, i am going to do some prototyping in this regard. How hard is it to map dom methods to javamethods, it is probably a lot of typing work but not hard. The problem with cross browser is not in the javascript but in the css differences i think. With polymorphism different browsers can be handled smoothly i guess. Diiferent renderers can also mean to have a internet explorer renderer and a firefox renderer and a safari renderer etc. I am sure it can be done like this but we have to ditch markup to achieve this. Tell me why is eclipse not build in JSP(and never will be), why are IDEA and netbeans not build in XUL. Because those guys are not so crazy to do so, why are we then???? -
Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: May 12 2006 14:03 EDT
- in response to Dennis Bekkering
Most ajax frameworks set just one components content per request, but what if we can send a list of components per request and let the browser update all components that have entries in that list.
Some 'server side' frameworks actually do part of what you want. The framework I'm thinking of basically let's you specify which components should be (re)rendered and handle the rest for you.
Now we (of framework x) are starting to find out that some things are a bit harder than we expected, e.g. when you insert components via ajax that have what we call 'header contributions' (they have their javascript/ css dependencies, like a date picker component for instance) that weren't in the page before, it's tricky if possible at all to update those dependencies.
Otoh, it's a luxury problem, which is due to the fact that the components are completely self contained, while if you work with a pure javascript lib, you'd work on a page-level instead of a component level in that respect (javascript/ css dependencies) anyway.
But in short, what you mentioned is something more people are working on. -
Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 12 2006 15:46 EDT
- in response to Eelco Hillenius
when you insert components via ajax that have what we call 'header contributions' (they have their javascript/ css dependencies, like a date picker component for instance) that weren't in the page before, it's tricky if possible at all to update those dependencies.
I off framework Y know that problem and can tell the guys of framework X that there is a solution if some rules are followed.
document.onclick(){
if(event.srcElement.onclick ! starts with 'function' ){
eval( event.srcElement.onclick );
}
} -
Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: May 12 2006 16:56 EDT
- in response to Dennis Bekkering
when you insert components via ajax that have what we call 'header contributions' (they have their javascript/ css dependencies, like a date picker component for instance) that weren't in the page before, it's tricky if possible at all to update those dependencies.
I off framework Y know that problem and can tell the guys of framework X that there is a solution if some rules are followed. document.onclick(){ if(event.srcElement.onclick ! starts with 'function' ){ eval( event.srcElement.onclick ); }}
:) But what about CSS? -
Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: May 12 2006 16:58 EDT
- in response to Eelco Hillenius
:) But what about CSS?when you insert components via ajax that have what we call 'header contributions' (they have their javascript/ css dependencies, like a date picker component for instance) that weren't in the page before, it's tricky if possible at all to update those dependencies.
I off framework Y know that problem and can tell the guys of framework X that there is a solution if some rules are followed. document.onclick(){&nbsp;if(event.srcElement.onclick ! starts with 'function' ){&nbsp;&nbsp;&nbsp;eval( event.srcElement.onclick );&nbsp;}}
And 'if some rules are followed' is problematic from an integration point of view. Are you going to force e.g. the developers of YUI to follow those rules? -
Re: Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]
- Posted by: Dennis Bekkering
- Posted on: May 15 2006 10:25 EDT
- in response to Eelco Hillenius
tried to answer earlier but the site seemed down, i dont ever experienced problems with CSS, tell me about it please. Strange enough you are the first one refering those problems. I discussed this in the past with the backbase core developer (we work on the same floor, not the same company though) and he never had those problems with the event handlers??? I think it is actually good to have some rules so one knowes that script methods are always called in a certain way. The rules are not that big of a deal. The element that is clicked on should be passed as well as the event. Offcourse one might say but getting reference over the event differs between browsers, all and all it works out well for me, i dont have any problems with it anymore. Btw i am not that interested in integration anyway. I use the framework to build application my way and it works out great. I dont want to catch the world i only want to rule it;-))))
:) But what about CSS?when you insert components via ajax that have what we call 'header contributions' (they have their javascript/ css dependencies, like a date picker component for instance) that weren't in the page before, it's tricky if possible at all to update those dependencies.
I off framework Y know that problem and can tell the guys of framework X that there is a solution if some rules are followed. document.onclick(){ if(event.srcElement.onclick ! starts with 'function' ){ eval( event.srcElement.onclick ); }}
And 'if some rules are followed' is problematic from an integration point of view. Are you going to force e.g. the developers of YUI to follow those rules?