Rethinking JSF - The Real Problem

Discussions

News: Rethinking JSF - The Real Problem

  1. Rethinking JSF - The Real Problem (127 messages)

    JSF has had a long and fairly controversial road so far. In "Rethinking JSF - The Real Problem," TSS looks at the reasons that JSF hasn't "caught on fire," along with addressing what needs to be done to overcome its barriers for the future. One example (of many!) from the article:
    The real problem is that JSF, for a component framework, has so few components. What kind of component would be useful? Well, consider your standard web application and how a user interacts with it: the user logs on, looks for something, reads it, possibly creates something new, then logs out. So... where are the login box components? Where are the search box components? Where are the data input components? Where's the ability to manage “pretty URLs?” (“Pretty URLs” are also known as bookmarkable URLs, or search-engine-friendly URLs.) Where is the data flow? Where's the conversational state? There's absolutely nothing in JSF that prevents these things from being made, and some groups (vendors, open source groups) have already made some of them - frameworks and implementations like Seam, IceFaces, RichFaces, Tomahawk, NetAdvantage, and others. For others, code is readily available in books like "JSF: The Complete Reference" (Schalk, Burns), "JSF In Action" (Mann), and "Core JSF" (Geary). Some elements are even available on the web (for example, how to manage pretty URLs). There are also sites with lots of JSF information: IBM developerWorks, http://java.sun.com, http://www.jsfcentral.com, http://www.jsftutorials.net, and http://www.theserverside.com itself. Most of these sites and references use JSF as it's meant to be used: there are no servlet filters (well, except in a few cases, where it makes the most sense). There are no servlets. All of them use the JSF component lifecycle, all of them are portable between compliant implementations of JSF. But most of the documentation focuses on the inputText component and its near cousins. While navigation and data input/output are, well, extremely important, by focusing on these, all JSF mentors are doing is telling people how JSF is different from what they're already used to. It's hard not to sympathize; authors tend to want to show simpler mechanisms to show something useful, rather than presenting something that needs advanced knowledge. If they opt to show something that needs advanced knowledge, then they alienate the readers who don't have it.
    While some of the problems are likely to be addressed in JSF2, that's still a year off - and most of the problems aren't related to the specification details themselves. They could have been fixed already. What do you think? What other problems do you see with JSF? What would you do about them, if anything?

    Threaded Messages (127)

  2. If you want an example of how to do a component-based Web framework, look at Tapestry, Wicket, or WebObjects (the latter of which got it pretty much right more than ten years ago). What boggles is the mind is that JSF, the so-called "industry-standard" framework was created by Craig McClanahan, the same guy who inflicted the execrable Struts framework on the world. And God knows how many poor unfortunate programmers followed that thing off a cliff. So to develop the specification for the "standard" replacement to JSP and Servlets, who does Sun turn to? Do they turn to someone like, say, Howard Lewis Ship, who created the excellent and widely-used Tapestry? No, they turn to Craig McClanahan, the guy who %$@($)^!ed things up in the first place. Brilliant.
  3. Before bashing Struts, think back to what you had to do six years ago before Struts existed. You wrote a custom servlet for your web site. Saving us from that exercise each time made Struts a significant improvement. The thing that made Struts so ugly was JSP.
  4. When Struts was made, we had an elegant framework like Tea. Tea might actually predate Struts. Even by today's standards, Tea is a very good framework. The grandparent is right... how can the guy who made Struts make something good? It's impossible. Unless the guy who made Struts had a life changing learning experience, we should expect more of the same -- a substandard, loveless, thoughtless torture of a framework written by someone who clearly doesn't love what he does for a living.
  5. Tea? I've never heard of it. Do you have a URL for it? If it's such a good framework why is it unknown?
  6. Tea? I've never heard of it. Do you have a URL for it?

    If it's such a good framework why is it unknown?
    If I remember correctly, it came out of Walt Disney.
  7. yup[ Go to top ]

    Yes, it was open source from Disney. To grandparent: It's not unknown. It's only unknown to people who prefer to ignore anything outside of their comfortably narrow view of things. If it's unknown, then how do I know about it? (And no, I don't work for Disney nor am I friends with any of its devs). There were many articles about it. I have no idea how anyone could miss it. Type "tea framework" into Google search.
  8. Struts2 (Webwork) is very good[ Go to top ]

    Worth a second look....
  9. I've never written a servlet in my life. Four years before Struts ever existed I used WebObjects. I don't remember exactly when Tapestry first appeared, but if it wasn't before Struts, then it wasn't long after it either. In short, there's no excuse for Struts ever having used, let alone written. It was a total mistake, right from the beginning, and those of us who said so at the time have been proven right. It's existence has only served to slow down and derail a lot of projects, while enriching publishers of technical books.
  10. What boggles is the mind is that JSF, the so-called "industry-standard" framework was created by Craig McClanahan, the same guy who inflicted the execrable Struts framework on the world. And God knows how many poor unfortunate programmers followed that thing off a cliff...
    In all fairness, though, in addition to Craig, you had other people like Amy Fowler involved. Even if you dislike Craig, Amy's credentials might be a little more to your tastes. (Or not.) Tapestry's nice, as is Wicket. That's not a comparison; I'm not saying JSF is better or worse than Wicket or Tapestry. That said, JSF *is* the JCP standard, whether we like it or not. Note that HLS *is* on the JSF 2 committee, and JSF 2 is likely to be a better beast than JSF 1 was.
  11. Note that HLS *is* on the JSF 2 committee, and JSF 2 is likely to be a better beast than JSF 1 was.
    They need to get someone from Microsoft ASP.NET team on board as well, serious.
  12. Bruce, I completely agree with your assessment ;) About 6 six years ago, I was confronted with Struts (and yes, that was already the most popular web framework and almost the only choice out of pure servlets world) and thought "what an abomination!". How hard is it to think in terms of UI components, have MVC at the component level, the way it's always been done in the desktop world. As a result, I developed and managed to sell for sometime a product (there's still info on it at http://www.kobrix.com/ticl.jsp) architected around similar principle of JSF. Then, due to JSF and the fact that too much effort went into something that didn't prove to be lucrative enough (we couldn't go open-source for other reasons), we abondoned progressively the project. We even had a visual RAD tool based on this stuff that worked pretty well. I still think that TICL was much better than JSF (and it's also a framework+components+tag library, so there's nothing wrong with the underlying servlets model), but JSF seems to be finally catching up and trying to recover from some of the bad decisions, at least from what I see in the plans for 2.0. Craig McClanahan seems to be a good programmer...I have seen a lot of the code in Tomcat for example, and he's probably smart. But designing a library is hard, and it's not for everybody. It's probably Sun's fault for not being able to pick competent people, especially when you have a sort of monopol and the ability to push a technology to the whole market. Probably there's a lot of politics involved, I'm not sure. But the popularity of something somebody created shouldn't be the main criterion. Tapestry may be popular, but Struts is even more popular, so that doesn't mean much because Struts' popularity is really incommensurable with its quality. Because of the so many similarities between what we did at Kobrix a few years ago and JSF, I decided to use JSF for one of my last projects. I thought it couldn't be that bad. Well, it was. I could get around it, but it was a very frustrating experience. JSF is screwed up in the details of every single part of it, which makes the whole thing unusable. Every single aspect of the framework has little annoying drawbacks that just add up. It also has some architectural flaws (like serialization of the whole component tree - an idiotic decision, and the inability to use it easily in JSP pages - another idiotic architectural bug). Most of the guys from the EG probably have never written a serious web app. Even though, I know none of them, that's the only explanation I have. That's why it takes years for a whole community the play with that crap and teach the handful of "experts" what to do to make it better. Every single one of them should be made to develop a real world webapp with JSF and then think again about what they're doing to other people ;) Best, Boris
  13. Bruce,

    JSF is screwed up in the details of every single part of it, which makes the whole thing unusable. Every single aspect of the framework has little annoying drawbacks that just add up.

    Best,
    Boris
    Such as...?
  14. SWING II, Get your Hot Dogs Here![ Go to top ]

    Ah yes!, the vendors the vendors the vendors, build it... and they will come. Yes, on the open market 1 or 2 swing drag and drop component layout kits after 10 years but still buggy still crap Vendors Vendors Vendors!, EJB Persistence, 1 Vendor, Hibernate after 10 years. Hibernate is still better than EJB entity beans implemented in Hibernate. JSF, lots of Vendors, noone in their right mind will use it...see you in a few years.... App Frameworks? Component Frameworks? Not one has caught on since the history of Java and you cant count struts its not even a framework unless you call a map of urls to classes and some crappy buggy tags a framework. Talking component frameworks for the web is like talking smalltalk 10 years ago. Noone cares about that stuff because there is no serious model for such a framework beyond MVC, and my momma used to say "MVC is as MVC does". MVC: Whatever and however you want to do it and screw it up as long as you screw it up in 3 layers. So flounder around with frameworks as long as you like, but noone is going there en masse until it is an inevitability that makes everything else look just plain dumb....on the surface. NOT under the hood. Rock on!
  15. And one more thing[ Go to top ]

    Everyone was talking about building complex components for GUI apps 20 years ago and you see where that ended up. WAKE UP. Finish your app. Stop wasting time!
  16. Echo2 and wingS go even further. They abstract from the whole HTML and CSS and JavaScript crap. BTW, what I really don't understand is, why do JSF people still think in pages? Have you ever seen a desktop ui done this way?
  17. Echo2 and wingS go even further. They abstract from the whole HTML and CSS and JavaScript crap.

    BTW, what I really don't understand is, why do JSF people still think in pages? Have you ever seen a desktop ui done this way?
    No but I have seen desktop apps thinking in panels and windows which is pretty much the same... I think JSF is not that far off from a rich client model, you have limites which are basically pushed onto you due to the html inherent request response cycle, but validation, event systems etc... this is pretty much very close to programming real rich client uis the main difference is you still have the dreadful html inherent roundtripping, which is a pain. I have programmed both and my personal guess is people coming from a rich client environment have an easy grasp especially if you add a stateful backend like Seam or Apache Orchestra, the main problem I see is that people coming from the classical, Page -> Action ->Page antipattern will have a hard time to adapt, but guess what they have to, the train even on the web clearly goes toward real rich client interfaces.
  18. No but I have seen desktop apps thinking in panels and windows which is pretty much the same...
    Maybe in what they are, but not how they are used. First people typically thing in "pages" or forms, not panels. Yes, people do the same in Swing/Echo2/wings/... but it is tons easier. Second, is the way things are called. If I want, i can easily have the same panel on a window, dialog, another panel, multiple times on the same panel, etc. I am not thinking of "forwarding to another page" but rather showing things.
  19. No but I have seen desktop apps thinking in panels and windows which is pretty much the same...

    Maybe in what they are, but not how they are used. First people typically thing in "pages" or forms, not panels. Yes, people do the same in Swing/Echo2/wings/... but it is tons easier. Second, is the way things are called. If I want, i can easily have the same panel on a window, dialog, another panel, multiple times on the same panel, etc. I am not thinking of "forwarding to another page" but rather showing things.
    Sorry this will be a long answer You talk about several things here, first of all in Swing the backend is stateful there are no request boundaries hence you have an object (most of the times combined controller model objects) and its representation all of them have states and you basically just shift data and app logic. Then we talk about ajax frameworks like echo2... I dont know the ins and outs of echo2 but I assume most of its logic also is stateful in the sense that you basically shift divs and keep everything within the browser via javascript with an occasional event into the backend. The downside of this approach is that it is very hard to sync some data with the server (resize events etc...) which means if you have a page refresh it is often either cookies or you lose data. Also you omit stuff like becoming barrier free, or even lots of browser versions or a simple hit on the refresh or back button entirely. Also Javascript is a must and speed also is an issue once you move heavily into ajax. The backend then is the same web centric mess, either stateful in the sense of being session scoped or request scoped with single backend requests triggering data shifts between the ajax part on the client and the backend which is delegated to a simple data pass through. I would call this approach rich client ui 0.8 because it falls flat on its face in certain situations. Next approach limited scoped backends like Seam or Apache orchestra, this basically keeps the backen stateful for limited amounts of time but does not care about the state of the ui frontend, currently it is used to take the teeth out of the request bytes without filling the ram a simple session scoped approach does. The frontend could be stateful as well but you run into the limitations of ajax based rich client uis. Next apprach flex, a real rich client interface which probably has the same it cannot keep its state over browser reloads problem (applets have that as well) and the same problem as echo2 and other frameworks... The list is pretty endless... There is no ideal solution, and probably never will be otherwise we probably would be programming in a compressed X protocol not the broken html protocol ;-) So why did jsf not go that route, simple, jsf originally was planned as a framework which should allow a programming model very similar to rich client uis (which are saner to program for than simple action based html once it gets to complex user interaction) but within a terminal like scope, which means refreshes etc... JSF in its original plan also is way older then the entire ajax craze (which also is broken by design imho), the train has to go and will go in the long run towards a real rich client programming model. The question is not that but when, it will depend on how fast a platform agnostic usable standard will be adopted (currently everyone tries to push its own agenda microsoft by shoving windows and .net down everyones throat by leveraging its monopoly, adobe by pushing its own stuff and sun of course by trying to revive applets). But the final result of this will be that the entire html protocol will be delegated to a transport tunnel or finally being pushed into the stack of history protocols. But back to your question, why not a rich client approach, basically because the framework lives in the domain of a webcentric approach, not in one of a as close as possible being a rich client domain while still having to live with the limitations the browser push upon me approach like echo2 and not pushing its entirely own technology like apples do, or flex. That JSF can scale to echo2 has been shown in the past and various frameworks currently adopt that approach due to the ajax craze, but I do not think ajax really is the answer to the problem that in the end we try to shoehorn a technology for simple documents (html) into the domain of user interfaces which need a lot of interactivity.
  20. BTW, what I really don't understand is, why do JSF people still think in pages? Have you ever seen a desktop ui done this way?
    Most of the desktop applications I know of - with the exception of multi purpose applications - are geared around the concept of data input masks and data display lists (or graphs). This is pretty much the same then thinking in pages with a state machine attached. Some people blame that on the notation of screen in mainframe environments. I think the reason is more that most of the people that order a piece of software have a pretty good idea what an application should do - and there most suitable layer of abstraction are "visual processes" which is a glorified term for a sequence of input masks (aka pages or panels).
  21. BTW, what I really don't understand is, why do JSF people still think in pages? Have you ever seen a desktop ui done this way?


    Most of the desktop applications I know of - with the exception of multi purpose applications - are geared around the concept of data input masks and data display lists (or graphs). This is pretty much the same then thinking in pages with a state machine attached.

    Some people blame that on the notation of screen in mainframe environments. I think the reason is more that most of the people that order a piece of software have a pretty good idea what an application should do - and there most suitable layer of abstraction are "visual processes" which is a glorified term for a sequence of input masks (aka pages or panels).
    It's an interesting reasoning, and, just as an alternative reasoning that would refer to the fact that the web started out document oriented, it's a purely technical one. Ask a regular layman to describe what he sees on an average web page, and he'll tell you about links, buttons, input fields, sections, tab bars, etc. Abstractions like that just make sense for user interfaces, whether they are displayed directly or embedded in a web browser.
  22. Ask a regular layman to describe what he sees on an average web page, and he'll tell you about links, buttons, input fields, sections, tab bars, etc. Abstractions like that just make sense for user interfaces, whether they are displayed directly or embedded in a web browser.
    Yes, but they only make sense within a particular harness. And this harness is more often than not the concept of a "step in a process" which people translate to "a panel" or "a page" in almost all cases I came across. This is a "natural way" of thinking that probably and ultimately can be traced back to printed forms, where separators and tick boxes are a valid abstraction itself.
  23. Yes, but they only make sense within a particular harness. And this harness is more often than not the concept of a "step in a process" which people translate to "a panel" or "a page" in almost all cases I came across.
    Imho, it's a big conceptual difference whether you limit your reasoning to pages (like JSF in fact does) or include parts of it (like panels).
    This is a "natural way" of thinking that probably and ultimately can be traced back to printed forms, where separators and tick boxes are a valid abstraction itself.
    It's natural for people to think about the task at hand first, I agree with that. But if you want to design applications that way, I think you should pick a proper workflow engine and let it drive the UI. Having flow on only page level and only in the UI layer combines the worst of both worlds.
  24. BTW, what I really don't understand is, why do JSF people still think in pages? Have you ever seen a desktop ui done this way?
    Yes, any application using the tab metaphor. I've even seen something called PropertySheet IIRC.
  25. Echo2 and wingS go even further. They abstract from the whole HTML and CSS and JavaScript crap.
    That's sometimes, but not always for the better though. Subjective I guess, but if you use a development model where you work with seperate designers and/ or work with HTML mockups as your design input (and want to use HTML tools for that), having to use layout managers can actually be a pain. Also, the ability to directly mess with HTML/ JS can save you a lot of pain if the framework doesn't exactly do what you want.
    BTW, what I really don't understand is, why do JSF people still think in pages? Have you ever seen a desktop ui done this way?
    YES! I wish I would read this more in discussions like this. :)
  26. No, they turn to Craig McClanahan, the guy who %$@($)^!ed things up in the first place. Brilliant.
    I have it on good authority his real name is Craig Mclotsofwordslikepoopooandwaawaabutendinginploppy..
  27. I have it on good authority his real name is Craig Mclotsofwordslikepoopooandwaawaabutendinginploppy..
    And if I could get Hani to spell it right at least once during each diatribe, then I'd be able to find these gems of wisdom with Google!!!! Craig McClanahan
  28. What an asinine post-- the components are there-- if people were really looking for them they would be available from some library-- a search box component? Ever written search for a site or think it can be abstracted into a generic UI component? Yes, a backing bean and h:inputText would do here, so what's the argument? There is view-based conversational state-- how do you think Seam and Tomahawk and others are able to implement their solution? Granted, we didn't define a managed bean scope in the API, but there's an abundance of solutions available for JSF that go beyond conversation into process and business scopes, etc. Pretty URLs-- lets be fair here-- we aren't creating URLs like /emp.jsf?EJEJEIFJ23423-34234j32ljk423... You can do /emp.jsf?id=3232 and have it work fine for get's. Read any of the JSF 1.2 documentation or blogs on the topic. If what you really want is restful URLs and are actually committing to a restful/read only scheme, than any component framework is probably not going to be best suited for that app. Good luck with flame fishing, it's hard being at the top.
  29. If what you really want is restful URLs and are actually committing to a restful/read only scheme, than any component framework is probably not going to be best suited for that app.
    I have to disagree. Have you seen how Wicket handles pretty URLs? Of the popular component frameworks, it's only JSF that suffers in the URL department. (Yea, I know JSF is not a framework...that's part of the problem!)
  30. Pretty URLs-- lets be fair here-- we aren't creating URLs like /emp.jsf?EJEJEIFJ23423-34234j32ljk423... You can do /emp.jsf?id=3232 and have it work fine for get's. Read any of the JSF 1.2 documentation or blogs on the topic.
    Or my component. :P
  31. Everyone out there thinks they have the better mouse trap. Just today we have a post for jSeamless which is nice just like the 50 or so before it. Spring is out there trying to replace J2EE and JSF, we have Wicket, Tapestry, etc etc etc. The java community will put framework after framework because frankly given one framework we can all say "I can do better than that". The real problem in JSF is that like all standard driven initiatives it is long on specification and short on implementation. Besides a few smaller vendors there are only two larger vendors supporting JSF. Oracle has provided the first set of rich components and gave most of them to Apache Trinidad. JBoss has helped solved the session (conversational scope) issue on the back end. Both are open source. Where the other vendors (e.g. Sun, IBM) are is beyond me. I have used a bunch of frameworks and the component frameworks all suffer from one major issue. That is the quality of the components being offered. As we get deeper and deeper into rich component suites we will find that the quality of components does matter. This is where I predict most of the frameworks will suffer because there will not be enough "free" programmers to maintain quality components for all of these new frameworks. In this regard, JSF because of the lack of industry support, has suffered as well. The article is right on in what I consider the three important issues facing JSF
    1. Quality rich components (solved by Oracle)
    2. Server-side persistent state management (solved by Seam)
    3. Good set of documents (first generation lead many JSF programmer off a cliff).
    JSP is only an issue with JSF when you don't use JSPX. Point being don't use JSP for anything but writing XML documents and most of JSP problems go away, a means to an end. Writing custom components, taglibs, for JSF is way to hard because of JSP. I hope we find an alternative to JSP in the next specification.
  32. JSP is only an issue with JSF when you don't use JSPX. Point being don't use JSP for anything but writing XML documents and most of JSP problems go away, a means to an end. Writing custom components, taglibs, for JSF is way to hard because of JSP. I hope we find an alternative to JSP in the next specification.
    We have a very good alternative to JSP already. It's Facelets. If you're doing JSF development and you're not using Facelets, you're really missing out. Writing custom components and taglibs with Facelets couldn't be simpler. I think the real problem with JSF is that people keep whining about things that aren't problems because there is a group of JSF haters that likes to hear that crap.
  33. JSP is only an issue with JSF when you don't use JSPX. Point being don't use JSP for anything but writing XML documents and most of JSP problems go away, a means to an end. Writing custom components, taglibs, for JSF is way to hard because of JSP. I hope we find an alternative to JSP in the next specification.


    We have a very good alternative to JSP already. It's Facelets. If you're doing JSF development and you're not using Facelets, you're really missing out. Writing custom components and taglibs with Facelets couldn't be simpler.

    I think the real problem with JSF is that people keep whining about things that aren't problems because there is a group of JSF haters that likes to hear that crap.
    The problem is, a) the original post was clearly a flamewar iniative, secondly, we hear constantly the complaints of the lack of components, guess what, there is none, with around 5 different huge oss component libraries in the wild. This is a problem of standards, standards move slow, but then again, if the development already is there in the oss world then people start to complain that it is not there because it is not in the standard. Most complaints I got from new JSF users were, why I have to learn additional libraries. I tell them usually, guess what, you were using jsp, you had to learn additional taglibs to be productive, you often had to learn additional frameworks on top of it, the reason for this is, jsp tries to concentrate itself onto a minimum somehow. I personally am glad that JSF has limited itself to the bare minimum of html deliverable components, because it left the world open for many opensource solutions, but I agree it is time now that some of this stuff is going back into the standards! JSF has weak points, especially on API level but the lack of components definitely is not its weak point!
  34. The real problem in JSF is that like all standard driven initiatives it is long on specification and short on implementation. Besides a few smaller vendors there are only two larger vendors supporting JSF. Oracle has provided the first set of rich components and gave most of them to Apache Trinidad. JBoss has helped solved the session (conversational scope) issue on the back end. Both are open source. Where the other vendors (e.g. Sun, IBM) are is beyond me.
    Hmm. That's an odd statement. Sun sponsors the RI with one fill-time developer committed to it, in addition to several part-timers (Ed Burns, Roger Kitain, Jennifer Ball). They also sponsor, to a certain extent, development on JSFTemplating, which powers the admin console in GlassFish, not to mention the excellent Woodstock component set. IBM sponsors Eclipse, which offers JSF support as part of WTP.
    I hope we find an alternative to JSP in the next specification.
    I don't expect that you'll be disappointed.
  35. JSF Challenges[ Go to top ]

    I'm quite a fan of the framework, and use it regularly in my team's production products, in its IBM implementation. Which means we're somewhat insulated from the "dearth of widgets" problem you accurately cite. IBM has some really nice widgets; the problem is it takes a week of research to figure out how to use them, as the documentation is somewhere between light and missing. Bugs seem to be steadily diminishing, and time savings are pretty impressive by anecdotal measurement. One big stumbling block for web developers may be the underlying event model. No doubt people with more agile brains than mine will give the lie to this, but it can be difficult to keep in mind just what phase is happening before which, all the time. When I find recalcitrant problems, more often than not it's traced to a misunderstanding or misuse of the lifecycle. Wiring JSF to Spring has been a pleasure; finally seeing the development community really "get" the AJAX connection has been even better. Remember Einstein's explanation of radio? "It's like a cat with its head in NYC and its tail in SF. Stroke its bum in SF and it purrs on Broadway. Except there's no cat" JSF is like Swing Except there's no shared memory.
  36. We've solved a lot of problems by replacing JSP with FreeMarker and so we don't want to go back to JSP. My development teams are having a great time with FreeMarker on top of Struts 2. The only issue is that Struts 2 isn't standards-compliant, and JSF is. There are many reasons why we'd like to switch to a standards-compliant framework which I won't discuss here. We've looked and JSF and it's a good framework. We're just waiting for someone to provide FreeMarker support for the views.
  37. Einstein's quote[ Go to top ]

    Not to be too much of a stickler here (well, maybe I am) the quote is "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat. " You can find it here: http://en.wikiquote.org/wiki/Albert_Einstein
  38. Imho, the problems with JSF (and the ultimate reason why Wicket was started in the first place) all start and end with the fact that it isn't based on a programming model that tries to stay close to simply Java programming.
  39. Imho, the problems with JSF (and the ultimate reason why Wicket was started in the first place) all start and end with the fact that it isn't based on a programming model that tries to stay close to simply Java programming.
    It's arguing personal preference (which is fine), but look at what's happening to java desktop-- moving out of hand coded Java listeners/bindings into domain specific architypes, most familiarly with XML notation-- plugging in existing domain artifacts.
  40. Agree[ Go to top ]

    I don't think one or two JSF component library can cover all the needed components. So, the ultimate way for JSF is that JSF should make developing a customized component EASY. In my project using JSF, I cannot event find a multi-select checkbox group aligned in three columns. So I must create a customized component. What should I do if I need another one that checkboxes align in two columns? So, the way is not to provide all components, is to provide a easy, elegant way to create customized component. Another important think: IDE support, matually.
  41. Re: Agree[ Go to top ]

    I don't think one or two JSF component library can cover all the needed components.
    So, the ultimate way for JSF is that JSF should make developing a customized component EASY.
    In my project using JSF, I cannot event find a multi-select checkbox group aligned in three columns. So I must create a customized component. What should I do if I need another one that checkboxes align in two columns?
    You must create a customized component? Just use a few h:selectBooleanCheckbox components and put a little logic in your backing bean. It's really not that difficult.
  42. yes![ Go to top ]

    So, the ultimate way for JSF is that JSF should make developing a customized component EASY.
    Bingo! Easy and FUN and without the hidden gotchas that RI and myfaces are full of. JSF is an utter failure when it comes to ease of use.
  43. Re: yes![ Go to top ]

    So, the ultimate way for JSF is that JSF should make developing a customized component EASY.


    Bingo!

    Easy and FUN and without the hidden gotchas that RI and myfaces are full of.

    JSF is an utter failure when it comes to ease of use.
    ...and it seems the market agrees with you... sure...
  44. Re: yes![ Go to top ]

    So, the ultimate way for JSF is that JSF should make developing a customized component EASY.


    Bingo!

    Easy and FUN and without the hidden gotchas that RI and myfaces are full of.

    JSF is an utter failure when it comes to ease of use.


    ...and it seems the market agrees with you... sure...
    The market surely agreed with Struts: a monument of vulgarity. Besides, as I said, the market doesn't have to agree ... it's imposed by the mechanisms of industry "control and propaganda" ;) Seriously, I'm recommending JSF for new projects, not because I think it's good, but because it's better than nothing and because of things like that graph...it's a wiser long term investment for big organizations because it has better chances of evolving and being maintained.
  45. Re: yes![ Go to top ]

    Yeah this whole thing just has me waiting to see some kind of demi god strike everyone down where they stand. I've got some links for you. How about www.etrade.com www.ebay.com We poor Tapestry developers don't have the marketing clout to pimp our technology everywhere as effectively as everyone else - but our stuff sure as shit isn't getting used to develop a bunch of crappy intranet apps.
    ... Besides, as I said, the market doesn't have to agree ... it's imposed by the mechanisms of industry "control and propaganda" ;) Seriously, I'm recommending JSF for new projects, not because I think it's good, but because it's better than nothing and because of things like that graph...it's a wiser long term investment for big organizations because it has better chances of evolving and being maintained.
  46. Re: yes![ Go to top ]

    We poor Tapestry developers don't have the marketing clout to pimp our technology everywhere as effectively as everyone else - but our stuff sure as shit isn't getting used to develop a bunch of crappy intranet apps.
    Jesse, I disagree with you on this one. The opportunity Tapestry has had in terms of exposure in past (JavaOne presence, theserverside being 100% implemented with Tapestry but now most of Tapestry being dumped, an Apache project, several years ago Howard's aggressive and irritating marketing by turning almost every discussions into a Tapestry discussion, though he's stopped with that strategy, and you name it ...) is overwhelming. If you haven't heard it before, I'll repeat. Tapestry has a learning curve that is too steep for many people. So stop playing a victim and instead work hard to make your product easy to learn and use. And after that the mass would follow. It's as simple as that. Jan
  47. Why do you keep posting this?[ Go to top ]

    ...and it seems the market agrees with you... sure...
    Why do you keep posting this slanted query? If you modify it like so , clearly Struts is the best framework. The Market has spoken!
  48. ...and it seems the market agrees with you... sure...


    Why do you keep posting this slanted query?

    If you modify it like so , clearly Struts is the best framework. The Market has spoken!
    The best solution doesn't have to be the best in all categories. Struts was the best because it represented a "perfect storm" of features, ease of use, accessibility, cost, support, ubiquity, and need. If say, Tapestry, was better than Struts, Tapestry would be where Struts is. Not to pick on Tapestry, but the last 3 releases have broken compatibility with their predacessors. Who would risk themselves taking a change of something like that? I'm now currently working on a post-Struts app in the form of GWT and I say Struts did its job well. None of our customers say "Struts is paeg-oriented!" or "Struts forces me to extend Action!" For some reason, this just doesn't come up in conversation. How about, instead, acknowledging that Struts clearly filled a necessary niche and definitely did it better than everyone else.
  49. who cares about the market?[ Go to top ]

    Struts was a market "success"! But it's a terrible framework. Tea was a market "failure", but it's a great framework, and Tea's source code is listed right under the "proper Java source code" dictionary entry. I looked at Struts source and I looked at Tea source. I know which developer is better. Who cares that the market preferred Struts?
  50. Re: yes![ Go to top ]

    So, the ultimate way for JSF is that JSF should make developing a customized component EASY.


    Bingo!

    Easy and FUN and without the hidden gotchas that RI and myfaces are full of.

    JSF is an utter failure when it comes to ease of use.


    ...and it seems the market agrees with you... sure...
    Depends on how you read the graph. The devil's advocate in me says "All the graph shows is that it takes 2-3 times the number of JSF guys to get the job done compared to other frameworks..."
  51. It's arguing personal preference (which is fine),
    True to some point, though I think it illustrates that JSF wasn't designed from the most basic abstractions on but rather made many assumptions right from the start.
    but look at what's happening to java desktop-- moving out of hand coded Java listeners/bindings into domain specific architypes, most familiarly with XML notation-- plugging in existing domain artifacts.
    The fact that there are initiatives to do that doesn't validate it imho.
  52. Domain Specific[ Go to top ]

    It's arguing personal preference (which is fine), but look at what's happening to java desktop-- moving out of hand coded Java listeners/bindings into domain specific architypes, most familiarly with XML notation-- plugging in existing domain artifacts.
    I wonder where this would be happening? Are you talking about the bizarre JavaFX Script? Totally unnecessary IMHO. If the domain is adequately described with an existing language, the introduction of "domain specific language" is just stupid. Java desktop is hopefully moving into tools generated UIs, as for example with Matisse. How the stuff is stored is plain irrelevant to start with and if you look at the stored artifacts at best irregulary it is probably better to keep it in lingua franca rather than to relearn the DSL every time around.
  53. Re: Domain Specific[ Go to top ]

    It's arguing personal preference (which is fine), but look at what's happening to java desktop-- moving out of hand coded Java listeners/bindings into domain specific architypes, most familiarly with XML notation-- plugging in existing domain artifacts.


    I wonder where this would be happening? Are you talking about the bizarre JavaFX Script? Totally unnecessary IMHO. If the domain is adequately described with an existing language, the introduction of "domain specific language" is just stupid. Java desktop is hopefully moving into tools generated UIs, as for example with Matisse. How the stuff is stored is plain irrelevant to start with and if you look at the stored artifacts at best irregulary it is probably better to keep it in lingua franca rather than to relearn the DSL every time around.
    Actually it is not irrelevant how the stuff is store. Some storage formats are inherently tools evil. There is a reason why matisse is a one way tool and not a complete roundtripping tool, because Swings storage format is Java, which makes it inherently tools unfriendly, either you live with something which tries two way processing and parses the java code and fails 10% of the time due to manual code interference, or you live with a separate storage format, storing the data in a tools friendly way and some generated code with clear interference points like matisse does it. As for javafx script, I agree this is somewhat problematic, why another scripting language, i have not seen anything which couldnt have been covered with existing languages, again a mixup of visual representation and logic in one storage format, and additionally two syntaxes living side by side.
  54. Imho, the problems with JSF (and the ultimate reason why Wicket was started in the first place) all start and end with the fact that it isn't based on a programming model that tries to stay close to simply Java programming.
    I agree with Jacob. Personally, I think building a UI in all Java code is an awful way to build interfaces. It seems to me that in every Wicket vs JSF comparison I see, they complain the "giant" markup and "tag soup" of JSF, then contrast that with (IMO) slightly smaller HTML and TON of Java code, Java Jambalaya if you will. To me, it's easier to read, say, than have to parse the relevant $NUM lines of Java code that Wicket requires. Then again, it's a personal preference: I think a DSL for UIs makes more sense.
  55. Imho, the problems with JSF (and the ultimate reason why Wicket was started in the first place) all start and end with the fact that it isn't based on a programming model that tries to stay close to simply Java programming.

    I agree with Jacob. Personally, I think building a UI in all Java code is an awful way to build interfaces. It seems to me that in every Wicket vs JSF comparison I see, they complain the "giant" markup and "tag soup" of JSF, then contrast that with (IMO) slightly smaller HTML and TON of Java code, Java Jambalaya if you will. To me, it's easier to read, say, than have to parse the relevant $NUM lines of Java code that Wicket requires.

    Then again, it's a personal preference: I think a DSL for UIs makes more sense.
    This is a classical debate, in my experience it is better to decouple the visual aspects of something from the implementation language as long as it is a general implementation language. The reason, it becomes in the long rum more verbose, harder to maintain, because visual tools cannot hook in and generally it is a huge mess to adjust. The classical problem here is Swing, Swing while being overall excellent has two weak points, the one being the layout information hardcoded in java, the second one being the visual representation being hardcoded in java! While still being maintainable this made things way harder than they should be. I think it is even more valid for html, where a clear split between visual representation and markup, yet is not possible due to lousy CSS implementations. All I can say is, use something which is on the display code for visual representation like freemarker, velocity etc... any templating mechanism, but for heavens sake, do never ever, code this stuff in java! This is one point i have major grips in jsf as well, the printwriter API on component level clearly is a design mistake which has to be cleared up!
  56. The classical problem here is Swing, Swing while being overall excellent has two weak points, the one being the layout information hardcoded in java, the second one being the visual representation being hardcoded in java! While still being maintainable this made things way harder than they should be.
    Hi, this is how things are done in Winform, though in Winform 2.0 VS generated C#/VB code is saved in a separate source file (aka partial class). You are advocating the old VB6 and Delphi!
  57. The classical problem here is Swing, Swing while being overall excellent has two weak points, the one being the layout information hardcoded in java, the second one being the visual representation being hardcoded in java! While still being maintainable this made things way harder than they should be.


    Hi, this is how things are done in Winform, though in Winform 2.0 VS generated C#/VB code is saved in a separate source file (aka partial class).

    You are advocating the old VB6 and Delphi!
    Not really... I am advocating that some layout information is pushed into files more maintainable than java sourcefiles. Having everything hardcoded into Java was a major burden in Swing, people started to experiment with various ways to push the entire view aspect of the layer into better suitable formats, there are at least 5 xml file implementations, one java layout management implementation which tries to separate the layout information from the components, at least 2 ways to serialize this stuff, and about 2 two way generators which never probably will work, and several one way generators which utilize a bunch of non portable meta information files. Microsoft and also Delphi have made a lot of mistakes, no layout management whatsoever, lousy resource files which were not readable lousy control apis, no mvc on control level etc..., but pushing the entire view aspect into a different language domain defintely worked, the main problem was not doing that it was that the languages used sometimes were lousy so the ideas were made obsolete implementationwise ;-) Partual classes probably help to some degree, because you can isolate a lot of the layouting information away from controller mechanisms like event handling connectors etc... This is somewhat also a different domain, more suitable than raw source code where everything is pushed in!
  58. I think it is even more valid for html, where a clear split between visual representation and markup, yet is not possible due to lousy CSS implementations. All I can say is, use something which is on the display code for visual representation like freemarker, velocity etc... any templating mechanism, but for heavens sake, do never ever, code this stuff in java!
    A variation perhaps: never ever code logic in your presentation templates. Use a 3GL for that and keep your templates clean so that they only contain elements for static representation and placeholders for the logic to grip in. You can in fact come a long way doing that using JSP (model 1) and Freemarker etc, but the fact that such templating techs do not forbid including logic makes that everyone except for the most diciplined programmers will end up with tag soup (lots of code duplication, the DSL bended to do things they weren't designed for, logic shattered over both templates and in Java, etc).
  59. Imho, the problems with JSF (and the ultimate reason why Wicket was started in the first place) all start and end with the fact that it isn't based on a programming model that tries to stay close to simply Java programming.

    I agree with Jacob. Personally, I think building a UI in all Java code is an awful way to build interfaces. It seems to me that in every Wicket vs JSF comparison I see, they complain the "giant" markup and "tag soup" of JSF, then contrast that with (IMO) slightly smaller HTML and TON of Java code, Java Jambalaya if you will. To me, it's easier to read, say, than have to parse the relevant $NUM lines of Java code that Wicket requires.

    Then again, it's a personal preference: I think a DSL for UIs makes more sense.
    With Wicket you build the LOGIC with Java, and all the presentation directly in markup (HTML). Big difference. Also, ... you'd have to know what 'myBean' and it's propery 'someValue' is no? At the same time it introduces a foreign concept in HTML, making it unusable with regular HTML editors and designers have to know what it means (which in this particular example is easy, but can be tricky).
  60. Before the TSS publishes an article like this they should make sure the author has a clue about what they're writing about. A reusable generic login component? Are you kidding me? Components need to be fine grained in order to be reusable and customizable. People need to realize the JSF expects it's developers to be users of components and not creators of them. I've worked with JSF for years and never had a UI requirement that I couldn't fulfill by simply wiring together JSF components already available using managed beans. And for the record: (url comparing markets for various web frameworks) Looks to me like JSF has taken of and caught on just fine. Mike Message was edited by: joeo at enigmastation dot com (converted url to shorter form)
  61. Before the TSS publishes an article like this they should make sure the author has a clue about what they're writing about.

    A reusable generic login component? Are you kidding me?
    No. All it takes is a backing bean that conforms to an interface (i.e., has login(), logout(), accessors and mutators for user, password, groups) and a component renderer that presents "log in" and "log out" states. The renderer would bind to a component on the back end that conformed to the interface. The implementation could use JAAS, programmatic login, Spring Security, whatever the developer wanted. Incidentally, I've done this. In real code. You can also find examples of a log in component in Schalk and Burns' book, if you don't believe me. Doubt less.
  62. Before the TSS publishes an article like this they should make sure the author has a clue about what they're writing about.

    A reusable generic login component? Are you kidding me?
    No. All it takes is a backing bean that conforms to an interface (i.e., has login(), logout(), accessors and mutators for user, password, groups) and a component renderer that presents "log in" and "log out" states. The renderer would bind to a component on the back end that conformed to the interface.

    The implementation could use JAAS, programmatic login, Spring Security, whatever the developer wanted.

    Incidentally, I've done this. In real code. You can also find examples of a log in component in Schalk and Burns' book, if you don't believe me.

    Doubt less.
    Sure you CAN create a login component but why would you want to when it's so mind numbingly easy to do with what JSF already provides? This log-in component notion is a solution looking for a problem.
  63. Before the TSS publishes an article like this they should make sure the author has a clue about what they're writing about.

    A reusable generic login component? Are you kidding me?
    No. All it takes is a backing bean that conforms to an interface (i.e., has login(), logout(), accessors and mutators for user, password, groups) and a component renderer that presents "log in" and "log out" states. The renderer would bind to a component on the back end that conformed to the interface.

    The implementation could use JAAS, programmatic login, Spring Security, whatever the developer wanted.

    Incidentally, I've done this. In real code. You can also find examples of a log in component in Schalk and Burns' book, if you don't believe me.

    Doubt less.
    How do you tackle problems like: * Different login form and error message layout * New functionality such as (forgot password and/or forgot username) * Remember me * Customizing the label and message text for all of the different elements of your login form * Combining login with "register new" functionality * Different elements of complexity to wire up the various authentication backends to all of the above wrinkles. The list of possible features and customizations goes on and on. In addition, if you attempt to create a component that handles tons of different situations you begin forcing upon your users a large amount of domain specific knowledge just so they can login to their app. Now if you have a large number of applications in your organization that require the same login interface with the same set of requirements then it may be feasible to create a small in scope specific login component that all these applications can share. Keeping in mind that the purpose for creating this component would be for reuse not "one time" or "few time" use. I don't doubt that others have provided such components as examples in books. However, it's important to keep in mind that such situations are the exception and not the rule and should not be looked at as a JSF deficiency for not having one. Mike
  64. Before the TSS publishes an article like this they should make sure the author has a clue about what they're writing about.

    A reusable generic login component? Are you kidding me?
    No. All it takes is a backing bean that conforms to an interface (i.e., has login(), logout(), accessors and mutators for user, password, groups) and a component renderer that presents "log in" and "log out" states. The renderer would bind to a component on the back end that conformed to the interface.

    The implementation could use JAAS, programmatic login, Spring Security, whatever the developer wanted.

    Incidentally, I've done this. In real code. You can also find examples of a log in component in Schalk and Burns' book, if you don't believe me.

    Doubt less.


    How do you tackle problems like:

    * Different login form and error message layout
    * New functionality such as (forgot password and/or forgot username)
    * Remember me
    * Customizing the label and message text for all of the different elements of your login form
    * Combining login with "register new" functionality
    * Different elements of complexity to wire up the various authentication backends to all of the above wrinkles.

    The list of possible features and customizations goes on and on. In addition, if you attempt to create a component that handles tons of different situations you begin forcing upon your users a large amount of domain specific knowledge just so they can login to their app.

    Now if you have a large number of applications in your organization that require the same login interface with the same set of requirements then it may be feasible to create a small in scope specific login component that all these applications can share. Keeping in mind that the purpose for creating this component would be for reuse not "one time" or "few time" use.

    I don't doubt that others have provided such components as examples in books. However, it's important to keep in mind that such situations are the exception and not the rule and should not be looked at as a JSF deficiency for not having one.

    Mike
    Different form? Different template. Easy enough. Forgot password or username? Add to the interface. My spec wasn't complete by any means. Remember me? Again, easy to do (and shown in books.) Customization of labels, etc? I18N. Provide a properties file, done. Register new? Again, a different phase of the component. Wiring to backends is a little more difficult, but not much; it really depends on what you need. Personally, I use Spring to inject what I need if the user/password isn't enough, but hey. The basic idea is fairly simple... if a portlet can do it, so can a JSF component. There shouldn't be a disconnect there.
  65. Different form? Different template. Easy enough.
    Different Template? What template? So your users have to learn some kind of custom component templating scheme?

    Forgot password or username? Add to the interface. My spec wasn't complete by any means.

    Remember me? Again, easy to do (and shown in books.)
    And if they don't want that functionality you have dead methods in your interface and more variables to take into account in the template.

    Customization of labels, etc? I18N. Provide a properties file, done.
    Unless you want different labels for different instances of of the component in your app then you have some way to wire your properties file to your component. What if they want to use Input buttons instead of images in any of the buttons/links available in the form? More complexity in the template Replacement of internationalized images instead of button labels? More complexity in your templating language/button customization. Internationalized images as part of some logo displayed with the login form? Now you need custom I18N keys to represent custom portions of your login form template.

    Register new? Again, a different phase of the component.

    Wiring to backends is a little more difficult, but not much; it really depends on what you need. Personally, I use Spring to inject what I need if the user/password isn't enough, but hey.
    Again I'm not saying it's not possible just not feasible compared to simply using the existing components, a backing bean, and wiring smaller scoped components together with your backing bean.

    The basic idea is fairly simple... if a portlet can do it, so can a JSF component. There shouldn't be a disconnect there.
    Portlets attack a different problem space from JSF IMHO. A problem space where a reduction in customization and scope is the norm. Perhaps it is just my particular experience talking but I believe that attempting to create components that span entire use cases and believing they will be generically reusable is impractical and a JSF anti-pattern. Where I think JSF shines is in facilitating the wiring together of many small scoped components to compose an entire use case. Mike
  66. As if JSF has anything to do with this functionality. Man the component bug is such a sad illness. It's a cut and paste operation that keeps you up all night for months and never is finished. Just cut and paste it fool!
  67. "The implementation could use JAAS, programmatic login, Spring Security, whatever the developer wanted." And so could any other implementation without JSF. So Whats your point Joe?
  68. Before the TSS publishes an article like this they should make sure the author has a clue about what they're writing about. A reusable generic login component? Are you kidding me?
    No. All it takes is a backing bean that conforms to an interface (i.e., has login(), logout(), accessors and mutators for user, password, groups) and a component renderer that presents "log in" and "log out" states. The renderer would bind to a component on the back end that conformed to the interface. The implementation could use JAAS, programmatic login, Spring Security, whatever the developer wanted. Incidentally, I've done this. In real code. You can also find examples of a log in component in Schalk and Burns' book, if you don't believe me. Doubt less.
    I've done this too (please, scroll down to see in-page component). With plain JSP, mind you. Granted, my login component is not 100% reusable, but it IS a real drop-in component made with good old -- or as some would think, with bad old -- JSP. Two states: "logged in" and "not logged in", two views: "log in" and "log out". Does not require Javascript to work properly, but if Javascript is enabled, then the component is updated in-place (read: Ajax). Try turning Javascript on and off without page reload and see whether this component breaks, it will not. By the way, notice that the URL does not change too, so even with Javascript turned off you still stay on the same logical page, therefore you need only one click of Back button to leave this page. The points I wanted to make: (1) one does not need a completely different framework to create components, (2) JSP is not that bad as some think if you use it creatively.
    How do you tackle problems like: * Different login form and error message layout * New functionality such as (forgot password and/or forgot username) * Remember me * Customizing the label and message text for all of the different elements of your login form * Combining login with "register new" functionality * Different elements of complexity to wire up the various authentication backends to all of the above wrinkles.
    If you were programming with .NET you would not have asked these questions ;-) And by the way, .NET 2.0 has login component, signup wizard, and many other reusable components with only minor possibility to change look&feel, and .NET depelopers don't mind. Obviously, if you want total customization, writing your own component may be easier. But most users don't care how a login form looks like, as well as most developers. You can have a fair degree of customization in a reusable component. When I started the JSP Controls Tag Library project, I was not attempting to design fully reusable components, instead I preferred to have a simple and quick way to modify the functionality and look&feel of the components. This is -- you get it -- by using JSP itself. Why would I want to, say, configure a component with something like XML config file, if I can go directly into JSP file and change what I needed, and then just reload a page? The beauty of plain JSP application is that you do not need to recompile the whole app and redeploy it. All you need is just reload a page. JSP components are by design distributed as JSP files, all functionality and markup is there. Don't like the look -- dig in and change it. Yes, it might not qualify as fully reusable components, instead I think of them as customizable templates, and I don't think that fully reusable components with huge separate config files would be a better solution. But when it comes to usage of JSP components, they are real drop-ins with standard action. P.S. For those interested in plain and simple JSP components: new version of JSP Controls library will be released soon, with drastically reduced session usage.
  69. This is -- you get it -- by using JSP itself. Why would I want to, say, configure a component with something like XML config file, if I can go directly into JSP file and change what I needed, and then just reload a page? The beauty of plain JSP application is that you do not need to recompile the whole app and redeploy it. All you need is just reload a page.
    I think we're making similar points. I think people go crazy thinking that in order to get something done with JSF you have to create components. I believe nothing could be further from the truth. Using plain old JSF and the plain old built in components that come with JSF you can wire together these types of features in a snap. I think people way over use JSF components and don't use plain old JSF enough. Like I said in a later post it is perfectly fine to create a login components if you don't have any over the top expectations regarding reuse and customization. I got the impression though from the article that these types of feature type of components would "save" JSF. And I can tell you in my organization where time and money are more flexible than functionality and look and feel an off the shelf login component or forum component would never fly.
  70. If you were programming with .NET you would not have asked these questions ;-) And by the way, .NET 2.0 has login component, signup wizard, and many other reusable components with only minor possibility to change look&feel, and .NET depelopers don't mind.
    Well I made the experience that in the Microsoft centric world people usually are less verbose (and also less in the mood to try to reinvent the wheel 100 times) they often are happy in what Microsoft delivers or if not, they are used to not looking outside the box because Microsoft is the enforced solution and there is nothing better than the stuff from Microsoft, or Microsoft invented everything and nothinbg else exists. Example: one word MFC, there were way better solutions out there in the wild (Borland, StarView) when Microsoft came with this utter garbage, yet it was used almost 12 years until with .Net the next fade came (MFC back then was positioned against Borland which hat a huge inroad with their really good OWL and .Net we know the story of a failed java takeover). Another one is Visual Sourcsafe... no companies and developers were not dropping this tool en masses, no matter how many times the repository was locked corrupted or made unusable, I was amazed recently that one of those guys still was using it after 10 years of being burned with it. I asked him why, he said, well it is from Microsoft... I am not so sure if people really are happy with the way meta components are, the first JSF rollout I did was a rather simple app, the first critque I heard was that the corporate design was not integrated good enough. Also one of the major hurdles the Studio Creator and the Visual Webpack really have is that the design of the rather complex components is fixed (yes those tools which are very similar in scope as the VStudio.Net webforms have such components) If you roll such Meta components, no matter being it facelet components or Creator compound components you really limit yourself to a certain degree to a fixed design which then often is not accepted, especially if the component is provided by a third party provider!
  71. If you were programming with .NET you would not have asked these questions ;-) And by the way, .NET 2.0 has login component, signup wizard, and many other reusable components with only minor possibility to change look&feel, and .NET depelopers don't mind.
    True, ASP.NET has high level components for login, user registration, password recovery/reminder, login state etc. etc. They are part of a new breed of coarse-grained components of ASP.NET 2.0. Microsoft calls them application services, I call them vertical components because they implement the user interface, the presentation logic, business logic and provides a persistent store. Other vertical components are site structure (controls for menus, breadcrumbs, sitemaps integrated with a sitemap description), authorization/authentication, user profiles, web parts (portlets) etc etc. I use this stuff every day. And I am here to tell you that they can be customized in (almost) any way I want. Usually I will just do with setting some properties to change legends, styles, css class etc. But if I want to take it further I implement my own templates (overriding the default ones), at which point I can control every single aspect of the user experience. And they still work with the backend providers. Until I switch the provider out, that is. Then they work with my provider amd store. I will admit that I was very sceptic when I first heard of this. Like many in this thread I simply could not imagine how it could be in a sufficiently flexible manner. I encourage anyone who doesn't "get" this call for coarser grained components to take a look at ASP.NET membership controls (and -providers) and navigational controls and -providers. Case in point: When I start out, the master page will have a login box like this: That's it. No code. I have login with username, password, "remember me", validation etc. On every page. From there I customize it to look and feel the way I want. I usually end up taking over the template (the built-in one looks kind of okay, but it is a horrible mess of a table based layout. Muahahaha.)
  72. Re: This is an idiotic article[ Go to top ]

    A reusable generic login component? Are you kidding me? Components need to be fine grained in order to be reusable and customizable. People need to realize the JSF expects it's developers to be users of components and not creators of them.
    Hi Mike. :) I dunno. I've talked to Joe quite about this on IRC, and I can kinda see his point. Take a blog component, for example. You specify where to get the data (which returns either a Collection of a certain class or interface), it spits out the title, summary, link, etc., and the app uses CSS to make it look right for that app. I can see the value in that, but I don't which is more work: using several UIComponents to make that happen, or just one plus a bunch of CSS (+ JS?)? I'm not sure, but I don't think the idea is completely without at least some merit.
  73. Re: This is an idiotic article[ Go to top ]



    Hi Mike. :) I dunno. I've talked to Joe quite about this on IRC, and I can kinda see his point. Take a blog component, for example. You specify where to get the data (which returns either a Collection of a certain class or interface), it spits out the title, summary, link, etc., and the app uses CSS to make it look right for that app. I can see the value in that, but I don't which is more work: using several UIComponents to make that happen, or just one plus a bunch of CSS (+ JS?)? I'm not sure, but I don't think the idea is completely without at least some merit.
    Hey Jason. :) Obviously one plus a bunch of CSS (+ JS?) is going to be easier if it fulfills all of the requirements for a blog in a way acceptable to your designers. Perhaps it is just my application space but that would never be the case with my designers and my business unit. I believe that instead of creating one large blog component you should look at what makes a blog complicated to implement and attempt to break those complex parts out into finer grained components that can be wired together. This provides a standard level of customizability inherently provided by JSF. These components can then be combined in a default way using something like a Facelets Composite component. What you end up with is a more customizable set of components that are still fairly easy to use in a default way. We'll have to talk more about component creation theory on IRC. :) Mike
  74. yeah[ Go to top ]

    so do it an stop boring us
  75. - JSF life cycle is unnecessarily complicated. Why should something like immediate="true" be necessary in a well-designed framework? - JSF's internal component view model state makes it very easy to produce subtle bugs where the stale component model view overwrites freshly updated backing bean values. There is no easy and natural way to tell JSF to "refresh" a page -- all interactions are treated as submits. The hacks necessary to work around this limitation for plain JSF (RI and myfaces) are ugly and bug-prone. - Custom components are insanely difficult to implement without Guru-level knowledge of JSF. This is an arbitrary and artificial limitation. It doesn't have to be like this. - JSF multi-rendering capability -- it's an API bloat the weight of which you feel when designing custom components. Whether a project will benefit from multi-rendering or not is questionable. Why should I pay the price in terms of conceptual complexity of an API when I may not even need to use it in 99.9% of the use cases? If I am going to render into PDF, should I bolt the rendering onto the JSF or should I write something that works with domain beans directly? After all, I almost never want merely PDF-ied web pages, but rather I want reports that look nothing at all like any of the original web pages. So if I won't be using multi-rendering for PDF and I won't be using it for any other report format, then why do I care? WAP? The real selling point of multi-rendering is very weak in my opinion, but it sure has that nice "PowerPoint bullet buzz" feeling going, doesn't it? - JSP, in and of itself, is trash. This has been known and widely agreed upon since about year 2000. Sun had 7 years to dump it, but why haven't they? Backward compatibility is not the answer for something as broken and as damaging as JSP. - JSP is arguably the most widely used rendering mechanism for JSF. JSP is a terrible match for JSF: notice the ugly tag for example. - It's very hard to apply CSS styles to some components (for example tabbed panel in tomahawk) - Error reporting and logging is a second class citizen in at least one of the most widely used free implementations of JSF: myfaces. It's probably not much better elsewhere. A JSF error should have all the information to resolve the problem within 10 minutes. There is absolutely no reason why this cannot be achieved other than neglect, stupidity or laziness on the part of JSF developers. Take a look at this: Dec 5, 2006 3:53:14 PM org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlTableRendererBase encodeInnerHtml SEVERE: Row is not available. Rowindex = 0 What table? I have many. What particular jsp? What is expected? What is the suggested fix? What line number did it occur at? Do I really need to see this in my log: org.apache.myfaces.shared_tomahawk.renderkit.html.? Does it add any useful information? I already know I use apache tomahawk, thank you very much. When row was not available, what was the state of the backing bean? - If you forget to add or equivalent to your web page, you can get silent and (for that reason) very hard to fix errors. An exception in getter is not reported in the log file by myfaces (and possibly others too). - JSF's API is too verbose. For example why do I have to write this: FacesContext context = FacesContext.getCurrentInstance(); ValueBinding binding = context.getApplication().createValueBinding("#{" + name + "}"); Bean bean = (Bean) binding.getValue(context) just to fetch a bean? Yes, I can (and did) write a utility class to do this, but it does smack of indifference and carelessness by the JSF people. A common answer to this is to suggest using faces-config.xml mechanism of dependency injection. Unfortunately faces-config.xml is not powerful enough to handle cyclic bean references (which can be handy to have, or otherwise, which you'd have to consciously avoid early in design phase). - JSF until only very recently has relied on a lot of magic Javascript. That's a big minus in my book. It's fine to use some Javascript for page rendering, but it should be well documented and not have any "magic" nature to it. - I hated ajax4jsf when I tried it. I got a response time on a very simple request of 1.5 to 2.5 seconds. When I switched to a Prototype based solution plus a simple custom servlet, response time went down to 15-35 milliseconds. I know which solution is simpler and faster. With Prototype, I actually understand the entire flow and can debug any part of it, if necessary. The internals of ajax4jsf, on the other hand, are so complex, there is simply no way to understand them in a reasonable amount of time. When I complained about these issues, I got the following answers, which I believe only help to further illustrate the problem: - use facelets instead of JSP - don't use RI or myfaces, instead use ADF or Seam - use Spring to make JSF tolerable - stop complaining about JSF, because JSF is only a spec -- it's not a framework
  76. Leo, Great post! I never found the motivation to list JSF's problems (because either it falls in the hands of fanatics that come back with stupied answers, or "reasonable people" that tell you that the EG is aware of the problems and working on them), but my list would have probably had 95% overlap with yours ;) Best, Boris
  77. - JSF multi-rendering capability -- it's an API bloat the weight of which you feel when designing custom components. Whether a project will benefit from multi-rendering or not is questionable. Why should I pay the price in terms of conceptual complexity of an API when I may not even need to use it in 99.9% of the use cases?
    I hear this a lot, and it's usually from people who haven't written many components (no clue if you have or not :). If you don't want a separate Render, just override decode() and encode*() in your UIComponent, and you're done. It's just like the other class isn't even there! :P
    - JSP, in and of itself, is trash. This has been known and widely agreed upon since about year 2000. Sun had 7 years to dump it, but why haven't they? Backward compatibility is not the answer for something as broken and as damaging as JSP.
    Not many will argue that point. See JSFTemplating or Facelets. Problem solved.
    - It's very hard to apply CSS styles to some components (for example tabbed panel in tomahawk)
    That sounds more like a component problem than a spec problem to me. It doesn't seem that other tab sets have that issue...
    - Error reporting and logging is a second class citizen in at least one of the most widely used free implementations of JSF: myfaces. It's probably not much better elsewhere.
    While I can't speak for MyFaces, the RI has gotten a lot of work in that area for the upcoming release (note: I'm an RI dev -- though Ryan Lubke has done all the work on that change). That being said, though, you're faulting the spec for one impl's shortcomings. Doesn't seem real fair. Or honest.
    An exception in getter is not reported in the log file by myfaces (and possibly others too).
    See above.
    - JSF until only very recently has relied on a lot of magic Javascript. That's a big minus in my book. It's fine to use some Javascript for page rendering, but it should be well documented and not have any "magic" nature to it.
    So...it used to do something you didn't like, and now it doesn't, but you still hate it for doing that. Nice.
    - I hated ajax4jsf when I tried it.
    So you hate a component library. How is that JSF's fault?
    - use facelets instead of JSP
    Perfectly valid advice.
    don't use RI or myfaces, instead use ADF or Seam
    It seems someone doesn't know what he's talking about if he's giving (or accepting) that advice. Neither Seam nor ADF are implementations. One is a framework built on top of the JSF spec (and can use either impl, though they're suggesting the RI right now afaik), and the other is a component set that will need either aforementioned implemenation or some undisclosed third impl.
    - use Spring to make JSF tolerable
    I've used JSF for over two years. I don't use Spring (though I don't mind it), but I fail to see how Spring would make JSF "tolerable."
    - stop complaining about JSF, because JSF is only a spec -- it's not a framework
    Well, that's somewhat valid. In fact, it seems most of your complaints have been about on particular implementation (of an old version of that spec at that!), and you've just assumed other impls have the same problems. Having said that, I think everyone involved with JSF realizes the spec isn't perfect, which is why the 2.0 JSR will be filed Real Soon Now. If you have valid concerns, head over to the spec site and file a bug, and someone will get on it as soon as the EG spins up completely.
  78. Jason, You surely can anwser every single problem by pointing to some solution somewhere, either existing or hopefully coming up if the EGs graces the problem with their attention. The bottom line is: the overall experience if many people (at least the ones that don't assume that because this is being pushed as a standard by the big guys etc. it must be good) is a big disappointment and constant frustration. There are essentially two implementation: the RI and MyFaces. Not sure about the latest update, but the RI was full of bugs for years and many recommended MyFaces which is written (it seems to me) mostly by exuberent youth and it's full of problems as well. They are getting fixed, sure...but it's been years and years. In the meantime Sun could try to balance the budget b/w marketing and getting the technology right perhaps a bit more in favor of the latter: having a good, well-thought out product is good marketing also ;) This is a spec and a standard, all right, but it's not the 10 commandments. The EG doesn't need to pontificate for 2 years each time around in order to come up with a new interface or a new mechanism, or address some problem. This is just to catch up with what others are already doing. Have you noticed that the discussion here is mostly not about whether JSF is quality stuff or not, but about trying to understand what makes it so bad given it is based on sound principles and it's the fruit of many years of work by experts in the field? How come? Best, Boris
  79. The bottom line is: the overall experience if many people (at least the ones that don't assume that because this is being pushed as a standard by the big guys etc. it must be good) is a big disappointment and constant frustration.
    And the inverse is true, as well: many people find it to be a great framework. I'm one of those people, having put food on the table with it for over two years now.
    There are essentially two implementation: the RI and MyFaces. Not sure about the latest update, but the RI was full of bugs for years...
    I can't really say for the 1.1 RI, but the 1.2 impl is extremely stable, as that's what I've been using (and working on) since it came out. It keeps getting better and faster with each release. Is it perfect? No, but it's not the steaming pile you think it is. You should try it out, then you can complain with a bit of authority. ;) jason
  80. The bottom line is: the overall experience if many people (at least the ones that don't assume that because this is being pushed as a standard by the big guys etc. it must be good) is a big disappointment and constant frustration.


    And the inverse is true, as well: many people find it to be a great framework. I'm one of those people, having put food on the table with it for over two years now.

    There are essentially two implementation: the RI and MyFaces. Not sure about the latest update, but the RI was full of bugs for years...


    I can't really say for the 1.1 RI, but the 1.2 impl is extremely stable, as that's what I've been using (and working on) since it came out. It keeps getting better and faster with each release. Is it perfect? No, but it's not the steaming pile you think it is. You should try it out, then you can complain with a bit of authority. ;)

    jason
    I don't aspire to have any sort of authority in the business of complaints. The point of my posts here is mostly sharing bad experience with others (why should we only congratulate and share the good experiences?). As a bonus, a little bit of scepticism in the face Sun's evangelizing machine couldn't hurt. Everything can be criticized and no design, no implementation is perfect. But JSF is _really_ screwed up. I just hope that it's not irreparable because this translates into turning people's jobs into nightmares (being a programmer, I care about the likes of me). Have fun making the RI "perfect". Incidently, as a developer of JSF, your opinion as its user is irrelevant. Best, Boris
  81. As a bonus, a little bit of scepticism in the face Sun's evangelizing machine couldn't hurt. Everything can be criticized and no design, no implementation is perfect. But JSF is _really_ screwed up. I just hope that it's not irreparable because this translates into turning people's jobs into nightmares (being a programmer, I care about the likes of me).

    Have fun making the RI "perfect". Incidently, as a developer of JSF, your opinion as its user is irrelevant.

    Best,
    Boris
    Ah can I sum it up in other words, years ago, you had a bad experience with a very early RI, since then you refused to look at it, years later with lots of progress in between you still rant about your experiences as being exactly the ones you had years ago, while others tell you they are happy ;-) I sort of have a deja VU... The same was about 5 years ago with java who never touched java after 1997 ;-)
  82. I don't aspire to have any sort of authority in the business of complaints. The point of my posts here is mostly sharing bad experience with others (why should we only congratulate and share the good experiences?). As a bonus, a little bit of scepticism in the face Sun's evangelizing machine couldn't hurt. Everything can be criticized and no design, no implementation is perfect. But JSF is _really_ screwed up. I just hope that it's not irreparable because this translates into turning people's jobs into nightmares (being a programmer, I care about the likes of me).
    I don't mind the skepticism or criticism. Without it, we don't really know what's wrong and where to go. It just seems to me, as another poster pointed, you seem to have used a long time, haven't touched it since, and come here complaining about it, which isn't even remotely fair or honest. I could be wrong, but that's the impression I get from your posts (though I really don't care to argue that point, fwiw. :)
    Have fun making the RI "perfect". Incidently, as a developer of JSF, your opinion as its user is irrelevant.
    I think you're dead wrong there. I became a committer on the RI *after* I had used for it over a year. I had real world experience in building enterprise applications in JSF before I began working on the RI, and continued to build such apps after I was given commit privileges. Given that, I think I'm in a pretty good position to speak from both perspectives. And the RI will never be perfect; nothing ever will. But will it keep getting better? Sure. Is it "good enough" to get real work done? Absolutely.
  83. Ok to the original comments: a) Verbatim is not needed anymore since JSF 1.2, facelets dont either. b) ADF is only a component pack and additional framework, there still is the RI and MyFaces, and both do not have too many bugs anymore (Cannot speak for the 1.2 incarnations though) c) Lifecycle and component creation too complicated, I agree, for the lifecycles I really can recommend shale, it has a saner approach d) Magic javascript, only really on one area, commandLinks, they have to use it due to inherent html limitations, nothing else of magic javascript is in the specs. You can bypass this magic javascript simply by using commandButtons The other magic is not spec related and only has the meaning of doing non spec stuff in a way that users dont have to touch javascript at all.
  84. JSP is trash?[ Go to top ]

    JSP, in and of itself, is trash. This has been known and widely agreed upon since about year 2000. Sun had 7 years to dump it, but why haven't they? Backward compatibility is not the answer for something as broken and as damaging as JSP.
    I suppose you are still using JSP 1.0 .
  85. JSP, in and of itself, is trash. This has been known and widely agreed upon since about year 2000. Sun had 7 years to dump it, but why haven't they? Backward compatibility is not the answer for something as broken and as damaging as JSP.

    I suppose you are still using JSP 1.0 .
    I'm using 2.0.
  86. So... where are the login box components? Where are the search box components? Where are the data input components?
    Login is just a use case in some scenarios that may not apply to all. If you need to include all these use cases into components, I wonder how big the library would be, think about the following: 1. Post Comment 2. Create Thread 3. Reply Thread 4. Search Thread Are you going to have all these as components in JSF? What's the point of having OO programming when you create Use Case as object directly?! Weird post and should be deleted.
  87. Problems with JSF[ Go to top ]

    Actually, for me, the problems with JSF may well stem from the fact that it's a standard. The beauty of being a standard is that there can be a lot of implementations for it. The dark side of being a standard is that there can be a lot of implementation for it. When looking to start with JSF, there are a LOT of choices. But there doesn't seem to be a clear de facto implementation. Some of JSF 1.1, other JSF 1.2. There's the vendors and open implementations. And they all vary in quality, documentation, etc. as multiple implementations are wont to do. So then you hear about the cross implementation issues. How it works in X but not in Y, and other such bugs. It's was never clear that when folks were talking about JSF, whether they were having problems with JSF the spec, or some specific implementation. Perhaps if I spent more time in the world, I could separate the wheat from the chaff. But as an outsider looking in, it's a maelstrom of confusion. I also tried things like Java Studio Creator, as well as working with books like Core JSF. I figured using JSC, it would whip up some boiler plate, and then I could use something like Core JSF to explain what came out. But JSC uses a different philosophy on page and bean design than the hand coded examples from the books. In JSC, the actual controls are part of the backing bean, whereas for most simple JSF, you have the values in the backing bean. If you're a Swing code, the JSC method makes sense. If you're a Struts coder, the book examples makes sense. The fact that JSF can do both perhaps shows off some untapped power. But as a novice this is quite confusing. Just figuring out that bit of the lifecycle took a lot of head scratching. I was able to make OK progress on my test application up until I needed to create dynamic controls on the form. At that point I gave up. At that point, the bulk of the complexities of JSF and its 8 stage lifecycle rear their ugly heads. I just tucked my tail and ran back to Stripes. I do agree, in some sense, with the overall theme of the article though. I think Microsoft does a spectacular job of advocating .NET through not just its components, but by the several complete, usable, and non-trivial sample applications they have on the framework. The apps aren't best of breed, but they're not 2 line "Blogger on Rails in one minute" applications either. It's not that the base components are horrid, but when "that's all you got", having some decent examples of "what can you do with them" is very helpful. Many applications are variances on a theme. If Sun published a simple distribution system (inventory, order entry, simple reports), with Header/Detail CRUD screens, security, reasonable navigation and a nice, conservative L&F, a gazillion back office developers would suck that up and beat it in to what their tables look like. All of a sudden JSF becomes a de facto implementation. Why? Because folks don't want just components. Most folks aren't picky and pedantic about design (just the folks who post here). If someone published an 80+% solution, developers would use it. Back office applications simply aren't that different for a majority of the cases. But, as mentioned, we get an INPUT box and a gazillion pages of detailed lifecycle documentation, rather than "real" examples of the stuff being used in anger.
  88. I am currently developing a Web application using MyFaces. When I started learning JSF, it seemed to me powerful and easy to understand. But as soon as I got into the details I realized that JSF is not enough to give the user the rich client experience. So, I started adding ajax4jsf into my code which allowed me to have some ajax functionality that I needed to update the DOM dynamically. But what about the user experience! To give user a cool look and feel you start adding some existing JavaScript libraries like prototype, x libraries and so on. After a while you just realize that nobody have thought about the maintenance of the code. At some point you have pell-mell code. Just fading out the existence of JavaScript and starting to invent everything again is wrong. On the server side, everybody is already talking about integration frameworks. Sun should think about integrating the existing technology like JavaScript/Ajax and JSP instead going and developing a new language like Java FX which doesn’t give any surplus value.
  89. Both are bloated technologies … Always there where better solutions like template based renderers like Freemarker or Velocity combined with Apache ECS, JSP+Custom Tags based on template rendering and widget api – ECS.
  90. Both are bloated technologies … Always there where better solutions like template
    based renderers like Freemarker or Velocity combined with Apache ECS, JSP+Custom Tags based on template rendering and widget api – ECS.
    Agreed - .Net is growing while Java is stuck with an overcomplexity learning curve that only big shops can afford to climb. For a further discussion of this viewpoint that JSP is too difficult for page designers to use see - http://www.jotobjects.com/JOTlinksaboutjsp.html JSF compounds the JSP over engineering problem that mixes the view (markup) and the model/controller (object). The JOT Servlets framework combines a template renderer (as in Freemarker, Velocity, etc.) with a pure Java component framework that separates the two domains.
  91. Both are bloated technologies … Always there where better solutions like template
    based renderers like Freemarker or Velocity combined with Apache ECS, JSP+Custom Tags based on template rendering and widget api – ECS.


    Agreed - .Net is growing while Java is stuck with an overcomplexity learning curve that only big shops can afford to climb.
    Not really, there are several reasons why .Net has caught on, the most important one, it is from Microsoft, they can bring out anything and hordes of Microsoft solution providers will jump onto the ship. The quality does not matter. Second they usually have a visual toolchain, not too many frameworks in the javaworld have that, currently I can only see JSP, Struts (one of the reasons why Struts is there where it is), Webobjects, and JSF. And JSF is the only one which has several pure visual solutions like .Net has one for html forms. Third, there usually is only one way, not hundreds of people trying to push the next framework because it is cool or they had a nieche problem. Here is my point
    For a further discussion of this viewpoint that JSP is too difficult for page designers to use see - http://www.jotobjects.com/JOTlinksaboutjsp.html

    JSF compounds the JSP over engineering problem that mixes the view (markup) and the model/controller (object).

    The JOT Servlets framework combines a template renderer (as in Freemarker, Velocity, etc.) with a pure Java component framework that separates the two domains.
    in the .Net world there is only one way the Microsoft way, period, Where do you want to go today, it does not matter I will push you in my direction ;-) Like it or not, but that is the Microsoft way and lots of people have been burned by having to drop a lot of legacy codebase every few years (the last ones who got burned were the ASP/VB shops with their enforced shift towards VB.Net and ASP.Net ;-)
  92. Like it or not, but that is the Microsoft way and lots of people have been burned by having to drop a lot of legacy codebase every few years (the last ones who got burned were the ASP/VB shops with their enforced shift towards VB.Net and ASP.Net ;-)
    I've experienced changes that caused me pain between versions of .Net/VS.Net. I think the problem is that with one solution other problems present themselves. For example - Partial Classes. I think they are a pain. I have to got to another file to find things. There are more, but can't remember off the top of my head. The same issue occurs if you pull the gui layout for Swing out of Java. And doing it in another language compounds the problem. Are there advantages? Sure. If people would quit thinking forms and pages, it would help a whole lot. Of course, I am thinking about application UIs not websites.
  93. Both are bloated technologies … Always there where better solutions like template
    based renderers like Freemarker or Velocity combined with Apache ECS, JSP+Custom Tags based on template rendering and widget api – ECS.


    Agreed - .Net is growing while Java is stuck with an overcomplexity learning curve that only big shops can afford to climb.


    Not really, there are several reasons why .Net has caught on, the most important one, it is from Microsoft, they can bring out anything and hordes of Microsoft solution providers will jump onto the ship. The quality does not matter.
    Same old utterances of gibberish. "The quality does not matter"... just like EJB and now JSF? How many jumped on the EJB 1.0 and 2.0 bandwagon? Look how confident is the committer of JSF in this thread. To paraphrase him: JSF 1.1 was buggy. JSF 1.2 is "good enough".
  94. Look how confident is the committer of JSF in this thread. To paraphrase him: JSF 1.1 was buggy. JSF 1.2 is "good enough".
    And do you know why I'm so confident? Because I write real world applications using the technology. I didn't get burned by an old release (yes, I used 1.1) and run away from it, only to show back up and recycle years old arguments about how awful it is. I've used it every day for over two years solving real problems. Is it perfect? By no means. I am, though, able to work around what little problems are there, and the framework makes sense to me and how I like to build applications. Others prefer more "Java-centric" solutions like Wicket, and that's fine. For me, JSF works, and, yes, it's "good enough" for me to get the job done. Does it need improvement? Certainly. That's what the 2.0 JSR is for. Not that anything has changed, but it's blindingly obvious that there's little real discussion to be had here, so I'm going to check out. If you'd like, go on hating JSF and using whatever you'd like. That's fine, really, as choice makes all the options better. This thread, though, has deteriorated into completely nonsense... :|
  95. Agreed - .Net is growing while Java is stuck with an overcomplexity learning curve that only big shops can afford to climb.
    All I can say is that my experience does not agree. Firstly, I have been following Java and .NET market growth for years, and there is no sign of a decline in Java growth; certainly not at the expense of .NET. Secondly, I am part of a very small 'shop' - 2 developers. We have not found any supposed complexity of Java to be a barrier to its use. Incidentally we have been using JSF productively for years.
  96. Agreed - .Net is growing while Java is stuck with an overcomplexity learning curve that only big shops can afford to climb.


    All I can say is that my experience does not agree. Firstly, I have been following Java and .NET market growth for years, and there is no sign of a decline in Java growth; certainly not at the expense of .NET.

    Secondly, I am part of a very small 'shop' - 2 developers. We have not found any supposed complexity of Java to be a barrier to its use. Incidentally we have been using JSF productively for years.
    I personally would say the learning curve by now is pretty equal. Java has a good set of visual tools in place and .Net basically forces you towards VStudio. The frameworks themselves are not so far off. JSF and HTML forms are more similar than different. People in here most of the times (and also framework promotors who the original post was derived from) tend to forget that in the .Net centric world everything is done around the tools, with the downside of locking you in to a certain degree (do something outside the box and you will bang your head), Java has a similar set of tools in place, but people tend to handcode more here.
  97. Spring Webflow[ Go to top ]

    For me, the actual technology used to create the page isn't so important. We've recently switched to building *all* of our pages with Spring Webflow, even CRUD pages. Its the ability to script together pages with such amazing ease that is our most recent 'great leap forward'. e.g. having a 'find' page, or an 'add new contact' page which can be called by a number of use-case implementations. Spring Webflow also provides various scopes above and beyond request and session, e.g. flow and conversation. Seam also provides this I believe, although not quite sure (or want to argue) which came first.
  98. JSF is dead end[ Go to top ]

    JSF+Ajax looks like a patch to a decade-old technology. If you prefer the client/server way, prototype+scriptaculous or yahoo ui is much better way. If you prefer thin-client, ZK or thinwire is much better option.
  99. Too late, too complicated[ Go to top ]

    I see various major drawbacks in JSF. First it came out much too late. The time from announcement to release was just too long and the first specification release was a total desaster. A lot of people - including myself - simply lost faith. That does not mean that it might not turn out good in the end. It simply means that people went off in a different direction and the harder it is to change. Take Struts as an example - there is so much Struts around in long living applications that it will stay around for at least the next ten years, like it or not. Or consider NetBeans that has turned out a wonderful and arguably the best environment for Java Development but that will probably never be able to oust Eclipse as the leading environment. Second, JSF, for what it does, is way too complicated and overengineered. From the beginning I thought it a weired idea to design it without a defined templating language. Even JSP would have been better than no language at all. Also, it is nowhere built around RAD development style which I found smelly from the very beginning. I still think it should be possible to create a workable prototype without ever leaving the JSP/Templating realm. The component lifecycle paradigm is much to complex as well and could have been eased of by simply looking at existing solutions, also in the non-Web world. Third of course, components. There is no denying that by the time JSF was created it was crystal clear that a number of components was needed for a descent website including such esoteric components like calendar, table, tree. Fourth, integration with major development frameworks like various portal products was a foreseeable problem. While possible, it requires a fair amount of work a very clear understanding of how JSF and whatever your framework is work under the hood. This makes it near impossible to integrate any non trivial JSF application into a non trivial portal (and into other frameworks).
  100. The solution[ Go to top ]

    I hear the fustration the author conveys in the article, but we all have to recognize that JSF is the next generation when it comes to server side MVC frameworks. Someone mention we first had JSP/Servlets, and then Struts, and now JSF. I could mention Spring MVC, Tapestry, and others but the list would be too long. The lack of component in the reference implementation of JSF it to be expected. To me the reference implementation of JSF is doing its job, providing the basic foundation that is scalable and robust via the component and lifecycle features. As far as not being able to find more advance topics in the books, well most book when a new technology comes out will be basic explain the technology at a beginning level. I my self like the JSF in Action book as it gives good detail examples for beginner and advanced developers. If you really want a more advance book on JSF, you should try Pro JSF and AJAX. So you see you can find documentation on advance JSF stuff, but like most programming languages books the example are from book to book are redundant as mention in the article. I really don't like having to learn a framework evertime something new comes out. Like I mention earlier we have progressed from JSP/Servlets, to Struts, to Spring MVC, to Ruby on Rails, to Tapestry, to ASP, to .Net, to JSF. I am sure I missed a serveral others; but my point is with most of the MVC frameworks comes new tags to render the presentation layer. As a developer (not a JSP/Servlet Developer, Struts Developer, JSF Developer), I don't want to have to keep learning new tags to use a Server Side MVC Framework. Assuming you are building web applications, would it be nice to only rely on the standard languages that are native to the browser (HTML, XHTML, CSS, and JavaScript). With the use of 100% of AJAX this is possible. I am using the standard languages (HTML, XHTML, CSS, and JavaScript) along with AJAX (See AJAX in Action), WebServices, and JSF to eliminate JSP and other custom tags from the presentation layer and relying more on JavaScript to render UI components while taking advantage of JSF and its lifecycle to provide me with infustructure. If all of us developers come together and develop like such we can loose all the prefix to the title developer and just use Web Developer when it come to the presentation developer and which ever MVC framework that is used on the server will not have any constraints or limitation on the presentation layer.
  101. we have to?[ Go to top ]

    we all have to recognize that JSF is the next generation when it comes to server side MVC frameworks
    You're kidding, right? And people wonder why the Struts is a market success...
  102. about JSP[ Go to top ]

    Interesting: PHP is getting more and more popular. But in the same time JSP (you can use it by PHP manner too) is a main source of problems for JSF as I read here many times. How it is possible? Maybe something is wrong at the basement?
  103. Re: about JSP[ Go to top ]

    Interesting: PHP is getting more and more popular. But in the same time JSP (you can use it by PHP manner too) is a main source of problems for JSF as I read here many times. How it is possible? Maybe something is wrong at the basement?
    PHP is the solution of choice for relaying mysql errors to web users.
  104. Re: about JSP[ Go to top ]

    Interesting: PHP is getting more and more popular. But in the same time JSP (you can use it by PHP manner too) is a main source of problems for JSF as I read here many times. How it is possible? Maybe something is wrong at the basement?


    PHP is the solution of choice for relaying mysql errors to web users.
    Too funny. :)
  105. Re: about JSP[ Go to top ]

    PHP is the solution of choice for relaying mysql errors to web users.
    Great :-) And ASP.NET does the same for SQL Server?
  106. Re: about JSP[ Go to top ]

    PHP is the solution of choice for relaying mysql errors to web users.
    You might enjoy a YouTube video about PHP that was broadcast at RailsConf last week. Their jab at Java was also right on the mark :-) Craig McClanahan
  107. Re: about JSP[ Go to top ]

    PHP is the solution of choice for relaying mysql errors to web users.


    You might enjoy a YouTube video about PHP that was broadcast at RailsConf last week. Their jab at Java was also right on the mark :-)

    Craig McClanahan
    What is this XML you speak of? I'm using Wicket and I don't really see any... It's a joke! Yes, I have a web.xml and yes I have a spring config. On the other hand, the app scales well unlike some apps/frameworks I might mention.
  108. Re: about JSP[ Go to top ]

    Interesting: PHP is getting more and more popular. But in the same time JSP (you can use it by PHP manner too) is a main source of problems for JSF as I read here many times. How it is possible? Maybe something is wrong at the basement?
    No, just one word... hype... I have to deal with PHP a lot, and there is so much wrong in the php foundation it is not funny anymore (most of it legacy stuff up to php4) There are very good scripting language based solutions, but php is definitely not one of them. PHP always was popular, because it allowed easy hacks was directly connected to mysql (which became popular despite its quality for the same reasons) and was the cheap rollout platform of choice for webhosters. There is defintely not a you can cover everything with one approach solution, jsp and php are viable choices for small web applications, they are dirty but allow a quick turnaround without too many layers in between. The main problem is that once things are getting bigger those solutions still are adaptable but they then start to show their ugly face. The same goes for webframeworks, there is a reason why we see so many of them, because all of them fill a certain nieche.
  109. Re: about JSP[ Go to top ]

    Interesting: PHP is getting more and more popular. But in the same time JSP (you can use it by PHP manner too) is a main source of problems for JSF as I read here many times. How it is possible? Maybe something is wrong at the basement?


    No, just one word... hype...
    That and the fact that it's easy for kids to pick up (whether they are or want to be 'real' programmers or not), which in turn probably is because there's so much information for it and it is so easy to get it hosted.
    The same goes for webframeworks, there is a reason why we see so many of them, because all of them fill a certain nieche.
    I think it is fine to have a couple of different choices that fill in different needs. But if JSF (which after all is the proposed standard) would have been better, at least we would have been able to throw out the model 2 (Struts, SpringMVC, etc) frameworks. Hopefully, that'll happen in the second round ;)
  110. Re: about JSP[ Go to top ]

    >
    I think it is fine to have a couple of different choices that fill in different needs. But if JSF (which after all is the proposed standard) would have been better, at least we would have been able to throw out the model 2 (Struts, SpringMVC, etc) frameworks. Hopefully, that'll happen in the second round ;)
    Like it or not model two frameworks are there to stay. They exist for a reason, why the web follows this semantic to some degree and exposes a total anit pattern once it comes to interactive user interfaces. Component frameworks while being the natural way to really program user interfaces (the design of this in a oo way goes way back to the mid 70s where the groundwork was laid in smalltalk) are harder to put on top of the broken html protocol, cause more burden on the server and in case of rich client uis also on the browser and add a bunch of other problems like state saving etc... Add to that the problem that hundreds of thousands of people basically were forced into learning a user interface design anti pattern and having to apply that to 10 years in and out. Unlearning this will be a hard and long task. It is even hard to tell those people what an event is and how it fits into the big picutre, most of them think, one event (the action) does it all.
  111. Re: about JSP[ Go to top ]

    Interesting: PHP is getting more and more popular. But in the same time JSP (you can use it by PHP manner too) is a main source of problems for JSF as I read here many times. How it is possible? Maybe something is wrong at the basement?
    JSP sucks because it is based on a one phase model instead of distinguishing the two very different phases which are of parsing the page and interpreting the page. Instead, JSP pages are executed (a jsp page is tranformed in java code after all) which make it impossible to use it as a general purpose template language (no wonder why it can't work in conjunction with JSF).
  112. popularity[ Go to top ]

    Don't you see? Popularity has nothing to do with quality. The market chooses mediocre products time and time again. Please take a look at this article: http://en.wikipedia.org/wiki/The_Market_for_Lemons
  113. Re: popularity[ Go to top ]

    Don't you see? Popularity has nothing to do with quality. The market chooses mediocre products time and time again.

    Please take a look at this article:

    http://en.wikipedia.org/wiki/The_Market_for_Lemons
    As you've also pointed out quality has nothing to do with success or failure either. Struts was a success, based on the numbers so far it appears JSF will be (if it is not already) a success too. Quality is subjective. Success is not so subjective. Mike
  114. ...why exactly is JSP trash? Note that's a P as in Paul there, not an F as in Frank. I always see everyone saying JSP sucks, is crap, you should use anything but JSP, etc., but I never see reasons stated. I'd like to hear them. If the only argument is that it allows, or even perhaps encourages, mixing of the view with other layers, get over it and train your team members better, to put it bluntly. JSP can be a completely 100% clean view templating technology, it just takes a certain degree of knowledge and discipline. For instance, if all you ever see in a JSP is: Hello, <%=bean.getName()%> ! ...or better still... Hello, ${bean.name} ! ...how is that any worse than Freemarker (which I too like), Velocity, or anything else? If you want to give the argument that JSP is pointless because it gets compiled to a servlet anyway, and there's no point incurring the compilation time, ok, I can buy that... but if this is the only legitimate reason it doesn't seem to me to be enough (matter of opinion though I admit). So, I ask, aside from these two points (because the first I consider invalid and the later I consider not enough to make JSP crap), what are the other reasons? I ask this in all seriousness... I'm like Mulder here, I want to believe, but like Scully I need some concrete proof :)
  115. As I said above, JSP suck because it doesn't distinguish the page interpretion step and the page processing step. There is only one step, page execution. The consequence is that as soon as a jsp line is read, it is processed (executed). This may be not a problem if yours tag don't need to know about their childern or neighborh but in a lot of commons use cases, it is a necessity. Take JSF as an example. JSF construct a tree of UI components from a jsp page. One of the problem with using JSP and JSF together is that somes components need to display their children by theirselves, ie the children component need to be interpreted first and then process. Here is a concrete example from Hans Bergsten article "Improving JSF by dumping JSP": Some more text You would expect the following result : Some text Some more text But what would you get with JSP is : Some more text Some text You get this weird output because panelGroup is in charge of displaying its children components but "Some more text" is displayed as soon as it gets read. The only way out of this is to embedding the static content in custom tags everywhere, making this tags ensure everything is displayed after the page has been interpreted. This is exactly what JSF 1.1 was doing with its mandatory f:verbatim tags which was a very ugly hack. Note this problem isn't limited to JSF but to a lot of other use cases. Of course, you won't notice it in a typical servlet/jsp application. The other problem of JSP is that it is totally dependent of the container (page are translated as servlets). Try to use a jsp engine in a client application for instance.
  116. The first is interesting, and I'll readily admit my experience with JSF is not very deep, so I have to ask, is what your showing a consequence of using JSF components in JSP's, or is it truly a limitation of JSP's? Could you give an example without JSF, just plain JSP's, where this might occur? On the surface it seems like an issue with the way the custom tag (JSF component in this case, but could just as easily be anyother taglib) is working (actually, I think you say as much later, if I understand your comments correctly). The second point is of course true... certainly something like Freemarker would, in theory anyway, allow you to run outside the container just fine. I definitely agree with your point. Still, is it enough to make someone say JSP "sucks"? Isn't that kind of like saying a Trident nuclear submarine sucks because I can't use it in my swimming pool? :) Sure, it's a limitation, and it might even be an important one to you if you are intent on nuking your nextdoor neighbor, but does it really make the sub suck?
  117. I definitely agree with your point. Still, is it enough to make someone say JSP "sucks"? Isn't that kind of like saying a Trident nuclear submarine sucks because I can't use it in my swimming pool? :) Sure, it's a limitation, and it might even be an important one to you if you are intent on nuking your nextdoor neighbor, but does it really make the sub suck?
    Well I personally would not say JSP sucks, it has its nieche and the nieche is the same where ASP, PHP and other similar view/code mixup rendering technologies are located. This is small applications which need a quick turnaround. The problem why everone hates jsps is that those apps usually live longer than they should and once reach a size where they become monsters. From a pure technological view JSP is a lousy tech beginning from a compile to servlet step ending with no mvc whatsoever and a simply display step where the entire logic is embedded. From a pratical view it is a neat technology which still has its nieche but tends to burn developers more in the long run due to not being very scalable issues.
  118. The first is interesting, and I'll readily admit my experience with JSF is not very deep, so I have to ask, is what your showing a consequence of using JSF components in JSP's, or is it truly a limitation of JSP's? Could you give an example without JSF, just plain JSP's, where this might occur? On the surface it seems like an issue with the way the custom tag (JSF component in this case, but could just as easily be anyother taglib) is working (actually, I think you say as much later, if I understand your comments correctly).

    The second point is of course true... certainly something like Freemarker would, in theory anyway, allow you to run outside the container just fine. I definitely agree with your point. Still, is it enough to make someone say JSP "sucks"? Isn't that kind of like saying a Trident nuclear submarine sucks because I can't use it in my swimming pool? :) Sure, it's a limitation, and it might even be an important one to you if you are intent on nuking your nextdoor neighbor, but does it really make the sub suck?
    Well my first point isn't a concern to most people because of the second point. JSP can only be used to serve web content as servlet while tools like Velocity or FreeMarker allow you to produce from a template anything you want : java code, sql, text, ... In those cases, you may see the problems mentionned above arise. JSP as it is right now always read one statement at a time and process it right there. It doesn't read the entire document first and then process it as a whole. It is a big problem when you try to use JSP to define (not outputting) some datas. Why? Because most of the time, the tags have some links together and needs to know about their children, siblings, etc Imagine for instance, if you forget about JSP being tied to the servlet model, trying to define a dynamic Spring or Hibernate configuration using Jsp. How would you do that? It's impossible because Jsp only read one statement at a time and process it right there instead of reading the whole page first. How would you manage the references between the different beans in Spring case? The only way you could make it works is by implementing all Spring configuration elements as Jsp custom tags or by emulating the second phase I was speakin g of : the jsp page output the config as an xml document and a Spring xml definition parse the generated data. So my main bulk against JSP is that it only covers a very precise use case : producing raw web content. It has never meant to be a general templating language as most people would expect. Therefore, it means that in some case you can use jsp and in other cases you would have to use something like Velocity. Don't you find this strange? Personnaly I do.
  119. The consequence is that as soon as a jsp line is read, it is processed (executed). This may be not a problem if yours tag don't need to know about their childern or neighborh but in a lot of commons use cases, it is a necessity.
    it is simply not true for custom JSP tags for example.
  120. The consequence is that as soon as a jsp line is read, it is processed (executed). This may be not a problem if yours tag don't need to know about their childern or neighborh but in a lot of commons use cases, it is a necessity.

    it is simply not true for custom JSP tags for example.
    Which is basically why ugly f:verbatim tags were introcuded at first. Ask developers how they like it.

  121. The only way out of this is to embedding the static content in custom tags everywhere, making this tags ensure everything is displayed after the page has been interpreted. This is exactly what JSF 1.1 was doing with its mandatory f:verbatim tags which was a very ugly hack.
    There is another way, JSF 1.2 resolves that issue as well... Also facelets by dropping JSP have resolved that also... But I agree basically ;-)
  122. You get this weird output because panelGroup is in charge of displaying its children components but "Some more text" is displayed as soon as it gets read.
    just due to stupid compilation. It is not a compiler actually, just a mapping. What prevents JSF from creating a correct tree? Any compiler can do that.
  123. You get this weird output because panelGroup is in charge of displaying its children components but "Some more text" is displayed as soon as it gets read.


    just due to stupid compilation. It is not a compiler actually, just a mapping. What prevents JSF from creating a correct tree? Any compiler can do that.
    You can't compile anything that isn't sequential using JSP because JSP executes the pages sequentially. Therefore, in this case, panelGroup get created, wait to display itself until it body has been processed, "some more text" is interpreted and outputted, the outputText child component get created. Finally, after all the body has been parsed and displayed, the panelGroup render itself and its children. So please tell me how is this due to a stupid compiler? Please tell me how would you be able to compile it correctly using JSP? Jsp interprets and processes the page concurrently, that's why it sucks. Even without this limitation, the stupid tie to the servlet model doesn't allow you to redirect the processing of the data (data is outputted automatically). There is no way to plug in a different page processor, for instance, a JSF page processor able to read the data and construct a UI tree. No the data has to be outputted since it gets translated into a servlet. In Jsf case, it forces you to define a tag by component just to be able to map it as the page is read... Again it is a ugly hack not an elegant solution.
  124. You can't compile anything that isn't sequential using JSP because JSP executes the pages sequentially.
    JSP executes the page in the same order you've put (in thecompiler) Java code in service() method for the resulting servlet. That is so easy. If you are simply writing that code line by line from JSP you will get what do we have now.
  125. Can you provide a link to the Wiki and Forum components that are part of ADF? I do not see them on the component list page. Also, I'm going to join in others saying that such coarse-grained components are not a good idea. Let's take the search example: I may have lots of options on my search (for accounts): - I'd like them to be able to select whether they include inactive accounts or not. - I have 10 different account types, and I'd like to be able to let my users select which one(s) they search on. By default, it should include 'vendors' and 'contractors'. - My results should be sortable and pageable. They should be able to specify how many results per page. - They should be able to save a search. - On some screens, the results should be in a scrollable div of some sort. - I already have a distinct look and feel for my app that this should match. How would you go about creating a JSF component that allowed me to do this? How much easier would it be than simply implementing it myself? Keep in mind, you know nothing about the data (or types of data) I am working with, what mechanism(s) I use for searching, or how I may wish to present this. The actual search functionality will have to be implemented for each case, as will the presentation. What does the search component achieve here? For reference, I have implemented searches with similar (not 100% exact) requirements as I put forth above. Implementing them in JSF hasn't been that difficult, and I honestly do not see where a component would help. And to be honest, I think the search is the most plausible of the half-dozen or so examples you put in your article. The typical model I use for deciding whether or not to create custom JSF components for internal use is this: 1. Design the functionality using currently available components (ie, standard components, 3rd party libraries we use, and custom ones we've already built ). 2. Determine where else we are going to use similar functionality. 3. Evaluate the situation and see if there are opportunities for reuse, and refactor into more abstract functionality where appropriate. Rarely does this turn into a new component. In the case of the search functionality, we couldn't see any gains from turning it into a component. We abstracted out pieces, such as a generic search holder to reduce the amount of code in the backing bean, but there wasn't much beyond that. That isn't to say JSF is perfect - there are still some things that I think could work better, and some things that downright frustrate me. It certainly can be improved upon, but I don't think adding a bunch of monolithic components for specific use cases into the RI is the way to improve it.
  126. Can you provide a link to the Wiki and Forum components that are part of ADF? I do not see them on the component list page.
    We filmed a tech talk with Oracle at JavaOne where they mentioned the ADF components. It should be online fairly soon.
    Also, I'm going to join in others saying that such coarse-grained components are not a good idea. Let's take the search example:

    I may have lots of options on my search (for accounts):
    - I'd like them to be able to select whether they include inactive accounts or not. [snip, lots of specific search requirements] How would you go about creating a JSF component that allowed me to do this? How much easier would it be than simply implementing it myself? Keep in mind, you know nothing about the data (or types of data) I am working with, what mechanism(s) I use for searching, or how I may wish to present this. The actual search functionality will have to be implemented for each case, as will the presentation. What does the search component achieve here?
    For you? Probably nothing. But consider TSS' search facility in the banner; that kind of search is very, very, very common. You have an input with a "go" button of some kind, and the results are paginated. It's not the most capable search in the world, to be sure - but it's horribly common. that kind of common component is what I had in mind, not a replacement for every capability that might be needed for every specific project.
    For reference, I have implemented searches with similar (not 100% exact) requirements as I put forth above. Implementing them in JSF hasn't been that difficult, and I honestly do not see where a component would help. And to be honest, I think the search is the most plausible of the half-dozen or so examples you put in your article.
    Ha! That's entirely fair. I'd point back at the Oracle components, though - Oracle has a lot more time than I do to focus on this stuff. I have only my own meager requirements; I'm a visionary with 20/80 vision, perhaps. In the long run, the component idea would probably involve making writing components easier (perhaps by allowing easier composition of "complex components"), which would impact not only the coarse components I've referred to, but custom components like you've written.
    The typical model I use for deciding whether or not to create custom JSF components for internal use is this:

    1. Design the functionality using currently available components (ie, standard components, 3rd party libraries we use, and custom ones we've already built
    ).
    2. Determine where else we are going to use similar functionality.
    3. Evaluate the situation and see if there are opportunities for reuse, and refactor into more abstract functionality where appropriate.

    Rarely does this turn into a new component. In the case of the search functionality, we couldn't see any gains from turning it into a component. We abstracted out pieces, such as a generic search holder to reduce the amount of code in the backing bean, but there wasn't much beyond that.

    That isn't to say JSF is perfect - there are still some things that I think could work better, and some things that downright frustrate me. It certainly can be improved upon, but I don't think adding a bunch of monolithic components for specific use cases into the RI is the way to improve it.
    Whoa, wait - I wasn't suggesting that putting components into the RI was the way to go. I have this (possibly absurd) vision of a component market past the RI... and I think the existence of such components is only part of "the real problem" being discussed. There are a series of issues. Components are one; education is another, partially because the components are so basic that neophytes don't see the advantages of JSF in the first place. "All this extra complexity for an ..." this doesn't work, from what I've seen and experienced. I've watched JSF for a long, long time now, and questioned it. (And, along the way, used other frameworks instead.) But I'm also a big believer in standards, where they exist, and if a standard can be improved, I think it should be. Further, JSF's problems are very similar to other standard Java technologies. One thing Sun has done really poorly is teach about the technologies it evangelizes. That's the other half of the message here.
  127. For you? Probably nothing. But consider TSS' search facility in the banner; that kind of search is very, very, very common. You have an input with a "go" button of some kind, and the results are paginated. It's not the most capable search in the world, to be sure - but it's horribly common. that kind of common component is what I had in mind, not a replacement for every capability that might be needed for every specific project.
    Yes, but there are many layout variations of that search box. Even something simple like allowing them to search just TSS or the web in general adds more complication to the component. The more layout you try to encapsulate in a component, the harder it is to reuse. Assuming that a simple search will suffice, however, what does a JSF component accomplish in that situation? Implementing something that trivial is so simple to do already, that I fail to see where any benefit can be derived. You remove layout flexibility to save someone from having to type a few characters?
    Ha! That's entirely fair. I'd point back at the Oracle components, though - Oracle has a lot more time than I do to focus on this stuff.
    Whether the Oracle components wiki and forum components actually turn out to be useful still remains to be seen, so I don't know what you are getting at there.
    In the long run, the component idea would probably involve making writing components easier (perhaps by allowing easier composition of "complex components"), which would impact not only the coarse components I've referred to, but custom components like you've written.
    I agree that creating components should be easier - and I believe this is something the EG is looking at for JSF 2. That said, you can already do something like you suggest with Facelets - and I have been doing it with quite a bit of success - using composition components. In fact, that's how I'd see you implementing a wiki, forum, login, or search for your project. You create the functionality using whatever useful components you can, then abstract it into a composition component that you can reuse. You get the reusability, but aren't tied to how a particular component creator chose to layout the component.
    Whoa, wait - I wasn't suggesting that putting components into the RI was the way to go. I have this (possibly absurd) vision of a component market past the RI... and I think the existence of such components is only part of "the real problem" being discussed. There are a series of issues. Components are one; education is another, partially because the components are so basic that neophytes don't see the advantages of JSF in the first place.
    Sorry, when you were lamenting the lack of useful standard components in your article, I assumed you thought there should be more standard components along the lines of what you suggested. This is a common complaint about JSF - there aren't enough standard components as part of the spec. That said, I don't think that coarse-grained components are what JSF is made for, and they certainly aren't where it will excel. In the past, we've evaluated component libraries to meet certain needs in our apps, and coarse-grained components have rarely been useful. Why? Because our apps (like most projects) have their own designs, and rarely does an off-the-shelf component match that. So, what do you do? Have each component have its own template you can customize? I don't see a way to accomplish what you are talking about in a useful manner.
  128. JSF needs to do more.[ Go to top ]

    The concept behind JSF is good, but if JSF is focusing on web based component programming, it should improve more both at the spec and the ref implementation. As a component-based programming model, at lease the event and status should be well kept, and the way to find a component from a model or vice versa should be easy, but in current jsf ref implementation, these are still very limited. Besides, full of bug. And also, JSF seems don't have a good plan in training developers, in all, at least now, JSF is still at a fair preliminary status, it could be fail or success, depending on how sun's doing it.