Tech Talk with Amy Fowler, Former JSF Spec Lead Posted


News: Tech Talk with Amy Fowler, Former JSF Spec Lead Posted

  1. A new interview with Amy Fowler, Spec Lead for JavaServer Faces, has been posted on TheServerSide. In this interview, Amy talks about the problems JSF solves and how J2EE developers can leverage it in their Web apps. She looks at event handling code in JSF, and describes a typical JSF use case. She also discusses interoperability with JSF using Struts, Webwork, and the Portlet API.

    Watch Amy Fowler's Video Here

    Threaded Messages (62)

  2. I've been extremely interested in JavaServer Faces. Amy intimated that JavaServer Faces was supposed to make it easy for non-OO developers to build web applications, but I'm most excited about the fact that JSF is supposed to make it possible to develop reusable Web UI components in an OO manner.

    I know that Amy addressed how JSF is related to web frameworks like Struts and Webworks, but how does it compare to other web frameworks which are also component-oriented - like Tapestry, for example?

    God bless,
    -Toby Reyelts
  3. I've been interested in JSF for a while, too. I was under the impression that it would allow for richer UI's, but mostly it just makes it easier to reuse web components. I do like the ability to self-detect Javascript and turn turn client-side validation on or off for the user.

    I'm wondering about the performance of something like this, though. How bloated will things become? It may be nice and fast, but who knows.

    Also, her mentioning of letting non-OO developers into the Java World is interesting. This will be a big threat to .NET and Visual Basic if the tool vendors can actually pull this off.

  4. I think this talk was even more abstract than JSF itself :(
  5. Is JSF going to become part of the J2EE spec? Obviously it will not be available for 1.4, but perhaps 1.5?

    While Amy noted that JSF and Struts can be integrated, my impression at this point is that the two technologies overlap in enough areas that most deployments will either use one or the other, once JSF is available.
  6. Time Warp[ Go to top ]

    This is a bit out of date. Craig McClanahan (the creator of Struts) is now the specification lead, so Struts will likely integrate well with JSF.

    For those of you asking "where's the beef?" - the public review draft of JSF 1.0 and the latest reference implementation (early access) is available here:

    JavaServer Faces Goodies

    An interesting read...
  7. Time Warp[ Go to top ]

    Thanks for the info, Bill. I was looking for this on the JCP page, but it didn't connect to this. <shrug>

  8. from EA[ Go to top ]

    <faces:textentry_input id="userNo"

    may be
    <v:longRange min="0" max="10" />

  9. Time Warp[ Go to top ]


    can you tell us what we have to expect from the change of the spec lead (assuming you know some more)? Will the current release change much? Where would the integration points with struts lie?

  10. **** This architecture is almost exactly the same as .NET ****

    I am a java programmer, but my company sent me to a 3 day .NET training. Their "ASP .NET" architecture also makes a component representation of web form elements and links, and you can attach events to each element individually or instead as one unit together. Dot NET also attaches command objects to these components. The Dot NET MVC architecture is also based on a "post-back" concept so much, that a code line you will always use is "isPostBack()". The data source abstraction layer and its component architecture are the same as .NET, and the validation model and architecture are the same. There is more, but you understand where I am going. These two architecture are suspiciously similar in architecture and behavior. Is there a connection? Its a hell of a coincidence. If you are someone who knows both technologies, please comment on this. ~CoNsPiRaCy~
  11. To Conspirator,

    ASP was first, than JSP, ASP.NET, JSF...
    GM must argue with ToyoTa why they
    use round wheel also...

  12. Yes, but they call it innovation. We call it standards.
  13. What you call it doesn't really matter. What matters, is that this technology really helps developers by reducing complexity in Web UI development. Far too many hours have been spent, at least in projects I know of, trying to make pages look and behave equal in different versions of Netscape, Opera and IE. This has definitely been a problem that now browser aware controls hopefully will help eliminate. Not to mention that JSF also supports rendering for other devices as well.

    The "automatic" client side validation, ie. auto generated java scripts in the rendering process, is also a feature that will reduce development time. If Java Script is turned off, the server will handle the validation. This clearly reduces the amount of code that has to be written, and / or produces better a better user experience for end users.

    A lot of the functionality proposed through JSR is perfect for exposure through IDEs that will make it even easier for developers to use these new mechanisms - and will probably expose it more or less like Visual Studio.NET does today.

    I claim that the time spent on developing the parts of the application code that JSF tries to cover, will be significantly reduced, when comparing to the time spent on this today using existing technologies like Struts. UI development often counts only for a minor part in the total time spent on a development project, but all reduction is good.

    You have to innovate &#8211; and more important implement, to prove that it works - before you can standardize. The fact that the Java Community chooses the exact same approach to reduce complexity in Web UI development as the Redmond guys, shows that they found a good solution to this.

    Vidar Moe
  14. ---
    What matters, is that this technology really helps developers by reducing complexity in Web UI development. Far too many hours have been spent, at least in projects I know of, trying to make pages look and behave equal in different versions of Netscape, Opera and IE.

    long live the browser wars!

    i don't know but my educated guess is that while the so-called browser wars lasted, 80% of development time went down the drain due to buggy, non-compliant vendor-specific "extensions" to HTML, JS and the like.

    funny thing is that right now as we're getting frameworks and API's to circumvent this, browsers start finally behaving more or less correctly to standards. i can do a page today that renders the same on IE6, Moz/NS7 and Opera. so ... what do i need JSF for then? :)
  15. I wonder if JSF will be supported by GUI builders such as JBuilder... I think integration with an IDE is where JSF will be most useful because as she said the whole idea of JSF is to simplify building web clients.
  16. Hi Jonathan

    I have worked with both JSP and ASP.Net but haven't used any Web Framework like Struct and JATO. I have spent about 2 to 3 weeks time to lean ASP.Net and when I learn it, I think it is great and easy to use. However, when I want to really use it to develop something, I think JSP is much better and easier to work with.

    For example:

    - In ASP.NET, you cannot use the same method to get the params from the Post and Get request.

    - In the <asp:repeator> tag, you cannot dynamically create asp web controls in the loop but you can dynamically create HTML button or controls in the loop but you will be kind of struggling whether to use pure ASP.NET web controls or mix of them.

    - Most examples in the ASP.NET book only show the best sample cases that can use the minimum amount of code to solve the simple and stupid things but you have some really applications you will normally need to write **lots** more code and it is surprisingly difficult to find the solutions.

    But remember that I have only learnt ASP.NET for a month, so it is very possible that I am wrong but nevertheless this is what I feel when I work with ASP.NET and sadly I will need to continue to work with .NET.


  17. <quote>In ASP.NET, you cannot use the same method to get the params from the Post and Get request.
    You can, use HttpRequest.Params collection which combines, get , post, cookies and server variables into one collection. If you just want separate get or post , use QueryString or Form collection

    In the <asp:repeator> tag, .....
    Not sure this article will help: , if not try to post a question to or for help.

    Most examples in the ASP.NET book only show the best sample cases that can use the minimum amount of code to solve the simple and stupid things
    That's why it is called sample not application :-)
    Some sample application maybe be useful, try the IBuySpyStore or IBuySpyPortal samples at, you maybe able to learn something from here.

    Hun Boon Teo
  18. Hi,

    When was in Beta and Rc1 I took a project I wrote in JSP/Beans and recreated it with I found these advantages in

    1. Nice pre-built rich UI components - calendar - datagrid etc...
    2. Easy to use validation mechanism.
    3. Super IDE in Visual Studio.
    4. A clear coding standard (postBack) is defined.

    But I also found that it really did not save any time, ok maybe 5% faster. I used a simple MVC pattern in my JSP and some basic helper beans (validation and so on)and that ultra thin framework makes created web-apps easy.

    I think that complex frameworks only complicate things without providing advantage. People seem to always talk about the browser like it is some complex thing to work with and to be avoided at all cost. This is the case if you try to make look and act like a thick client app. But on the other hand if you understand the simplicity of it and just create web apps, then you will find that it works very well for many types of applications.

    I am not sure what pisses people off about JSP except for the fact it gives you direct control of the browser. I think with Tag Lib and hopefully JSF and standard rich UI components we will be in great shape without having to resort to totally abstracted frameworks like WO's or Tapestry. BTW both Tapestry and WO's have great ideas; but why spin on your head to KO someone when all you have to do is punch him in the head :)

  19. For all the guys on linux :

    mplayer mms://
  20. I'm very happy with Tapestry[ Go to top ]

    What I've read, Tapestry matches well against JSF.

    Tapestry has really easy-to-use built-in basic controls, it's good for debugging, does lot of mudane work for you, enables re-use in whole different level (compared to taglibs), easy & flexible validation, and so forth.

    In a nutshell: Stuff that good OO desing is supposed to deliver, agile software.

    I encourage everyone interested in web components or anyone with a feeling "There's got to be better way to do things.." to take a look at Tapestry. It's really worth it.

    Not to mention that Tapestry is here today. Stable, ready to use and developing constantly to be even better. And there's cool Eclipse plugin too, Spindle.

  21. please have a look at the architecture of wingS. it features:

    o real mvc (models and events of javax.swing)
    o pluggable look and feel (renderers for different browsers)
    o easy porting of swing applications
    o highlevel components (tree, tabbed pane, menu)
    o fast as hell
    o ...

    How can JSF ever get better than this?

  22. I know why I consider it better:

    It's standard, I can know what to expect from a container if it's compliant with JSF. I can go somewhere else and work, knowing they'll probably be using Faces, or moving in that direction.

  23. Is it inappropriate to say that Ms. Fowler is a spectacular women? Is anyone else overwhelmed by such a beautiful woman talking technical like this? I envy who ever gets to mix chromosones with her.

    It sounds like JSF competes with Flash MX. Has Sun put out a PetStore example in JSF yet?

  24. Down boy... :^)
  25. Is it inappropriate to say that Ms. Fowler is a

    > spectacular women?

    Mmmmmhhhh, yes! Floyd, thanks! ;-)

    -- Andreas
  26. Is it inappropriate to say that Ms. Fowler is a

    > spectacular woman?

    Obviously Java Server 'Faces' is beautiful in more ways than one. Lol . . .
  27. She is Hot as Hell!!!!!!!!

  28. > Is it inappropriate to say that Ms. Fowler is a spectacular women?

    No, it's not.

    > Mmmmmhhhh, yes! Floyd, thanks! ;-)


    > She is Hot as Hell!!!!!!!!

    Guys, keep these unprofessional comments to yourselves. They don't add anything to the discussion of JSFs except to demonstrate that you're neanderthals.

  29. Can anybody point me to demos of trees, tables, menus etc ?

    I couldn't seem to find them ;-)
  30. ...except to demonstrate that you're neanderthals.

    I'm no anthropologist or evolutionist but ...
    It probably proves they aren't neanderthals. They formed sentences and didn't club her over the head and drag her off. (I only get my evolutionary knowledge from TV. :) )

  31. Neandethals, cromagnums, austrolopithicus, peat bog man, ice man, whatever...Prepubescent java man at least...
  32. Where's the beef?![ Go to top ]

    Where are the menus, trees, tables?

    It's all reinventing the wheel at the same time making everything else incompatible.

    I just can't understand that it took this long to come out with a spec. that is this content free!
  33. Prepubescent java man at least...

  34. *drool*

  35. <quote>
     Is it inappropriate to say that Ms. Fowler is a spectacular women? Is anyone else overwhelmed by such a beautiful woman talking technical like this? I envy who ever gets to mix chromosones with her.

    Ha! She could be Java's answer to Apple's Ellen Feiss
  36. Finally! Sun is opening up about what JSF is.
    My initial impression is: It is no threat to Tapestry, or even Struts. Sun can never admit that it's made a mistake, and keeps layering kludges and hacks on earlier kludges and hacks in an attempt to set things right.

    Obviously, I'm not fan of "cruft" in HTML templates. By "cruft", I mean anything that isn't HTML. Tapestry is partly a reaction to JSPs, which are HTML + cruft. JSF takes cruft to a higher level with vast amounts of non-HTML in the JSP. At least there's no Java in their JSPs.

    Tapestry splits a component into three parts: Pure HTML template, pure XML specification and optional Java class.

    So far, the thing that seems most half-baked is the JSF ApplicationHandler. It appears that *all* behaviors on *every* page filters through this one object.

    Developers must assign command names to each of their forms or links so that, at this single choke-point, developers can perform the correct operation and select the correct tree to render a response (tree seems to be the abstraction over a JSP, somewhat like a Struts forward, but implying that the JSP contains JSF components).

    I'm assuming that someone is going to provide the equivalent of Strut's ActionServlet, that does data-driven dispatch for you ... but that isn't in the examples and RI provided so far.

    So, what we have is the equivalent of the Bitter Java Pattern "Magic Servlet", where all the business logic (and some share of the presentation logic) is located in one place.

    I don't see how this is going to sput the creation of components, at least, at least, not of the flavor I develop regularily in Tapestry. How can a component have its own behavior when all behavior is specified in a single place, custom for the application?

    Any application to be built by a team would have to create some kind of smarter ApplicationHandler right of the bat that would do sub-dispatch, otherwise you would have all developers conflicting over a single Java file at all times. Again, this may be coming, but its not in the RI.

    In JSF, the command names are assigned by the developer(s) and must be coordinated between the JSPs and the ApplicationHandler. It's the same old problems from JSPs ... the command names represent your dispatch model and will not scale properly as the application increases in complexity.

    In Tapestry, the framework already encompasses the dispatch model entirely; forms, links and other components have "listener methods" that can be placed at the developer's discretion (typically, inside the containing page or component's Java class). So, in Tapestry, your component is wired to invoke a particular method when triggered. The necessary information is encoded into the URL (Tapestry builds all the URLs used by the application). This information identifies the page and component within the page as well. Thus the Tapestry framework can invoke the triggered component directly, which can then notify the application via a listener method. Short and sweet ... listener methods are rarely more than a few lines long.

    The Tapestry model scales very well in complexity ... you can have hundreds of pages, and components ten levels deep (that is components contructed from other components contructed from other components ...) and the framework will continue to work the same as in the simplest demos.

    Back to JSF ...

    It seems to be mostly about handling forms (a previous poster noted a .Net webforms pedigree). However, there are a lot of oddities. It isn't clear how you would put a <faces:textentry_input> inside a loop ... probably you (the developer) are responsible for generating a unique id?

    A lot of the "sweating pixels" kind of operations (that is, precise control over the HTML, and thus, the layout) that are accomplished using informal parameters in Tapestry will require new RenderKits in JSF. I'm guessing from the spares docs that RenderKits are to JSF what L&F is to Swing.

    Again, Tapestry never locks you out from the exact HTML, allowing your to specify additional HTML attributes (in code, in the specification or in the HTML template) as you require (mostly, you just set the HTML "class" attribute).


    Validation is roughly on par with Tapestry, though it isn't obvious how a JSF Validator can do some of the cool Tapestry things (in Tapestry, the IValidationDelegate can modify the HTML for FieldLabels and ValidFields to visually identify input fields in error).

    An important sub-framework within Tapestry is client-side JavaScript generation. Tapestry includes the ability to generate JavaScript from a template file, so that it is adapted to the use by a specific component. Often, this means plugging in the name of a form and form element. Tapestry organizes all the JavaScript generated by all components anywhere on the page (again, nested however deep) and places it all in a single <script> block just before the <body> tag.

    I didn't see any facility for accomplishing the equivalent in JSF. I suppose components could just emit little script blocks inline with the HTML, though it gets hard to hook things like the <body> onload event handler going that way.

    This is strange, because I've long heard rumblings that JSF would have a client-side scripting focus.

    As much as JSF claims to be about components, it is still all about JSP tags. JSF components generate HTML, and pull and push properties into a "model" object of some kind, but don't appear to have any additional behaviors beyond validation. It's a very heavy approach because the behaviors are specified in that central ApplicationHandler object.

    Tapestry has always had a concept of component that had individual resources, such as JavaScript but also including private assets such as images and stylesheets. That is, a Tapestry component can be bundled with images and distributed as a JAR and Tapestry would take care of exposing those "private assets" at runtime to the client web browser (it would either pump the bytes down on demand, or copy the asset to a directory mapped to URL ... but the component doesn't have to be aware).

    Starting in 2.2 (about to go beta), Tapestry extends this, with the concept of a component library, that includes components, pages specific to the library and even services (in Tapestry, services build and interpret URLs for components and so provide all the basic request dispatching functions).

    In other words, Tapestry is paying more than lip-service to creating components.

    Now, I'm sure folks with an inside track to JSF can provide more information, and correct my bad assumptions and guesses ... but based on what I've seen so far, JSF is just demo-ware that doesn't even demo well.

    Tapestry (which demos pretty darn well, by the way) is for creating serious applications that execute on the web ... but doing it in a way that promotes true reuse (within and between applications), eases interactions between team members and otherwise supports the developer at every stage.

    I had been worried for a bit that JSF would not be good, but be good enough (to steal Tapestry's thunder). I'm no longer worred. JSF is just another also-ran.
  37. The company that I work for, did a research project with the National Research Council of Canada, and we spent several months reviewing web services, J2EE, and Database systems for a technical risk project that we were doing. Out of that we learned 3 things:

    1. Web services were immature.
    2. J2EE was overrated.
    3. That JSP and anything else that stuck anything other than HTML into an HTML file was not only counter-productive but dangerous to the life of the project.

        I will give you an example. We have a "legacy" project (sort of reminds of coding COBOL vs Visual BASIC) that is done in JSP (all of our development efforts have moved to Tapestry). We had to perfect the logic of the project while the text and look of the project was still in flux. Everytime our graphics guys fixed the pages, code would get damaged, or vice versa. Everytime our graphics guys created new pages, our programmers would have to go mark up the pages with code and could not work on the logic of the given page until after our graphics guy had finished it. On top of that the whole system has to be translated into French. Which means that we not only have doubled our work, we have actually ended up tripling it, pushing back deadlines, etc. If it had been for the fact that we "inherited" the code, it would have been done in Tapestry to start with, because:

    1. Our graphics designers could do their thing without disturbing the work of our programmers.
    2. The programmer wouldn't have to wait for the designers to finish a page to start work on it. Many times our programmers work with pages that are simple white with text and form fields and after it works, our designers integrate the pages together.
    3. Converting to french means simple copying the existing layout, add french text, and place it in with the english text (with a change to the file extension) and we are done, no need to recreate the code of a JSP.
    4. If our client doesn't like the look, it is a simple matter of changing it, no code is disturbed, no code is broken, it will work when it is done being modified without our programmers even looking at it. (And our designers don't even know Java....)

    If you are using a language / MVC framework that puts proprietary / non-HTML code into your templates / HTML files, I seriously suggest that you take a look at the approach that Tapestry takes as you will probably find that it is quite revolutionary in its approach to web development (as stated above...)

    So take it from someone who spent just looking at existing and upcoming technology for 3 months (pure research, not much coding, TONS of paper and many late nights scouring the web looking for answers), Tapestry frags the snot out of frameworks like JSF, Struts, and the likes.

        I will give Apache one thing though, they have built a lot of production quality software that beats even Microsoft. We added Torque to Tapestry to fill a void in the database support (Tapestry by itself has no database support) because Tapestry's model fit so perfectly that I can actually create a web page to display all the records in a table using only 14 lines of Java code, of which less than half (only 6 lines of code) are actually hand written (the rest are auto-generated by Eclipse). So I guess that is another point for Tapestry: Integration of other packages / APIs that support a Java Beans style is a no-brainer. No taglibs need to be written, no new scripting needs to be created, it simply works.
  38. IMO, should you have started with Struts, you would not have had the problems you are describing. A good book on Struts was posted on TSS a while ago.

    -- Igor
  39. Tapestry 2.2 Beta Release[ Go to top ]

    I get worked up with these discussions and then (somewhat unfairly) get criticised for monopolizing other threads. A Tapestry 2.2 beta release announcement is pending on SourceForge and there I'll be free to answer any and all questions about Tapestry.
  40. I mean, pending on TheServerSide. Woops.
  41. That's interesting. So you are blaming J2EE technology and other frameworks for gross misuse of the technology in the first place and then your company's poor management of the project afterwards? Many of the problems you describe have very simple, accepted solutions regardles of the framework (even without one).

    I have no doubt that Tapestry is a great framework, but you are doing it a great disservice here.
  42. I don't think you are being fair to Mr. Green. Looks like he's talking about a research project where the goal was to evaluate these technologies on behalf of a client.

    Beyond that, if you notice, his key issue wasn't the immaturity of web services, or the problems of J2EE ... it was dealing with HTML.

    Tapestry was borne out of my expiriences working as a Java/J2EE consultant. Customers are finicky. They change their minds. On the last day of a contract (really! I'm remember Citibank suddenly realizing that the DHTML menu bars had to match the style of their public website Friday morning on the last day of a contract, despite signing off on it months earlier).

    The Sun guidelines are full of "roles" that don't exist in the real world. Although Primix had its own graphic designers and HTML producers (the former were the PhotoShop jockies, the latter turned that into HTML) that is often not the case; in some cases, clients insisted on using their existing GDs who would e-mail PhotoShop files or HTML as the development team every friday (leading to the dreaded "friday night integration crunch").

    Anyway, Sun's roles have the HTML producer, who "just knows HTML and the JSP tags provided by the Java developer" to create the HTML. Really. "Just need to know the tags" ... really, not application flow, not the data (i.e., where dynamic data comes from), not the names of JSP actions, just, magically, "the tags".

    Back in the real world, HTML guys don't know JSP and only recently have some tools caught up to the JSP syntax.

    Tapestry provides. Tapestry just adds some new <span> tags and the "jwcid" (Java Web Component Id) attribute to existing tags. Since everything else is nice and safe in a XML component specification (that the HTML developer never, ever has to see), integration is easy ... even if it occurs repeatedly.


    The HTML guy starts with some HTML including a sample value (so they can verify their layout in WYSIWYG mode) ... and maybe a comment or two for the Java developer.

    <!-- Column total, use class "negative" if negative. -->

    The Java guy strips out the HTML comment and turns the sample value into a component:

      <span jwcid="insertColumnTotal">$137.33</span>

    The XML specification will provide the correct CSS class attribute at runtime based on business or presentation logic.

    If the layout of the page changes, the HTML developer just needs to avoid messing with tags marked with a "jwcid".

    If something new is added, the HTML produder adds it to the template and notifies the correct Java developer to fill in their side of things.

    None of the frameworks based on JSPs will *ever* be able to have integration this simple because you always have to put tons of cruft into the JSP.
  43. Actually, he was very clear that those three things at the beginning were conclusions of his research. It is not my intent to flame anyone, but I have seen this "hastiness" in drawing conclusions and making broad generalizations many times before.

    The JSP spec certainly has its issues, as does everything else (including Tapestry I'm sure), but the process you describe can also be effectively handled when using JSPs. If you have found Tapestry to work well in your situation, then I think that is great. But I don't think it is necessary to slash and burn another solution that works just fine for many others.

    What I would suggest is that people extoll the virtues of their favorite framework or whatever, and then respectfully explain perceived shortcomings with other solutions they have tried without broad generalizations that are almost always incorrect. I have found that process to be much more effective and it keeps religious wars from starting.

    I'll take a closer look at Tapestry...
  44. That is not really fair and I think that you know it. The implementation of the ApplicationHandler as described in the spec and the tutorial is half baked but clearly it is indicated that a better mechanism will be provided. Even if a solution is not provided how hard it is it for someone to abstract the event dispatching mechanism to an xml file or to simply let applications add event handlers in a generic manner to the ApplicationHandler.

    Point being : it is a spec designed to provide some flexibility in implementation in order to allow differentiation between vendors. Do not look for opportunities to spread disinformation.

    I have looked at Tapestry and it is an excellent piece of work. As you point out it is a bit light in terms of documentation. One of the most valuable aspects of tapesty is the concept of assets or better put the abstraction of assets which truly enable the development of fully encapsulated components that could potentially be dropped into an application very neatly. Why on earth JSF has completely missed this does shock me.

    Other unrelated points ...

    I have to add my 2 cents to the parade of - you have to be kidding me - that is all there is after two years - and to boot there is no source code distributed with the early access release.

    However, I personally feel that it is a good start towards a common serverside event based architecture. I shudder to think about how they are going to have to hack it to integrate it with struts ActionForms but that is an entirely different topic.

    To the point that there are not a lot of components included - who cares - it is the lifecycle, event handling, adn component architecture that is important - how long will it be before a good table, tree, etc etc etc are written - not long at all. Get the framework right and let the community do the rest.
  45. "To the point that there are not a lot of components included - who cares - it is the lifecycle, event handling, adn component architecture that is important - how long will it be before a good table, tree, etc etc etc are written - not long at all. Get the framework right and let the community do the rest.

    That's where the falacy lies, the JSF spec has some elaborate architecture, however if you can't back it up with a complex test case, then you don't know that it even works!

    That's precisely in my opinion what's completely bad about this spec, there's absolutely no proof that it even works!
  46. From the interview it seems like

    struts template tags => JSF front-end components

    Action class in struts => command class in JSF

    Struts Validator => similar validation in JSF

    I still dont see the point of using JSF.

    Also talking about nothing in Session seems bad design to
    me. Neat things can be done Session and Application objects.

  47. I'm not interested in JSF at all but it's nice to see some chicks on this site.

  48. I guess this would be interesting about 2 or 3 years ago, or how ever long it has been since I read some Java Server Faces hype. I'm sure the Sun folks mean well, but they really should get out more. Let's just say I'm glad I'm using Tapestry.
  49. Five years ago I used WebObjects. Those were some happy GUI years. Then, some other job. JSP. After WO, that felt like driving a bicycle instead of being driven in a Rolls. Now there is Tapestry. Yay, J2EE finally has what WO had five years ago. From happy to crappy to happy. I wish Apple had some marketing for WO.
  50. I don't know whether JSF is crap or not, but what's really frustrating about JCP is that we can't see what's going on there. In all democracies public media broadcasts the conversations of parliments. I just don't understand why a group of 10-15 persons should work secretly. What's going on there that results in crappy jsrs? If it were public (at least if we could read the mailing list), we could critisize their approach sooner than proposed final draft.

  51. I think it is only fair to have as many interviews with our good-looking female coleagues! More of the same Floyd.
  52. Whatever one may think about J2EE vs .NET - at least in some respects (Amy Fowler vs Doug Purdy) we have a clear winner ;-))

  53. Problem is Just too many Frameworks[ Go to top ]

    The big problem is that there are just too many Web Frameworks for Java.

    Just look at the list at :

    21 of them and its not even comprehensive. Sun has one called JATO, the new PetStore demo has another one, there's SwingLets and more swing-like frameworks are coming out everyday.

    Standardization now is important, I want to be able to get a Echo component and a Tapestry component and display it on the same webpage. I can't do that now, Its all or nothing. Enterprises will tend to pick the one they expect to be around for a long time, regardless of technological supperiority. That's why today Struts is king even though it's much weaker than WebWork. Its the same with people, which toolkit should I invest my time in such that in "enhances" my resume. Again, you pick the standard, because you expect most enterprises to be hiring for that knowledge.

    Sad as it may be, Tapestry and Echo, no matter how good they may be, isn't going to be adopted by the masses. My suggestion is to get yourselves organized and begin to play nicely in the JSF sandbox. Yes, I am still dissapointed that it took so long, however you've go to move on. The playing field now is JSF whether it sucks or not.

    History may serve as a guide, look at the JMS spec and RI, it doesn't have much of an implementation, however, it has spawned a thriving market of vendors. I hope JSF does the same.

  54. "The big problem is that there are just too many Web Frameworks for Java."

    I agree, here we are talking about providing complex GUI forms to J2EE applications.

    Well, I've been developing complex GUI front ends to J2EE servers for over a year with Borland's Delphi 6. The front ends are limited to Windows and Linux systems, but we all know how many Windows front ends are out there.

    The framework: Delphi->SOAP->J2EE, it's incredibly easy for Delphi to import a WSDL from the J2EE server and create a GUI.

    Also, keep in mind it's just as easy for the J2EE server to import a WSDL from Delphi. Thus, you can have your peer-to-peer and messanging frameworks created as well.

    Oh yes, one more thing, all of this SOAP plumbing will keep you ready to connect with .NET systems if you like.
  55. Yup, after waiting 2 years for JSF I expected more.

    Since everybody here talks about Tapestry I wanted to mention Echo ( and EchoPoint ( open source projects.

    Echo even supports multiwindow applications. It uses hidden frame that controlls the client state of browser. So if you have parent window and child window and if user closes the parent window the controll frame in child window can restore the parent window with the same state(last state sent to server).

    EchoPoint is project for developing components for Echo, it has TabbedPanes, Menus, Tree (Server and Client side) etc...

    Check it out !
  56. What's really sad about JSF is it has taken so long to deliver so little. While Sun and friends have been busy producing a 90 page artifact the rest of the world has been creating real working solutions.

    For my money the framework that is delivering results is Echo. Add in the components from the EchoPoint project (see Domagoj's post for the URLs) and you have what JSF might one day deliver.

    Phillip B
  57. could someone explain whether XUL ( XML user interface language) from mozilla will complement JSF or is it going to compete with it..
  58. I see alot of people comparing JSF to other NON-Standard frameworks. I'd like to hear some opinions on JSF as it stands by itself...

    Vendor lock-in (or the lack there of) is one of the biggest pro's of java. IMO, JSF goes a long way to providing a vendor neutral framework for gui components.

    Though thats not to say that JSF is only a gui component framework. With JSF Sun has provided some sound direction to developers who were left wondering "Well how in the world am I supposed to structure and organize my web applications?".

  59. Let's just hope they get off the Struts narrow look and
    expand out to Webworks or Maverick. I'll be damed if I'm
    going out the door with a paradigm that only ensompasses
    JSP. ( I won't get on a rant about JSP congestion)

    I need multiple choices and surely would like to see JSF
    as fast as possible.

    As far as the other subject about Fowler, I always have
    said that I may not be the greatest developer in the
    world, but I'm the bestlooking. You lose Amy.

  60. What are the plans for compliance with the W3C XForms standard?
  61. Where can I post Installation Problems?[ Go to top ]

    I want to check out the jsf-1_0-ea2 on jwsdp-1_0_01-windows-i586 from sun, but starting the cardemo I get always 'com.sun.faces.MISSING_RESOURCE_ERROR'...
    Is there a newsgroup for jsf?

  62. Can some one help me[ Go to top ]

    Very quickly!!

    How do you run JSF simple webpage in Borloand JBuilder 6

  63. Hi, everybody.

    I like JSF very much but I can't find any help about how to use it with database operations or complex business logic. Can anybody show me some complex applications with JSF and business logic(DB operation included is better)?

    My email/MSN is ejbstart at hotmail dot com.

    Thank you in advance.