Programming with
a dose of satire.
Programming
|
| ||||||||
 |
 |
|||||||
|
Programming |
||
|
JavaServer Faces 1.0 Early Access Draft Commentary By Brian Pontarelli This article is divided into the following pages: 1. Introduction Although some will claim that the Java Server Faces (JSF) 1.0 Specification Early Access Draft (EAD) release is simply not suitable for web development, there are those, including the companies that voted yes on the specification, that believe that it has merit. I won't go into detail about what camp I'm in, but I will say that JSF is definitely a step in the right direction for HTML over HTTP based application development. There are some parts of the specification as it stands that need to be addressed. Some issues revolve around performance and others clarity. In this article I'll try to tackle as many as I have space for and those that I've found. I've referenced the section numbers from the EAD so that you can follow along at home, so to speak. I'm also assuming that you have prior knowledge of the specification - although not required, it will help when reading. I spend very little time describing the sections and assume that you have access to them to read, or have read them before and will pick up as we go along.
>> Page 2 (Data Model Duplication) Talkback: Message Index:
The Messages: Excellent ArticleGreat article. Good analysis. It appears from the authors comments that the JSF has used less than the required thought experiments and even less prototypes. Still its nice to see Sun finally publishing something. It would nice if Sun would respond to articles like these - in public. Rather than the current JSR policy of 'deals in smoke filled rooms'. Finally I agree with the authors point on HTML. It never was and never will be a good application development format. We really do need a better alternative. Robin Sharp robin.sharp@javelinsoft.com London, England Sun Oct 06 16:20:54 BST 2002 HTML was and is not meant for Applications HTML over HTTP was never really meant for applications. It was meant to exchange information and not really build large scale enterprise apps. It appears to me that we have flogged the stateless nature of http long enough and what we really need is a cross platform protocol running over TCP/IP which is designed for large scale enterprise apps. Ofcourse this is not really possible without all the vendors (including MS$, SUN and IBM) agreeing to the basic idea and working together to build a new protocol. Harikrishna hari_real@indiatimes.com New York, USA Wed Oct 09 16:43:10 BST 2002 XUL plus SVG plus XHTML is the future for rich desktop apps > HTML was and is not meant for Applications > HTML over HTTP was never really meant for > applications. XHTML is excellent for styled text but fails for rich user interfaces (e.g. trees, tables, etc). This is where XUL (XML User Interface Language) comes into the picture. Along with SVG for 2D graphics XUL and XHTML form a perfect trio for creating rich desktop apps in XML. > vendors (including MS$, SUN and IBM) agreeing > to the basic idea and working together to build > a new protocol. No need to create a new protocol. XUL, XHTML and SVG are the way to go. To get started with XUL check out Luxor XUL @ http://luxor-xul.sourceforge.net or browse O'Reilly's free Mozilla XUL book @ http://books.mozdev.org or visit the XUL planet @ http://www.xulplanet.com Gerald Bauer gerald@vamphq.com Feuersbrunn, Austria Thu Oct 10 17:39:31 BST 2002 Great comments Great comments. It's funny how most people that have read the article, including friends of mine, have really liked my comments about HTML over HTTP. Originally, this was just something that I wrote quickly after my forth reading of the JSF spec. and when I was thoroughly distressed by technology in general. One of those, "what the heck is wrong with this picture" kind of moments. I have not had a chance to look into XUL, but I definitely will. What I've seen as the weak point of other attempts at an application protocol/language is either the commercial drives behind it, or the blindsidedness of the writers (where they forget that there is more to technology than J2EE or even CORBA or even XML-RPC). Probably the largest reason for HTMLs success is the fact that it doesn't specify anything about the server. It says, here's the information you get, and that's about it. If XUL does this, in an application centric way, then it's possible that it could survive, if not, a few companies will use it, but companies with 20 years of spending on everything from Mainframes to J2EE will probably ignore it as to much effort to use and it will end up collecting dust in a CVS repository somewhere for the next twenty years. Brian Pontarelli brian@pontarelli.com Chicago, USA Sat Oct 12 22:58:34 BST 2002 M$ will wipe out HTML based Apps. to sell more Office, Web Services and PC's Dear All, I dont know Im right or wrong. But, what i feel is, Microsoft's .NET, C# and their profit making products, you will definately agree to my point. M$ now has C# to compete with Java atleast in windows now. It dont sell IE. So, they are promoting Webservices more than other technologies. Because, they will be selling MS Office components itself running from Network or Web as Web Services in near future. Most of the companies will do this. If u see C# applications can also be invoked from internet thru .NET remoting. If u see Sun also, promoting Java Web Start now, which can invoke applications from remote systems. They will give provision to invoke webservices also thru that. Also, pc's memory will go up within a year or two and bandwidth speed will also go up. So, within 2 years time, none of the Web Applications will be in any of these Markup Lanugaes like HTML, XUL, SVG etc. Yours, Sankar.B Sankar.B jinishans@yahoo.com Tamil Nadu, India Sun Oct 20 07:05:11 BST 2002 a good article, but has anyone told the working group? Good article. I think it could have used some diagrams (or pointed to some in the draft) to make clear the life cycle of a request in an application that uses JSF. Data duplication is a heck of a problem. It looks like something that needs to be solved architecturally. I haven't read the spec (not a member of the developer network), but I was wondering whether there were any reasons for converting into the UITree(?) model--does this level of indirection add anything but complexity? I liked the point about error messages. To me, the error paths through any application creates most of the headaches. Are there any projects out there to solve this important but non-sexy problem? As for HTML over HTTP, this is a dead horse (both HTML and HTTP). The fact is that HTTP was accepted in part because of its flaws. If you don't need to maintain state, it's much easier to write a server. And so, many http servers were written. Ignoring flaws of HTML, I don't see how you can fix the state problem (and the associated shenanigans that this requires) without a (widely distributed) replacement for HTTP. A final note--has anyone pointed this article out to the members of the JSF working group? I'd love to hear from them. Dan Moore mooreds@ynnmail.com USA Tue Oct 22 02:39:19 BST 2002 re: has anyone told the working group? Good idea. I've just emailed Craig McClanahan at Sun. It'll be interesting to see whether or not he (or one of the group) posts a response. Matt Stephens London, England Tue Oct 22 19:57:26 BST 2002 re: has anyone told the working group? I'm in the JSF working group, and I replied to most of the comments raised in this article when Brian posted it to the JSF Forum hosted by Sun at: <http://forum.java.sun.com/thread.jsp?forum=427&thread=302413> I recommend that you discuss JSF there instead, since I and other JSF spec group members read that forum on a regualar basis; tracking down discussions all over the net is something I only do when I get too bored to do what I should ;-) You should also send formal feedback to the mail address listed in the spec. That's the only way to guarantee that it's seen and considered by the spec group. Hans Bergsten hans@gefionsoftware.com Wed Oct 23 03:23:12 BST 2002 The group and beyond First of all, I'm not too sure that the HTML/HTTP is beating a dead horse. I really think that this issue needs to be address at great lengths and continuing to talk about it, not matter how small the forum, is definitely putting peoples minds in the right direction. Secondly, initially, when this was not an article, but more of a list of issues, I mailed it directly to the JSF group. I received no response, nothing. I'm as disillusioned by the JCP and most JSRs out there as everyone is. The black box, boys club that the JCP has become is frankly disheartening. I'll be sure to write another article and publish it everywhere if the JSF specification is not mended, but beyond that, without a large bank account and a NASDAQ stock ticker, there isn't much I or anyone can do. I might have over stepped my bounds, but each day I've become more frustrated and needed to vent a bit. I'm glad that my comments were addressed at the JSF forum, but I'm worried about the fact that so many answers were, "we need to look into that", or, "that needs to be addressed". Besides this, I've only read the spec a few times and I've probably missed some other points as well. What over issues exist that might produce the same response? Also, some of my main points seemed to get lost in the response. I still think there are major issues with the data duplication, regardless of the fact that it may only be pointers (references). I'd really like to see the benefits rather than justifications. Why should this duality occur if it serves no purpose? If there are hard facts for its benefit, post them to the forum so that the community can mull them over. That's about it for me. Again, thanks for reading the article, I'll keep abreast of the latest developments with the JSF and hopefully spread the word. Plus, if I ever get a response from the JSF team, I'll let everyone know. Brian Pontarelli brian@pontarelli.com Chicago, USA Thu Oct 24 17:11:51 BST 2002 a couple notes I think we'd all agree that pushing apps via (D)HTML over HTTP has its shortcomings, but you have to admit, it's easy for the drones to learn just enough to get them going, just powerful enough to do some interesting things, fast to develop, lightweight, distributed, etc etc etc. How many options for thin-client solutions do we really have at this point? One thing I can't quite seem to grasp about the MVC architecture though... I get the model, I get the view, I get the point of separating the business logic from the system with beans or other compiled backend code. But what's with the controller? Maybe I'm misunderstanding it, but in Servlet/JSP land, this seems to mean having one servlet through which all user events get routed. Isn't this equivilant to writing a thick client java app and delegating all your Swing events to a single class implementing a hundred listeners? Joe storm__j@yahoo.com doesn't matter, I'm not staying here anyway Fri Oct 25 17:08:22 BST 2002 Interesting Interesting comments. I think your conclusion says what is on my mind though i.e. [my interpretation and para-phrasing] why are we kludging html over http to try to create client-side applications? HTML was designed to return information as a document. Kludge after kludge has been added to it (JavaScript, DHTML, embedded objects - applets, activex) to try to make it what it was never intended to be. Applets were supposed to solve the problem but didn't (I'm not sure why they failed exactly, but they did, too bad). Flash has had much better success however. Perhaps we can look at Flash to fill this goal now instead. Flash MX seems to capable enough to fulfill this goal. Just a thought. Proceeding further down this road (through JSF) just seems like a pointlessly complicated excersize. Event handling frameworks using html over http have been tried for years. They never quite seem to be able to pull it off. Will JSF be any different? We'll see. Ian Canada Sun Nov 10 07:13:10 GMT 2002 Just a few follow ups Well, for anyone new to this thread of discussion, or those that are still checking back periodically, no word from the JSR group. I haven't been back to the forum over there lately since it has exploded into a Q/A session of epic proportions. You would think they had already shipped this thing and companies were long since on the band-wagon. Secondly, let me address just a few things quick. The controller, which was a question a month ago, is designed to allow the view to communicate with the business logic. It allows the application to send a request to a specific class based on parameters, which in the J2EE world are the HttpServletRequest parameters. Having a single servlet handle this just simplifies things. As for the Flash MX bit, I salute Macromedia for their efforts to provide a good transition away from the horrible mess that is the web. However, they will fail like all those before them. The reason is that MX is NOT a standard, can not be freely controlled by all companies and costs money. HTML is free, open, controlled and simple (although the last one in my opinion is that it is too simple). What the world needs is what I've been raving about for nearly two years now, a new protocol and a new language. I call me versions RAL over RAP. That's Remote Application Language over Remote Application Protocol. Since we can't leave this up to W3C, some one else needs to step up to the plate and take over. When they come along, please contact me and I'd be more than happy to work for you ;) Brian Pontarelli brian@pontarelli.com Chicago, USA Tue Dec 17 03:59:09 GMT 2002 JSF is necessary and proper There are plenty of frameworks that support HTTP based applications within the limitations of that protocol. Collaborating on a standard is really a nobrainer of the higest order. That the core team members from Struts were helping to drive this is a confidence builder and if you've ever created a homegrown framework for this you will realize the JSF is top-drawer. It is also continually being improved. That HTTP does not support applications in the traditional sense is true but not particularly useful information. I used the Internet over a POTS line for the better part of the 90's. That phone lines were not designed to handle digital transmissions did not preclude its use; it just limited what could be done. Rod Macpherson Sun Oct 10 02:57:35 BST 2004 I want some Help to solve this bug. I am new to java and directly i am working on JSF and Hibernate. Now i want to develop a window with tree view structure. I got solution from the "myfaces.apache.org" but when i am using that i am getting this problem. I am attaching my code here. <%@ page import="org.apache.myfaces.custom.tree.DefaultMutableTreeNode,org.apache.myfaces.custom.tree.model.DefaultTreeModel"%> <%@ page session="true" contentType="text/html;charset=utf-8"%> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> <%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%> <html> <body> <% System.out.println("Coming Hear"); if (pageContext.getAttribute("treeModel", PageContext.SESSION_SCOPE) == null) { DefaultMutableTreeNode root = new DefaultMutableTreeNode("Project"); DefaultMutableTreeNode erp = new DefaultMutableTreeNode("ERP"); root.insert(erp); DefaultMutableTreeNode dinoster= new DefaultMutableTreeNode("Dinoster"); root.insert(dinoster); DefaultMutableTreeNode hbp = new DefaultMutableTreeNode("COSMOS++"); root.insert(hbp); DefaultMutableTreeNode guiness = new DefaultMutableTreeNode("GuINESS"); root.insert(guiness); DefaultMutableTreeNode invient= new DefaultMutableTreeNode("Invient"); root.insert(invient); DefaultMutableTreeNode node = new DefaultMutableTreeNode("Gopal"); erp.insert(node); erp = node; node = new DefaultMutableTreeNode("Mukesh"); erp.insert(node); node = new DefaultMutableTreeNode("Shobha"); guiness.insert(node); guiness = node; node = new DefaultMutableTreeNode("Santosh"); guiness.insert(node); node = new DefaultMutableTreeNode("Prasad"); guiness.insert(node); node = new DefaultMutableTreeNode("Giri"); hbp.insert(node); hbp = node; node = new DefaultMutableTreeNode("Sreenath"); hbp.insert(node); node = new DefaultMutableTreeNode("Anupama"); dinoster.insert(node); dinoster = node; node = new DefaultMutableTreeNode("Sunil"); dinoster.insert(node); node = new DefaultMutableTreeNode("Hitesh"); dinoster.insert(node); node = new DefaultMutableTreeNode("Sindhu"); invient.insert(node); invient = node; node = new DefaultMutableTreeNode("Purnachand"); invient.insert(node); pageContext.setAttribute("treeModel", new DefaultTreeModel(root), PageContext.SESSION_SCOPE); } /* else { System.out.println("Present + "); return ; }*/ %> <f:view> <t:tree id="sampleTree" value="#{treeModel}" styleClass="tree" nodeClass="treenode" selectedNodeClass="treenodeSelected" expandRoot="true" iconNodeOpen="./images/minus.gif" iconNodeClose="./images/folder.gif" iconLine ="./images/line.gif" iconNoline ="./images/noline.gif" iconChildFirst ="./images/line_first.gif" iconChildMiddle ="./images/line_middle.gif" iconChildLast ="./images/line_last.gif" iconNodeOpenFirst ="./images/node_open_first.gif" iconNodeOpenMiddle ="./images/node_open_middle.gif" iconNodeOpenLast ="./images/node_open_last.gif" iconNodeCloseFirst ="./images/node_close_first.gif" iconNodeCloseMiddle ="./images/node_close_middle.gif" iconNodeCloseLast ="./images/node_close_last.gif" > </t:tree> </f:view> </body> </html> Here with this code i was unable to display the folder image. IF anybody know this please let me know how to solve this problem. Or Is there any option to remove this another image. keeping only one image. Prasad prasadb@global.com Bangalore, India Mon Nov 28 14:17:45 GMT 2005 resultset resultset pdhall pdhal@okayainfo.com delhi, india Thu Nov 02 10:59:08 GMT 2006 Doubt in command button method I have a command button which has an action method and an onclick method.The action method does a calls a backing bean.The onclick method does a window.close(). Data from the popup needs to be transferred in the action method and in the on click method the popup should close.This works fine in IE and not with Firefox. Any help appreciated Regards Daya Daya dayap@aztecsoft.com Karnataka, India Mon Apr 02 05:51:22 BST 2007 How to have have a onclick event as well as an action method on a commandButton I have a commandButton where I call a method from a bean. The bean actually gives output and generates a PDF. It opens the PDF in another window(that is what I want). But I want to resize the window to a smaller size. But I am not sure how should I do that using javascript onclick event on the command button.I can not use the window.open because I do not have any URL of the output that is coming from server side. Any ideas would be greatly appreciated. Thanks Tej teja gtejasree@yahoo.com V, US Wed May 02 23:08:47 BST 2007 Reset button problem I am new to JSF. Infact i am not a programmer. But, recently i started using this application using Exadel IDE. I am facing a problem with reset button. I have used converters and validators in my application. I have two inputfields where user needs to enter the values in numbers only. If not it gives error message. After giving this error message, if i click on reset button it's not removing the values from the page. I just used managed beans to create this application. Before validation if i click reset it is resetting the form to empty values. I have seen the solution provided here and understand that i have to use Actionlistener to implement reset buttom to make it work properly. But i am not able to understand how to create it. Can you please give me the sample code part to implement actionlistener? In java file, in facesconfig.xml and in my jsf page what code i need to use? krishnakanth krishik_123pm@yahoo.com Hyderabad, India Mon Aug 06 11:42:42 BST 2007 How we can close winow after clicking on command button How we can close winow after clicking on command button in java server faces? Any suggestions will be appreciated. chintan Anand chintananand14@gmail.com Tue Sep 18 11:29:19 BST 2007
Related Articles: User Interface Design should be a Team Effort
|
||
Introduction
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.