Changing JSF Pages Programmatically

Discussions

News: Changing JSF Pages Programmatically

Bookmark and Share Get thread feed

  1. Changing JSF Pages Programmatically (59 messages)

    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.
    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?
    Reply to this

    Threaded Messages (59)

  2. Changing JSF Pages Programmatically[ Go to top ]

    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
    Reply to this Reply to original

  3. Changing JSF Pages Programmatically[ Go to top ]

    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).
    Reply to this Reply to original

  4. Learn JSF 1.2[ Go to top ]

    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
    Reply to this Reply to original

  5. JSF is a steaming pile[ Go to top ]

    <%@ 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>
    Reply to this Reply to original

  6. JSF is a steaming pile[ Go to top ]

    <%@ 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); &nbsp;%><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...
    Reply to this Reply to original

  7. JSF is a steaming pile[ Go to top ]

    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).
    Reply to this Reply to original

  8. JSF is a steaming pile[ Go to top ]

    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?
    Reply to this Reply to original

  9. JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  10. JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  11. JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  12. JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  13. JSF is a steaming pile[ Go to top ]

    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.

    +1
    it'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.
    Reply to this Reply to original

  14. JSF is a steaming pile[ Go to top ]

    I wish it was more like Swing actually.
    this one too
    Reply to this Reply to original

  15. JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  16. JSF is a steaming pile[ Go to top ]

      
    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.
    Reply to this Reply to original

  17. JSF is a steaming pile[ Go to top ]

    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 ;)
    Reply to this Reply to original

  18. JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  19. JSF is a steaming pile[ Go to top ]

    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
    Reply to this Reply to original

  20. JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  21. JSF is a steaming pile[ Go to top ]

    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.

    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.
    Reply to this Reply to original

  22. JSF is a steaming pile[ Go to top ]

    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.
    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.

    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.
    Reply to this Reply to original

  23. JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  24. JSF is a steaming pile[ Go to top ]

    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
    Reply to this Reply to original

  25. Re: JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  26. Re: JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  27. Re: JSF is a steaming pile[ Go to top ]

    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.
    dont bother steve, some will never get it.
    Reply to this Reply to original

  28. Re: JSF is a steaming pile[ Go to top ]

    Others will be indulged in the ivy tower and refuse to recognize the reality.
    Reply to this Reply to original

  29. Re: JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  30. Re: JSF is a steaming pile[ Go to top ]

    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
    Reply to this Reply to original

  31. Re: JSF is a steaming pile[ Go to top ]

    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.
    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!).
    Reply to this Reply to original

  32. Re: JSF is a steaming pile[ Go to top ]

    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!).
    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.
    Reply to this Reply to original

  33. Re: JSF is a steaming pile[ Go to top ]

    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.
    It is proof of the Baaaaaa factor.
    Reply to this Reply to original

  34. JSF is a steaming pile[ Go to top ]

    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.
    Reply to this Reply to original

  35. JSF is a steaming pile[ Go to top ]

    Thank you for posting an unmaintainable codemess without any separation of concerns ;-)
    Reply to this Reply to original

  36. Changing JSF Pages Programmatically[ Go to top ]

    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
    Reply to this Reply to original

  37. Changing JSF Pages Programmatically[ Go to top ]

    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).
    Reply to this Reply to original

  38. Changing JSF Pages Programmatically[ Go to top ]

    So all the HTML design goes back to Java code ...

    Dmitry
    Reply to this Reply to original

  39. Changing JSF Pages Programmatically[ Go to top ]

    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/
    Reply to this Reply to original

  40. Changing JSF Pages Programmatically[ Go to top ]

    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>
    Reply to this Reply to original

  41. Changing JSF Pages Programmatically[ Go to top ]

    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/
    Reply to this Reply to original

  42. Changing JSF Pages Programmatically[ Go to top ]

    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.
    Reply to this Reply to original

  43. Changing JSF Pages Programmatically[ Go to top ]

    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/
    Reply to this Reply to original

  44. Changing JSF Pages Programmatically[ Go to top ]

    With introducing JSF 1.2 and JSP 2.1 soon, this will be a JavaEE standard.

    What will be a JavaEE standard?
    Reply to this Reply to original

  45. Changing JSF Pages Programmatically[ Go to top ]

    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
    Reply to this Reply to original

  46. Changing JSF Pages Programmatically[ Go to top ]

    poor javaee, how can she bear the weight of such a machine while carrying the legacy of j2ee?
    Reply to this Reply to original

  47. Changing JSF Pages Programmatically[ Go to top ]

    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/
    Reply to this Reply to original

  48. Changing JSF Pages Programmatically[ Go to top ]

    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())) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answer = (HtmlInputText)application.createComponent(HtmlInputText.COMPONENT_TYPE);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LengthValidator lengthValidator = &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(LengthValidator)application.createValidator(LengthValidator.VALIDATOR_ID);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lengthValidator.setMinimum(2); // an answer must have at least two characters&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lengthValidator.setMaximum(200); // an answer must be no longer than 200 characters&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;((HtmlInputText)answer).addValidator(lengthValidator);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// bind the value property to the answer property in the pollPickerBacker bean&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answerBinding = application.createValueBinding("#{pollPickerBacker.answer}"); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} else {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ("s".equalsIgnoreCase(getAnswerStyle())) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ("tick".equalsIgnoreCase(getWidgetStyle())) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answer = (HtmlSelectOneRadio)application.createComponent(HtmlSelectOneRadio.COMPONENT_TYPE);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ("list".equalsIgnoreCase(getWidgetStyle())) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answer = (HtmlSelectOneListbox)application.createComponent(HtmlSelectOneListbox.COMPONENT_TYPE);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ("menu".equalsIgnoreCase(getWidgetStyle())) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answer = (HtmlSelectOneMenu)application.createComponent(HtmlSelectOneMenu.COMPONENT_TYPE);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answerBinding = application.createValueBinding("#{pollPickerBacker.answer}"); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} else if ("m".equalsIgnoreCase(getAnswerStyle())) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ("tick".equalsIgnoreCase(getWidgetStyle())) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answer = (HtmlSelectManyCheckbox)application.createComponent(HtmlSelectManyCheckbox.COMPONENT_TYPE);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ("list".equalsIgnoreCase(getWidgetStyle())) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answer = (HtmlSelectManyListbox)application.createComponent(HtmlSelectManyListbox.COMPONENT_TYPE);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ("menu".equalsIgnoreCase(getWidgetStyle())) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answer = (HtmlSelectManyMenu)application.createComponent(HtmlSelectManyMenu.COMPONENT_TYPE);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answerBinding = application.createValueBinding("#{pollPickerBacker.answers}"); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;answer.getChildren().add(getAnswerOptionItems());&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}</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
    Reply to this Reply to original

  49. Changing JSF Pages Programmatically[ Go to top ]

    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
    Reply to this Reply to original

  50. Changing JSF Pages Programmatically[ Go to top ]

    So all the HTML design goes back to Java code ...Dmitry
    i hope so
    Reply to this Reply to original

  51. Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]

    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.
    Reply to this Reply to original

  52. Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]

    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.
    Reply to this Reply to original

  53. Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]

    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.
    Reply to this Reply to original

  54. Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]

    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.
    Reply to this Reply to original

  55. Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]

    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.

    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????
    Reply to this Reply to original

  56. Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]

    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.
    Reply to this Reply to original

  57. Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]

    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 );
     }
    }
    Reply to this Reply to original

  58. Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]

    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;}}

    :) But what about CSS?
    Reply to this Reply to original

  59. Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]

    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(){&amp;nbsp;if(event.srcElement.onclick ! starts with 'function' ){&amp;nbsp;&amp;nbsp;&amp;nbsp;eval( event.srcElement.onclick );&amp;nbsp;}}
    :) But what about CSS?

    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?
    Reply to this Reply to original

  60. Re: Changing JSF Pages Programmatically OR Back To Servlets[ Go to top ]

    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;}}
    :) But what about CSS?

    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?
    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;-))))
    Reply to this Reply to original