Home

News: JSF for nonbelievers: Clearing the FUD about JSF

  1. JSF for nonbelievers: Clearing the FUD about JSF (179 messages)

    Rick Hightower has come out to tell the community that JSF is easier to use than you think, and that there is a lot of FUD surrounding it. He has started a four part crusade to this effect. What are your experiences with JSF?
    For such an indispensable technology, JavaServer Faces (JSF) has generated an undue amount of FUD. Hearsay has it that JSF development is difficult, more demanding than some mainstream approaches, and dependent on WYSIWYG tools to work at all. In this new four-part series, Rick Hightower separates FUD from fact to show you that, actually, JSF can be easier to use than MVC Model 2 frameworks such as Struts. If you know what you're doing, that is.

    Fear, uncertainty, and doubt (FUD) has been circulating about J2EE's JavaServer Faces (JSF) technology for a while now and I've decided the time has come to put a stop to it; or at least offer a balancing perspective. The first myth about JSF is that you need a WYSIWYG drag-and-drop tool to do JSF development. The second is that JSF doesn't support MVC Model 2 frameworks like Struts. And the final, most all-encompassing myth about JSF development is that it's just plain difficult.

    In this four-part series, I'll do my best to dispel all three myths in the most practical way possible: by teaching you to work around them. The fact is, if you think JSF development is difficult you're probably not doing it right, and fortunately that's pretty easy to fix. I'll get you started this month with an architectural overview of JSF and a working example demonstrating the fundamentals of MVC and JSF. But before we get into all that, I'll take just a minute to separate some JSF FUD from fact.

    JSF for nonbelievers: Clearing the FUD about JSF

    Threaded Messages (179)

  2. I don't think the FUD relates to the difficulty in developing, but with the quality of the implementations? I think the lack of integration with JSTL and the core contexts also makes it appear more difficult from the outside. Whilst I can see the technical arguement for the separate context, I don't think people want to drop jstl and use the jsf tags.

    Could be wrong tho :P
  3. I don't think the FUD relates to the difficulty in developing, but with the quality of the implementations? I think the lack of integration with JSTL and the core contexts also makes it appear more difficult from the outside. Whilst I can see the technical arguement for the separate context, I don't think people want to drop jstl and use the jsf tags.Could be wrong tho :P

    It's perfectly understandable that developers are battling a bit in migrating to JSF. I'm sure some of the other JSF EG members will comment, but from my experience as a JSF-RI developer and participating on the forums, I've been seeing JSF users trying to use JSF the same way as Struts or other current MVC frameworks-- and it doesn't work that way.

    First off, the issues with JSTL and JSF integration will be solved in the next release as JSP and JSF are integrating together within the EL realm (don't worry, JSF isn't taking over JSP by ANY means).

    Secondly, JSF will always be more restrictive in the tags you can use in the view. Through promoting the concept of predefined UI Components, your views become more assertive and reusable. Think of it this way with displaying a table of information-- instead of writing a JSP that intermingles a c:forEach, with a couple c:choose/c:ifs in each column in between a mess of HTML; you as a programmer, just write a single component that handles all of the HTML rendering in a reusable component-- keeping the logic out of the page. Which is better? Lets say that you want to display that table on 5 other pages-- are you going to cut and paste that mix of JSTL and HTML to 5 other pages? Or, are you simply going to drop your JSF component tag in 5 other pages? The latter seems much more maintainable to me, and probably will perform a lot faster if you do all of your control statements within compiled Java code that can be managed in one spot.

    Third, JSF is a Pull MVC framework. Users are still trying to mimic Struts/WebWork Actions that *push* collections and beans around in the Request or Session. This mindset snowballs many initial attempts to use JSF. Users should be starting to leverage JSF's Managed Bean Framework to pre-specify objects your application will use. Once these beans are specified, they can be pulled into any view or acted upon with any action. The managed bean framework also allows beans to act as Actions or Commands as bean properties can be assigned from Request Parameters at creation-- providing context such as the current employee ID you wish to view or the product Id you would like to add to your order.

    This probably isn't the forum to provide additional help with migrating to JSF-- hopefully I will be able to put an article or two out there on it.

    -Jacob
  4. Through promoting the concept of predefined UI Components, your views become more assertive and reusable. Think of it this way with displaying a table of information-- instead of writing a JSP that intermingles a c:forEach, with a couple c:choose/c:ifs in each column in between a mess of HTML; you as a programmer, just write a single component that handles all of the HTML rendering in a reusable component-- keeping the logic out of the page. Which is better? Lets say that you want to display that table on 5 other pages-- are you going to cut and paste that mix of JSTL and HTML to 5 other pages? Or, are you simply going to drop your JSF component tag in 5 other pages? The latter seems much more maintainable to me, and probably will perform a lot faster if you do all of your control statements within compiled Java code that can be managed in one spot.

    Umm... Many of us have been doing this using other framework s and JSP for many years. Best practices aren't the sole realm of JSF and suggesting that these are the two choices is just plain FUD, IMO.
    Third, JSF is a Pull MVC framework. Users are still trying to mimic Struts/WebWork Actions that *push* collections and beans around in the Request or Session.

    It's ironic, in a discussion about clearing up the FUD about JSF and people talking about it that don't know anything about it, that you would choose to say something like this. WebWork is and has always been a *pull* MVC framework. It gets information without you having to bind it into the page. It uses an expression language to find the values you are looking for from the context without you having to tie the page to any particular bean implementation.

    I'll try to understand your framework, please do me the same courtesy.
    This mindset snowballs many initial attempts to use JSF. Users should be starting to leverage JSF's Managed Bean Framework to pre-specify objects your application will use. Once these beans are specified, they can be pulled into any view or acted upon with any action.

    See... this sounds like *push* to me. Pre-specify = push.
    The managed bean framework also allows beans to act as Actions or Commands as bean properties can be assigned from Request Parameters at creation-- providing context such as the current employee ID you wish to view or the product Id you would like to add to your order.This probably isn't the forum to provide additional help with migrating to JSF-- hopefully I will be able to put an article or two out there on it.-Jacob

    Please do some more research before referencing other frameworks and their capabilities.
  5. It's ironic, in a discussion about clearing up the FUD about JSF and people talking about it that don't know anything about it, that you would choose to say something like this. WebWork is and has always been a *pull* MVC framework. It gets information without you having to bind it into the page. It uses an expression language to find the values you are looking for from the context without you having to tie the page to any particular bean implementation.

    I'll try to understand your framework, please do me the same courtesy.

    I'm going to offer that courtesy and elaborate on my point (and I'm only speaking for myself as a developer).

    The emphasis of my statement mainly pointed at the way that developers approach MVC frameworks or misuse them despite whatever intentions the framework authors provided (WebWork included which is a great solution IMHO, and I'm not just being nice). This developer mindset, clearly emphasized in Struts is procedural in nature-- the concept of requiring Actions or Command procedures to guide the application flow and data models. While JSF does have Actions or procedures, it doesn't require them within a model 1 architecture.

    The same statement goes with my first original point I made on the concept of UI Components. Just because they are capable of abstracting and isolating UI changes, doesn't mean that most developers use them. My comments were founded on the common web application developer who creates a series of Actions, using framework X, and pushes data into the scopes provided in order make that data available to some view as specified by the Action called.
  6. I'm going to offer that courtesy and elaborate on my point (and I'm only speaking for myself as a developer).The emphasis of my statement mainly pointed at the way that developers approach MVC frameworks or misuse them despite whatever intentions the framework authors provided (WebWork included which is a great solution IMHO, and I'm not just being nice). This developer mindset, clearly emphasized in Struts is procedural in nature-- the concept of requiring Actions or Command procedures to guide the application flow and data models. While JSF does have Actions or procedures, it doesn't require them within a model 1 architecture.The same statement goes with my first original point I made on the concept of UI Components. Just because they are capable of abstracting and isolating UI changes, doesn't mean that most developers use them. My comments were founded on the common web application developer who creates a series of Actions, using framework X, and pushes data into the scopes provided in order make that data available to some view as specified by the Action called.

    Ok, now I'm interested. Although I don't agree with saying that developers have to push anything anywhere in WebWork (it's automagically populated for you) I agree that what I've seen of other MVC frameworks requires this kind of plumbing code, which sucks IMO.

    Can you please describe the data and page flow for a set of CRUD pages for persistent entity using JSF as a comparison? I'm interested in understanding the difference.
  7. Ok, now I'm interested. Although I don't agree with saying that developers have to push anything anywhere in WebWork (it's automagically populated for you) I agree that what I've seen of other MVC frameworks requires this kind of plumbing code, which sucks IMO.Can you please describe the data and page flow for a set of CRUD pages for persistent entity using JSF as a comparison? I'm interested in understanding the difference.

    A decent example of this approach was posted on JavaWorld a while back: Put JSF to work.

    While you end up using method signatures to define actions for CRUD operations, read operations can be wired in a Spring-like manner and pulled into the view in a pre-specified scope, just by requesting a JSP page directly. I'm sure other frameworks offer this same feature.

    Also, by using method signatures instead of actions, it's up to the developer to decide the grainularity of their application controller-- seperate or concentrate as much as you want within beans.

    The other benefit/consequence of JSF is that validation/conversions/listeners/etc can be expressed within the JSP page itself-- basically like configuring your Action before it's fired on a per page basis.
  8. A decent example of this approach was posted on JavaWorld a while back: Put JSF to work.While you end up using method signatures to define actions for CRUD operations, read operations can be wired in a Spring-like manner and pulled into the view in a pre-specified scope, just by requesting a JSP page directly.I'm sure other frameworks offer this same feature.
    This could easily be done (and is regularly done) with an Interceptor in XWork / WebWork. I prefer not having this hardwired in, though, as it's better to give users the freedom to do this how they'd like.
    Also, by using method signatures instead of actions, it's up to the developer to decide the grainularity of their application controller-- seperate or concentrate as much as you want within beans.

    WebWork allows you to map multiple Action aliases to one class calling different methods on it. I like to implement my CRUD screens all with one Action. It ends up being about 20 lines long, altogether.
    The other benefit/consequence of JSF is that validation/conversions/listeners/etc can be expressed within the JSP page itself-- basically like configuring your Action before it's fired on a per page basis.

    Ugh... I thought we learned better than putting code in the page itself? I use validation differently. Since I'm directly accessing my domain model objects, I like to have a set of validations that can be used for those objects EVERYWHERE. This includes in batch processing when there's no web page involved. If you put validations and conversions in the page, then you'll have to put them in EVERY page.

    The XWork validation framework provides a generic object validation framework which can be used in any context, not just the web. It grew out of a need to consolidate validations across both a web app and a batch processing app for the same domain model. It also allows you have different validations for different contexts, etc.

    Anyway, I don't think bundling this kind of stuff into a page is a good idea. Maybe this is an example of JSF targeting a different market, the rapid app development market where you want to get things up fast. I'm not convinced this type of development would work at all for large scale projects, and I would be worried about maintenance of apps structured like this, no matter what the size.
  9. Anyway, I don't think bundling this kind of stuff into a page is a good idea. Maybe this is an example of JSF targeting a different market, the rapid app development market where you want to get things up fast. I'm not convinced this type of development would work at all for large scale projects, and I would be worried about maintenance of apps structured like this, no matter what the size.

    I agree with you on this point, but like I said, it leaves it up to the developer to scale their own layers on a case by case basis if they choose, or model validation/components within the Managed Bean Framework and pulled into the view if they choose.
  10. Anyway, I don't think bundling this kind of stuff into a page is a good idea. Maybe this is an example of JSF targeting a different market, the rapid app development market where you want to get things up fast. I'm not convinced this type of development would work at all for large scale projects, and I would be worried about maintenance of apps structured like this, no matter what the size.
    I agree with you on this point, but like I said, it leaves it up to the developer to scale their own layers on a case by case basis if they choose, or model validation/components within the Managed Bean Framework and pulled into the view if they choose.

    But JSF supports this bad practice. It's got a whole group of supporting facilities just screaming "use me, this is the way JSF works!". To say that you can build layered applications with real controllers and validations is bogus, because you can do that with any framework, and others make this right way the standard supported way.
  11. JSF Validation[ Go to top ]

    Anyway, I don't think bundling [validation] into a page is a good idea.
    I agree with you on this point, but like I said, it leaves it up to the developer to scale their own layers on a case by case basis if they choose, or model validation/components within the Managed Bean Framework and pulled into the view if they choose.
    But JSF supports this bad practice.

    You guys seem to be talking about bundling validation code into the JSP page (i.e the view). Can you give me an example of how JSF supports/encourages this practice?

    In my experience, validation with JSF is handled on the server. You put validation tags in the JSP, but the code is in server-side objects (backing beans or other classes). For client-side validation, I've seen JSF validation tags that use JavaScript, but again, that code is not bundled in the page, but rather in the tag library.

    Maybe I'm misunderstanding (or just overlooking something obvious -- wouldn't be the first time).
  12. JSF Validation[ Go to top ]

    You guys seem to be talking about bundling validation code into the JSP page (i.e the view). Can you give me an example of how JSF supports/encourages this practice?In my experience, validation with JSF is handled on the server. You put validation tags in the JSP, but the code is in server-side objects (backing beans or other classes). For client-side validation, I've seen JSF validation tags that use JavaScript, but again, that code is not bundled in the page, but rather in the tag library. Maybe I'm misunderstanding (or just overlooking something obvious -- wouldn't be the first time).

    What I'm talking about is that configuring validations and conversions per page is a poor practice because it leads to lots of duplicated markup across pages. I prefer to work directly with my domain model objects and define my validations and conversions one time for my domain model objects to be used everywhere. You're tying your validations up in JSF specific beans or, worse yet, in a taglib.

    This brings up another point, though. If you have a JSF component which doesn't support client-side validation, and you want to add it, then you have to write another Renderer class to cut and paste the original Renderer code and then add some more println() statements to add Javascript. This is where templated components is a HUGE win, because you can just tweak the template and you're done.
  13. JSF Validation[ Go to top ]

    What I'm talking about is that configuring validations and conversions per page is a poor practice because it leads to lots of duplicated markup across pages. I prefer to work directly with my domain model objects and define my validations and conversions one time for my domain model objects to be used everywhere. You're tying your validations up in JSF specific beans or, worse yet, in a taglib.

    Oh, I see. Are your validations and conversion done in POJOs? We have some setup like that, and the JSF-specific backing bean wraps the validation method so that we can provide feedback (e.g. validation error messages) through JSF messages.
  14. JSF Validation[ Go to top ]

    What I'm talking about is that configuring validations and conversions per page is a poor practice because it leads to lots of duplicated markup across pages. I prefer to work directly with my domain model objects and define my validations and conversions one time for my domain model objects to be used everywhere. You're tying your validations up in JSF specific beans or, worse yet, in a taglib.
    Oh, I see. Are your validations and conversion done in POJOs? We have some setup like that, and the JSF-specific backing bean wraps the validation method so that we can provide feedback (e.g. validation error messages) through JSF messages.

    Yes, the XWork Validation framework works against POJOs and can be used completely outside a Web context. I apply them against our domain model, which are POJOs persisted with Hibernate.

    This is why flexible POJO based frameworks are more interesting (to me) and play better with other tools, so we don't have to do wrappers like this.
  15. JSF Validation[ Go to top ]

    Yes, the XWork Validation framework works against POJOs and can be used completely outside a Web context. I apply them against our domain model, which are POJOs persisted with Hibernate. This is why flexible POJO based frameworks are more interesting (to me) and play better with other tools, so we don't have to do wrappers like this.

    JSF does use POJOs and with the newest rendition of JSF 1.1, you can specify a generic method to validate an object/property.

    The way I initially looked at JSF was that I was able to get rid of having to code protocol collaboration within my business POJOs. If I'm writing an application to work with an employee database, I just bring my business objects right into JSF and have JSF UI components manage them and modify them however I please. It's not going to be a matter of writing an action to do this, or writing an action to do that, while writing a form bean just to be able to support some page. Really, if you are talking TDD mentality and removing dependencies-- an object model used in JSF doesn't have to have an ounce of code anywhere that knows of JSF's APIs. Flexible? I believe so.
  16. JSF Validation[ Go to top ]

    Yes, the XWork Validation framework works against POJOs and can be used completely outside a Web context. I apply them against our domain model, which are POJOs persisted with Hibernate. This is why flexible POJO based frameworks are more interesting (to me) and play better with other tools, so we don't have to do wrappers like this.
    JSF does use POJOs and with the newest rendition of JSF 1.1, you can specify a generic method to validate an object/property.The way I initially looked at JSF was that I was able to get rid of having to code protocol collaboration within my business POJOs. If I'm writing an application to work with an employee database, I just bring my business objects right into JSF and have JSF UI components manage them and modify them however I please. It's not going to be a matter of writing an action to do this, or writing an action to do that, while writing a form bean just to be able to support some page. Really, if you are talking TDD mentality and removing dependencies-- an object model used in JSF doesn't have to have an ounce of code anywhere that knows of JSF's APIs. Flexible? I believe so.

    Yes, but the JSF UI components working with your business objects are implementing BUSINESS LOGIC by managing the interactions between these services / entities. UI implementing business logic is less maintainable than not.
  17. JSF Validation[ Go to top ]

    Yes, but the JSF UI components working with your business objects are implementing BUSINESS LOGIC by managing the interactions between these services / entities. UI implementing business logic is less maintainable than not.

    Here's an article that addresses decoupling validation rules from the presentation in JSF:

    Improve JSF by Decoupling Form Rules from Presentation Components

    There are some links to related discussions in Sun's forums at the bottom of the article.
  18. JSF Validation[ Go to top ]

    I should have mentioned that the example markup in the article doesn't display properly on that web page (at least not on Safari or Firefox), but is visible if you view source.

    I think his proposals make sense; if something like this were built into JSF it would allow for the kind of decoupling you're talking about (and I think you have a valid criticism of the way validation is approached in JSF -- although that approach is hardly unique to JSF).
  19. JSF Validation Using Chains? XWork?[ Go to top ]

    Ran across this while reading about JSF validation/XWork/et cetera.

    JSF + Chains

    I saw your comment on the page, too. While Chains seems like a reasonable choice, it sounds like XWork is probably a more mature solution. The nice thing about the Chains solution is that it looks pretty easy to integrate into JSF. Can XWork be used with JSF?
  20. JSF Validation Using Chains? XWork?[ Go to top ]

    Ran across this while reading about JSF validation/XWork/et cetera.JSF + ChainsI saw your comment on the page, too. While Chains seems like a reasonable choice, it sounds like XWork is probably a more mature solution. The nice thing about the Chains solution is that it looks pretty easy to integrate into JSF. Can XWork be used with JSF?

    I'm sure it could if someone wanted to do it. I'd be glad to answer questions for that person, but I'm not interested in doing it myself.
  21. JSF Validation[ Go to top ]

    This brings up another point, though. If you have a JSF component which doesn't support client-side validation, and you want to add it, then you have to write another Renderer class to cut and paste the original Renderer code and then add some more println() statements to add Javascript.

    There's also the option of using Jakarta Commons Validator (or even Struts validation) for client-side validation with JSF, rather than "rolling your own". IIRC, Core JavaServer Faces talks about this, somewhere.
  22. JSF validation sucks[ Go to top ]

    validation is definitely the weakest part of the current JSF spec. I usually don't want to validate a form field by field but in one go by binding the whole form to a backing bean (using Ioc) send that as an argument to my business service method running in the service tier not the web tier, let that do all the validation and return a HashMap of validation error strings (e.g. in an exception). JSf should catch that exception and display the error strings in the web form. JSF doesn't offer any support for this; in fact because in the validation phase no field values are bound to a backing bean, it makes is damn hard to implement it yourself. The only way to properly do it (using Ioc, not by manually pulling the values out of the UIComponents themselves) is by bypassing JSF validation altogether (the validation phase) and do your validation in the update model phase... Talk about a well designed framework...

    Another thing that is totally missing is the notion of workflow (e.g. a form submission that is split over several pages).

    The JSF spec people should take a good look at Spring MVC and how they support validation and workflow.
  23. JSF validation sucks[ Go to top ]

    validation is definitely the weakest part of the current JSF spec. I usually don't want to validate a form field by field but in one go by binding the whole form to a backing bean (using Ioc) send that as an argument to my business service method running in the service tier not the web tier, let that do all the validation and return a HashMap of validation error strings (e.g. in an exception). JSf should catch that exception and display the error strings in the web form. JSF doesn't offer any support for this; in fact because in the validation phase no field values are bound to a backing bean, it makes is damn hard to implement it yourself. The only way to properly do it (using Ioc, not by manually pulling the values out of the UIComponents themselves) is by bypassing JSF validation altogether (the validation phase) and do your validation in the update model phase... Talk about a well designed framework...Another thing that is totally missing is the notion of workflow (e.g. a form submission that is split over several pages).The JSF spec people should take a good look at Spring MVC and how they support validation and workflow.

    You should take a look at the specification in more detail and see that you can create a business rule validator and place it in the configuration file as a managed bean. See Here.

    Workflow--- you can create a POJO bean and place it in the session and create a series of Action methods on that bean for each step which control the flow.

    BTW, we aren't allowed to look at any other frameworks to see how they are doing things, such as SpringMVC or Struts. We have a magic shoe that we talk into and it tells us how JSF should work.

    Jacob Hookom
    McKesson Medical-Surgical
  24. missing my point[ Go to top ]

    Dude, you are completely missing my point.

    1) I know that you there exist validator classes/tags and that you can write your own. That's just what I don't like: your validators are JSF specific objects (worse you have to write 2 classes: 1 for the real validator and one to wrap it in a custom JSP tag :( )

    What I want is a business POJO class which does validation that is agnostic of the JSF framework. This way I do my validation in the business logic (but trigger it from the web tier if I'am accessing the business logic through the web tier. Also when i switch from web framework I don't have to rewrite all my validation code.


    2) workflow: of course you can define a JSF bean and store it in a session (duh!). The point is that Spring MVC has built in support (via Wizard controllers) for submission over multiple pages with integration validation handling. In JSF you have to write all this yourself.
  25. JSF validation sucks[ Go to top ]

    validation is definitely the weakest part of the current JSF spec. I usually don't want to validate a form field by field but in one go by binding the whole form to a backing bean (using Ioc) send that as an argument to my business service method running in the service tier not the web tier, let that do all the validation and return a HashMap of validation error strings (e.g. in an exception).
    This is almost exactly what I do in my code. But for business services which are UI-agnostic I prefer to return error codes instead of returning error strings, because the business service may be exposed as a web service or may provide data to voice-enabled application or may serve cell phones with WML and small displays. Web service will be perfectly happy with error codes, WML should have shorter messages, and voice system should provide voice messages instead of stringified ones.

    So, human-legible error reporting should happen in UI tier corresponding to a particular client type, not in the business tier.
    JSf should catch that exception and display the error strings in the web form. JSF doesn't offer any support for this; in fact because in the validation phase no field values are bound to a backing bean, it makes is damn hard to implement it yourself.
    Granted, I did not look thoroughly at JSF validation yet. What I do in my Struts-based code, is that I set up session-scoped form bean and store error messages in it instead of returning them from validate(). This way I can safely do redirection from POSTing input to GETting the view, and I can refresh view anytime without risking of losing error messages. Error messages are cleaned each time input comes in.
  26. great reply[ Go to top ]

    Your suggestion of using error codes instead of error strings is good. I'll use it and use the error codes as key in a resource bundle to look up the error strings.

    Thanks for the improvement to the pattern!

    Sincerely,
    Steven Sagaert
  27. But JSF supports this bad practice. It's got a whole group of supporting facilities just screaming "use me, this is the way JSF works!". To say that you can build layered applications with real controllers and validations is bogus, because you can do that with any framework, and others make this right way the standard supported way.

    You have to understand what JSF is trying to accomplish. It's a component framework with building blocks, meant to appeal to hardened Java developers and newcomers from the M$ realm with tool support. Yes, go ahead and say that JSF is like ASP.NET-- in supporting a visual IDE, but lets stop there. Mechanically, JSF works a lot differently and Sun is tackling the specification in such a way that developers, as always, will have choice in IDEs, Protocols, Components, and scalability/layering.

    While experienced developers may say, JSF on its own, doesn't handle all the MVC features you would expect; you have to also think about the larger majority of 'developers' who are used to and looking for visual tool support. Projects like Craig's Struts: Shale will provide the meat that experienced developers are looking for in their controller, while allowing the flexibility of various visual tools (and handcoded XML) to support RAD from even non-programmers.

    Senior developers can also provide themselves much more control over projects as they are the ones that develop and maintain the components that others use. At least in our development group, it was a 'push and hope' cycle where senior programmers pushed information into the request or session from an action, and hoped that the designers/junior programmers could properly identify and work with the schema we provided within HTML and JSTL markup.

    With strict component development (not that JSF is exclusive), programmers initially work with UI requirements to build standard components for their application, and then it's trivial work for the other half of your team to get that data presented in the UI with a couple tags on any multitude of pages or projects that come up.

    For those who are hooked up on HTML templates, I believe the JSF enforces a more standardized approach. When HTML first came out, elements provided literal structure to the document-- a list was a list, a table was a table, a link was a link. It was a very strict interpretation of how data should be structured. Within that spirit, it's feasible to build a component that efficiently writes HTML to a stream within your Java code-- without worrying about the presentation details, leaving your code relatively static and literal throughout the applications' life.

    Where I believe HTML templating (and HTML/JSTL mixing) can be problematic on large teams is that each developer, using their favorite visual HTML editor, can easily provide their own 'touches' to the page, intermingling both structual and presentation concerns. Over time, as I'm sure others have experienced, every page ends up with it's own quirks and style. (Feel free to comment here)

    While JSF doesn't solve all UI issues, it does force the same mentality you place on your domain model to occur within your view. Taking that next step, hopefully with tool support, the benefits of a UI component model will be the same as a well put together object model within your business tier.

    -Jacob
  28. You have to understand what JSF is trying to accomplish. It's a component framework with building blocks, meant to appeal to hardened Java developers and newcomers from the M$ realm with tool support. Yes, go ahead and say that JSF is like ASP.NET-- in supporting a visual IDE, but lets stop there. Mechanically, JSF works a lot differently and Sun is tackling the specification in such a way that developers, as always, will have choice in IDEs, Protocols, Components, and scalability/layering.While experienced developers may say, JSF on its own, doesn't handle all the MVC features you would expect; you have to also think about the larger majority of 'developers' who are used to and looking for visual tool support. Projects like Craig's Struts: Shale will provide the meat that experienced developers are looking for in their controller, while allowing the flexibility of various visual tools (and handcoded XML) to support RAD from even non-programmers.
    Great, you've reimplemented RAD tools from the 80's on the web, but I'm sure the scalability and maintainability of the apps will be *much* better this time.
    Senior developers can also provide themselves much more control over projects as they are the ones that develop and maintain the components that others use.

    Well, I've never seen widescale cross-project reuse materialize in any UI framework (client or server) for non-simple UI components, but again, I'm sure you'll succeed where all others have failed.
      At least in our development group, it was a 'push and hope' cycle where senior programmers pushed information into the request or session from an action, and hoped that the designers/junior programmers could properly identify and work with the schema we provided within HTML and JSTL markup.

    Sounds more like limitations with standard JSP/JSTL development than anything else...
    With strict component development (not that JSF is exclusive), programmers initially work with UI requirements to build standard components for their application, and then it's trivial work for the other half of your team to get that data presented in the UI with a couple tags on any multitude of pages or projects that come up.

    Yes, many frameworks allow for reuse. Most don't require complicated lifecycles or tooling to provide it. I would argue that both WebWork using the <ww:action> tag and Sitemesh using inline decorators make for much simpler reusable components.
    For those who are hooked up on HTML templates, I believe the JSF enforces a more standardized approach. When HTML first came out, elements provided literal structure to the document-- a list was a list, a table was a table, a link was a link. It was a very strict interpretation of how data should be structured. Within that spirit, it's feasible to build a component that efficiently writes HTML to a stream within your Java code-- without worrying about the presentation details, leaving your code relatively static and literal throughout the applications' life.Where I believe HTML templating (and HTML/JSTL mixing) can be problematic on large teams is that each developer, using their favorite visual HTML editor, can easily provide their own 'touches' to the page, intermingling both structual and presentation concerns. Over time, as I'm sure others have experienced, every page ends up with it's own quirks and style. (Feel free to comment here)

    Sounds like you had lousy control over your UI guidelines. So, if I understand, your argument is that by making it harder to change the output, you get better control? So let's all just write out every page using out.println() because then it's even harder to manage change and noone will mess with things. Seriously though, you don't end up with a ton of templates. People usually build one theme, if they change the defaults at all, and maybe a couple templates for each of a handful of the UI components for different use cases. You don't get an explosion of templates, in my experience, but maybe I've just been working on good teams where people don't go off uncontrolled. In such a team, what's to prevent people from copying your Renderer class and tweaking that?
    While JSF doesn't solve all UI issues, it does force the same mentality you place on your domain model to occur within your view. Taking that next step, hopefully with tool support, the benefits of a UI component model will be the same as a well put together object model within your business tier.-Jacob

    I don't understand this comment... You want to make your UI static and lock down changes? Do your customers agree to this? I prefer to encapsulate changes to the UI using decorators and Sitemesh and make the actual JSP/HTML I have to build for the functionality of a page very small, with all of the layout and styling done in the decorators. This lets me manage the UI very efficiently.
  29. While JSF doesn't solve all UI issues, it does force the same mentality you place on your domain model to occur within your view. Taking that next step, hopefully with tool support, the benefits of a UI component model will be the same as a well put together object model within your business tier.-Jacob
    I don't understand this comment... You want to make your UI static and lock down changes? Do your customers agree to this?
    The way that JSF implements component rendering, yes, they are just as static as having a JSP Tag write HTML to the output stream as with every other framework. JSF allows these components to callaborate during rendering which is very dynamic, in such a way that is unique only to JSF as far as I know.

    Keep in mind, I'm only locking down changes to the HTML structure rendered-- not the data rendered (bean properties, values, etc). Then designers can use web standards for an even more flexible presentation. The reason for this is that by being more strict and consistent in the structure, you actually allow more flexability in the presentation of the data across the whole application.

    Read On.
  30. JSF allows these components to collaborate during rendering which is very dynamic, in such a way that is unique only to JSF as far as I know.K
    Based on everything I've seen, Tapestry is much more highly dynamic than JSF in this regard. In Tapestry, it is very easy to enclose some text and components inside a Block component and pass that component as a parameter to another page or another component, allowing it to be rendered out of context (via a RenderBlock component).

    For example, on TSS, the PostReplyForm of the PostNewsReply page (which contains the TextArea into which I'm typing at this moment) contains a Block that will be passed to the NewsThread page, and from there into the SkinBorder component.

    The SkinBorder renders this Block, which ends up being the "Thanks for posting" message that appears in the upper right hand "announcement space". The Block contains a mix of HTML and components, including a Script component that generates javascript to reposition the window to the posting you just made. Of course, that JavaScript is collected into a big script block just inside the <body> tag, just like any other JavaScript created during the render of the page.

    So, when I say that Tapestry is dynamic, it means something broad, and useful, and practical. Any page, even any component, within TSS can put any bit of dynamic content into that announcement block (the administrative pages even put small forms into the announcement block).
  31. The way that JSF implements component rendering, yes, they are just as static as having a JSP Tag write HTML to the output stream as with every other framework.

    See, this is what I'm talking about. READ UP ON OTHER FRAMEWORKS, especially those of people grilling you on the details of why yours is problematic :-)

    WebWork's UI tags render templates that the user can tweak. You group templates into themes of related templates, and you can specify the theme and/or template to use on a per-tag basis. Templates for the UI component output makes things MUCH more customizable.
      JSF allows these components to callaborate during rendering which is very dynamic, in such a way that is unique only to JSF as far as I know.

    I see a Tapestry post coming...
    Keep in mind, I'm only locking down changes to the HTML structure rendered-- not the data rendered (bean properties, values, etc). Then designers can use web standards for an even more flexible presentation. The reason for this is that by being more strict and consistent in the structure, you actually allow more flexability in the presentation of the data across the whole application.Read On.

    Yes, but I think it's obvious that the template allows this and more.
  32. Keep in mind, I'm only locking down changes to the HTML structure rendered-- not the data rendered (bean properties, values, etc).
    How you cannot lock the data [items] if you have all these listeners and event handlers? Isn't this a little more constrained than, say, having a bunch of properties sitting on the server, and pulling the properties you need simply by adding another <input> element to your HTML FORM? Despite the hype around page-oriented component model I think that it puts more constraints on view structure and content, than something that was called here "pushing data to the session".

    Am I too far off thinking that JSF is a view persistence technology? Spring can offer comparable features with its Model-and-View approach, and I personally do not need listeners and stuff. And Spring can provide much more than just view rendering. So, if I finally decide to drop Struts and move on, Spring will be the more likely choice than JSF.
  33. Keep in mind, I'm only locking down changes to the HTML structure rendered-- not the data rendered (bean properties, values, etc).
    How you cannot lock the data [items] if you have all these listeners and event handlers? Isn't this a little more constrained than, say, having a bunch of properties sitting on the server, and pulling the properties you need simply by adding another <input> element to your HTML FORM? Despite the hype around page-oriented component model I think that it puts more constraints on view structure and content, than something that was called here "pushing data to the session".

    What you are describing is exactly what JSF offers. You can drop in input components and specify that #{employee.firstName} will be updated along side #{employee.department.managerId}. In terms of web standards, you want to have a consistent structure, encouraged by UI components, so a table, list, input element is structured the same way every time.

    Pushing data to the session is exactly the opposite of what JSF promotes. The old MVC frameworks use page-oriented or action-oriented development where a single Action or command provides data/logic necessary for a pre-defined view.

    In terms of JSF, UI components act as 'mini' actions and forms that can collaborate together within a whole set of specialized views. This promotes greater reusability, such as dropping a shopping cart component into all of your page that will encapsulate a CRUD operations-- view and controller, independent of whatever other components/layouts you are using within a page.
    Am I too far off thinking that JSF is a view persistence technology? Spring can offer comparable features with its Model-and-View approach, and I personally do not need listeners and stuff. And Spring can provide much more than just view rendering. So, if I finally decide to drop Struts and move on, Spring will be the more likely choice than JSF.

    JSF has a unique lifecycle that allows independent components to collaborate in any kind of view-- CRUD/persistence or otherwise. JSF is similar to Spring's MVC in some ways, but I would personally opt for JSF and then use Spring on the backend as in this Javaworld article.
  34. What you are describing is exactly what JSF offers. You can drop in input components and specify that #{employee.firstName} will be updated along side #{employee.department.managerId}. In terms of web standards, you want to have a consistent structure, encouraged by UI components, so a table, list, input element is structured the same way every time.
    Hm, is it right that with JSF I have two choices:
    1. Use template-style pages, where I drop input component on a page and specify the corresponding property name.
    2. Create my own renderer and spit out component presentation in HTML, which will be combined with HTML from other components to build a whole page.
    The second approach with using <div< instead of obsolete <table> would produce the structure, which can be formatted as needed with CSS. I like that. Seems like an easy way to build a portal.
    The old MVC frameworks use page-oriented or action-oriented development where a single Action or command provides data/logic necessary for a pre-defined view.
    And by "predefined view" you mean the template or whatever cast-in-iron JSP page, not the one which is assembled in runtime from component renderers?
    In terms of JSF, UI components act as 'mini' actions and forms that can collaborate together within a whole set of specialized views. This promotes greater reusability, such as dropping a shopping cart component into all of your page that will encapsulate a CRUD operations-- view and controller, independent of whatever other components/layouts you are using within a page.
    Well, in web app view and controller cannot be completely intependent, can it? In desktop app each control can redraw itself when WM_PAINT comes in. All it cares of is the parent HWND and the RECT where to draw itself. In a web app the whole composite page has a single location, so you cannot update page elements individually. But you can reload the whole page and re-render all components according to their current state... So, seems that JSF goes only half-way. It renders components according to their current server state, but it does not synchronize view with model, that is, it does not mark all pages as non-cacheable. I can go back in session history and see the stale page content, and repost to shopping cart again and then fight with double submit. I want to not be able to do that. Struts has Controller.Nocache, and JSF suggests me to use what? filters? If the ideology of JSF is to display the view for the current model state, then support for non-cacheable pages must be built-in. JSF promises to be easier on developers ;)
  35. Hm, is it right that with JSF I have two choices:
    1. Use template-style pages, where I drop input component on a page and specify the corresponding property name.
    2. Create my own renderer and spit out component presentation in HTML, which will be combined with HTML from other components to build a whole page.
    The second approach with using >div< instead of obsolete >table< would produce the structure, which can be formatted as needed with CSS. I like that. Seems like an easy way to build a portal.

    Instead of producing templates or decorators, you emphasize modular development and wire components together within a view. Some frameworks may encourage templating engines that will decorate your product pages with a shopping cart layout, while JSF takes the stance of dropping a shopping cart tag on your page will will render all of the view/controller concerns. That's kind of a key point with JSF's components that I haven't hit on in this thread is that components not only handle presentation aspects, but also can coordinate controller behavior.

    If I have a page where I need to handle 5 different requirements-- search, shopping cart, displaying products, user info, and navigation-- each requirement could be represented as a tag that gets dropped into the page. The display products component can be extended from some other generic display tag your team develops to handle rendering a table and also encapsulate filtering and sorting logic. Again, all that within one component that can be placed along side the 4 other components for that page without worrying if your sorting capabilities are going to conflict with handling searh queries from a different component.

    Also, div tags don't make tables obsolete, they just make table tags obsolete for use in laying out pages. Structually, tables still offer purpose for displaying data sets.

    Along the lines of developing portals, the JSF-RI team is working with portal technologies to allow JSF components to be used within a portal engine.
    Well, in web app view and controller cannot be completely intependent, can it? In desktop app each control can redraw itself when WM_PAINT comes in. All it cares of is the parent HWND and the RECT where to draw itself. In a web app the whole composite page has a single location, so you cannot update page elements individually. But you can reload the whole page and re-render all components according to their current state... So, seems that JSF goes only half-way.

    If you describe it that way, then yes, JSF only goes half way. Just like in Swing, each JSF component takes care of rendering itself within the HTTP request lifecycle which is representative of the model you provide. It would be feasible to develop UI components that use XML RPC to do what you are describing.
    It renders components according to their current server state, but it does not synchronize view with model, that is, it does not mark all pages as non-cacheable. I can go back in session history and see the stale page content, and repost to shopping cart again and then fight with double submit. I want to not be able to do that.

    By default, JSF uses this behavior of no-cache via posts. If you dig, you might find older issues with JSF and caching of views, but the caching is now even highly optimized for application clusters.
    Struts has Controller.Nocache, and JSF suggests me to use what? filters? If the ideology of JSF is to display the view for the current model state, then support for non-cacheable pages must be built-in. JSF promises to be easier on developers ;)

    It will hopefully be a lot easier as the team irons the details based on feedback from developers like yourself.
  36. It would be feasible to develop UI components that use XML RPC to do what you are describing.
    Is JSF team willing to go this way? This will be an "unfair advantage" and will bring web apps closer to RIA.
    By default, JSF uses this behavior of no-cache via posts. If you dig, you might find older issues with JSF and caching of views, but the caching is now even highly optimized for application clusters.
    I deployed Duke's "Guess Number" demo app. The response contains only "Cache-Control: max-age=0" which is insufficient for Mozilla. Contrary, Struts 1.1 has "Cache-Control: no-cache,max-age=0" which is still insufficient for Mozilla if one wants to reload pages when browsing session history. Struts 1.2.4 has "Cache-Control: no-cache,no-store,max-age=0" if Controller.Nocache is set to true in config file, which works great for me.
  37. I deployed Duke's "Guess Number" demo app. The response contains only "Cache-Control: max-age=0" which is insufficient for Mozilla. Contrary, Struts 1.1 has "Cache-Control: no-cache,max-age=0" which is still insufficient for Mozilla if one wants to reload pages when browsing session history. Struts 1.2.4 has "Cache-Control: no-cache,no-store,max-age=0" if Controller.Nocache is set to true in config file, which works great for me.

    Thanks for pointing that out. I will double check with the current demo in CVS that we're working on and make sure that the cache control within the JSPs has been updated. The other catch to be aware of with JSF is that all submissions from a JSF page are POSTs by default which should prevent caching from occuring as opposed to GET operations.
  38. Instead of producing templates or decorators, you emphasize modular development and wire components together within a view. Some frameworks may encourage templating engines that will decorate your product pages with a shopping cart layout, while JSF takes the stance of dropping a shopping cart tag on your page will will render all of the view/controller concerns. That's kind of a key point with JSF's components that I haven't hit on in this thread is that components not only handle presentation aspects, but also can coordinate controller behavior.

    You can do the same thing in WebWork using the Action tag to do page controllers for components, but I wouldn't recommend it as a general design strategy. Have you noticed that Microsoft started here and is now adding a full featured front controller to .NET? Why is Javaland moving backwards?
    If I have a page where I need to handle 5 different requirements-- search, shopping cart, displaying products, user info, and navigation-- each requirement could be represented as a tag that gets dropped into the page.

    In this case you're either building a portal, and you should use a portal server, you're doing too many things on one page, or you're really doing ONE of those things, and the others are small representations that are really part of your decorator for the part doing that one thing.
      The display products component can be extended from some other generic display tag your team develops to handle rendering a table and also encapsulate filtering and sorting logic. Again, all that within one component that can be placed along side the 4 other components for that page without worrying if your sorting capabilities are going to conflict with handling searh queries from a different component.Also, div tags don't make tables obsolete, they just make table tags obsolete for use in laying out pages. Structually, tables still offer purpose for displaying data sets.Along the lines of developing portals, the JSF-RI team is working with portal technologies to allow JSF components to be used within a portal engine.

    Will this be before or after they get it to work with JSP correctly?
    If you describe it that way, then yes, JSF only goes half way. Just like in Swing, each JSF component takes care of rendering itself within the HTTP request lifecycle which is representative of the model you provide. It would be feasible to develop UI components that use XML RPC to do what you are describing.

    But here's the fundamental disconnect: Swing is an API for client applications where the view and model are co-located and there's no (or very little) overhead for calls between the layers. This is fundamentally different in the web world, and applying patterns from the client world is inappropriate.
    By default, JSF uses this behavior of no-cache via posts. If you dig, you might find older issues with JSF and caching of views, but the caching is now even highly optimized for application clusters.

    Posts don't fix things, they just make the user accept that they are re-submitting form values.
    It will hopefully be a lot easier as the team irons the details based on feedback from developers like yourself.
  39. You can do the same thing in WebWork using the Action tag to do page controllers for components, but I wouldn't recommend it as a general design strategy. Have you noticed that Microsoft started here and is now adding a full featured front controller to .NET? Why is Javaland moving backwards?
    If I have a page where I need to handle 5 different requirements-- search, shopping cart, displaying products, user info, and navigation-- each requirement could be represented as a tag that gets dropped into the page.
    In this case you're either building a portal, and you should use a portal server, you're doing too many things on one page, or you're really doing ONE of those things, and the others are small representations that are really part of your decorator for the part doing that one thing.
    Who ever said you couldn't incorporate a front controller (Shale)? I highly doubt this tactic is moving backwards, if anything, it solves a lot of issues with functionally rich applications.

    The claim that you are now doing too many things on one page is silly, even take a site like Amazon.com-- how many concerns/features are expressed within a single view? This is where the current decorator approach fails in my opinion, at least within the Struts realm. It's not just a matter of just flexibly displaying components on the page, but also being able to coordinate updates/logic on subsequent requests with whatever was referenced in the view (a search box along side a paged and sorted data set). If you were to take a framework like struts and do the same thing, it *could* be the developer's responsibility to maintain state/logic for all combinations of the UI from end to end-- rendering and handling the request.
    Will this be before or after they get it to work with JSP correctly?

    From what I've seen in development it's done, and done :-)
    If you describe it that way, then yes, JSF only goes half way. Just like in Swing, each JSF component takes care of rendering itself within the HTTP request lifecycle which is representative of the model you provide. It would be feasible to develop UI components that use XML RPC to do what you are describing.
    But here's the fundamental disconnect: Swing is an API for client applications where the view and model are co-located and there's no (or very little) overhead for calls between the layers. This is fundamentally different in the web world, and applying patterns from the client world is inappropriate.
    That's the beauty of JSF, if company X wants to roll with XML RPC for a very Swing-like application, dispite whatever yours or my opinion my be, they can do so.
  40. By default, JSF uses this behavior of no-cache via posts. If you dig, you might find older issues with JSF and caching of views, but the caching is now even highly optimized for application clusters.
    Posts don't fix things, they just make the user accept that they are re-submitting form values.
    As it turns out, JSF supports separating of input and output via redirect quite nicely. Just one element in the config file and voila!, it redirects from POST to result page, retaining all view information. Another nice thing is that information is not sent back and forth in the stupid _viewstate, but is kept on the server. If you notice, the Guess Number example alredy has backing bean defined with session scope. So the only major thing that does not quite work for me, is that I cannot mark pages as non-cacheable.
  41. But here's the fundamental disconnect: Swing is an API for client applications where the view and model are co-located and there's no (or very little) overhead for calls between the layers. This is fundamentally different in the web world, and applying patterns from the client world is inappropriate.

    If a Swing client can effeciently talk to a web service, then why can't a browser efficiently talk to a JSF server? The two are the same topologically.

    It's possible that a server component encapsules JavaScript. JavaScript can imitate Swing and reduce network requests by handling some clicks locally. Wether or not JSF helps much with JavaScript encapsulation is another question.
  42. Just like in Swing, each JSF component takes care of rendering itself within the HTTP request lifecycle which is representative of the model you provide.

    That seems much like Swinglets. It generates DHTML for the client and binds it to Swing models on the server. It might be nice if Swing models were easily configured in JSF and that JSF had default DHTML renderers for them. Does JSF have predefined widgets or models? JSP doesn't.
  43. Just like in Swing, each JSF component takes care of rendering itself within the HTTP request lifecycle which is representative of the model you provide.
    That seems much like Swinglets. It generates DHTML for the client and binds it to Swing models on the server. It might be nice if Swing models were easily configured in JSF and that JSF had default DHTML renderers for them. Does JSF have predefined widgets or models? JSP doesn't.

    Yeah, that's the basic idea behind JSF-- to have a library of already made components and data models that you can use within your application, read more here.
  44. Let us say we assume JSF has rich UI features.
    But does JSF implementation comes free? The Sun's RI implementation has lots of bugs and as per license it can not be used for commercial product.

    Then You may need to go for Sun's studio creator IDE or IBM's WSAD. Hence it seems that it doesn't come free like STRUTS.

    Comments pls.

    Tans
  45. ...Then You may need to go for Sun's studio creator IDE or IBM's WSAD. Hence it seems that it doesn't come free like STRUTS.Comments pls.Tans
    There is nothing wrong about paying for hight quality components and convenience IMO.

    Unfortunately JSF is less convenient and sound technology than it could be ....

    By the way there are free components for Tapestry and they are easy to use and extend ( No need for buggy StudioCreator )
  46. By the way there are free components for Tapestry and they are easy to use and extend ( No need for buggy StudioCreator )

    This is true of JSF components, too. You don't need StudioCreator or another IDE to use them, they're free, et cetera.
  47. By the way there are free components for Tapestry and they are easy to use and extend ( No need for buggy StudioCreator )
    This is true of JSF components, too. You don't need StudioCreator or another IDE to use them, they're free, et cetera.
    Theoretically I do not need IDE and could use notepad for writing programs....
    We are talking about efficient use of a technology. According to JSF marketing JSF components are meant to be used via JSF aware tools.

    And creating/modification JSF components does not even come close to easiness of components creation in Tapestry...
  48. Of course Tapesty is somewhat getting a good market response with component based event driven web framework.
    But many developers object of its steep learning curve for Tapestry(conceptual documentation).

    It seems for me JSF to Tapetsry as EJB3 to Hibernate (metadata based OR tool).

    It may happen Howard Lewis Ship (creator of Tapestry) being welcomed to the JSF 2 expert group in the same way that Gavin King(creator of Hibernate) was welcomed to the EJB 3 expert group.

    Tans
  49. Let us say we assume JSF has rich UI features.But does JSF implementation comes free? The Sun's RI implementation has lots of bugs and as per license it can not be used for commercial product.

    You can always uses MyFaces if you have issues with Sun's RI.
    Then You may need to go for Sun's studio creator IDE or IBM's WSAD. Hence it seems that it doesn't come free like STRUTS.
    No, you don't need an IDE or a RAD tool for JSF. You can create a complete JSF application with VI if you want to.
  50. This developer mindset, clearly emphasized in Struts is procedural in nature-- the concept of requiring Actions or Command procedures to guide the application flow and data models.
    I found that this is the biggest misconseption and misuse of Struts. Struts does not definde application flow. It knows nothing about the flow. The struts-config.xml does not contain flow definition. All it has is the mapping between target mapping name and a resource. The mapping names are the flow. These names are defined in the application in the same manner as they are defined in JSF app. Things get simple with Struts when you navigate to actions only. Every request must pass through controller - every single one. Flow is scattered over actions, but each action mapping should be considered independent from others. And it should be ready that it might be called in a situation where model or view is not ready, but it must handle it.
    My comments were founded on the common web application developer who creates a series of Actions, using framework X, and pushes data into the scopes provided in order make that data available to some view as specified by the Action called.
    I did not get this statement. Input/transient/output data should be stored somewhere anyway. Whatever you call it: model, viewstate, I/O adapter class, it is some temporary storage which keeps state. View just reads whatever it needs from this object. Where is pushing?
  51. This developer mindset, clearly emphasized in Struts is procedural in nature-- the concept of requiring Actions or Command procedures to guide the application flow and data models.

    Strut's is *not* procedural. Procedural is one Cocoon script using continuations to handle a sequence of rendezvous. A Struts action is no different than a JSF listener. A fault of Struts and not of JSF is that Struts uses abstract base classes and not interfaces. This limitation means that a Struts action object can not also be a page object or a form object.
    While JSF does have Actions or procedures, it doesn't require them within a model 1 architecture.

    It's possible using Struts to develop a model 1 application that has no action classes. The 'type' attribute of the 'action' element is optional in Struts's configuration descriptor.
  52. JSF & Tapestry[ Go to top ]

    JSF is a great idea and I am rooting for it. At this time, I think that the Apache Tapestry framework is more mature, but hopefully JSF will grow into a really fine tool.

    I prefer Tapestry because they made the conscious decision to jetisson JSPs and "start from scratch". I'm not ragging on JSPs, but there is an impedance mismatch between component-based web UI toolkits and JSP.

    I would love to see a non-JSP framework for using JSF... and I think Tapestry could provide a good example of what this might look like.
  53. JSF (Standard) and others (Freedom)[ Go to top ]

    We did discussion here, and I got several new information about standard, JSF is cool and standard. But as we know the process to get standard upgrade process is long.

    with this discussion, about JSF, I got that JCP must be more open or customer oriented to fighting the FUD.

    This is look like JDO right.

    But, I got news from my friend, several company more love to use standard one like JDO and JSF, they said is more safe, but several love Open Source one, we can patch the error, if the vendor is slow in respon.

    In my point right now, because I put JSF in my research area not in production, this is because I need a list to compare, why we should use JSF, what is benefit?

    In my mind, is this related to buy the IDE such as JSF, JDev to expert this?



    Frans -> Velocity Fans
  54. Realistic production sites[ Go to top ]

    Are there any realistic production sites that use JSF that I can go to and check out?

    .V
  55. Realistic production sites[ Go to top ]

    Are there any realistic production sites that use JSF that I can go to and check out?.V
  56. Realistic production sites[ Go to top ]

    There are sample JSF sites:
    http://forum.java.sun.com/thread.jspa?threadID=593580&tstart=0

    That is what I base things on, production sites. They exist now, for the 1st time it appears.

    Now you can compare Tapestry sites to Struts sites to RiA sites...
    Comparing an article does not give me a feeling of saftey, that it's not a 90 prescent solution.
    .V
    boardVU.com
  57. RE: Realistic production sites[ Go to top ]

    FYI, JSF Central will begin running a series on real-world JSF sites this month. As a matter of fact, the sites mentioned in this thread (created by the Institutes of the Innocents in Italy) will be the subject of our first article.

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info
  58. Realistic production sites[ Go to top ]

    Are there any realistic production sites that use JSF that I can go to and check out?.V

    You could check out www.europeanshoppingmall.com, (log in as guest/guest). Its frontend is completely developed in JSF using SUN Java Studio Creator.

    Iwan
  59. Realistic production sites[ Go to top ]

    Are there any realistic production sites that use JSF that I can go to and check out?.V

    I tried to use JSF for a back office application for a CRM and finance solution and evaluated the JSF technology and found it really a good approach for building web applications, unfortunatly Myfaces turned out to be in an unusable state.

    The points about Myfaces (Version 1.0.2) which were anyoing:
    - Is used javascript to both submit a form and for every link withing the JSF, we are working in also in B2C, so this is a real killer, if Javascript is switched off the site does not work at all, I don't really see the point in using Javascript
    - It was really slow: Lists from the database with more than 70 entries took more than 30 seconds to load, even the sql returned in 100ms
    - It was unstable, it was randomly hanging up

    So my experience JSF with Myfaces is not unfortunalty ready to use yet.
  60. Realistic production sites[ Go to top ]

    ...we are working in also in B2C, so this is a real killer, if Javascript is switched off the site does not work at all...

    Surely this is where JSF shines. A server can have both a DHTML render kit and an HTML one, easily detect which kit the user needs, and bind the kit to his session.
    ...I don't really see the point in using Javascript- It was really slow: Lists from the database with more than 70 entries took more than 30 seconds to load, even the sql returned in 100ms- It was unstable, it was randomly hanging up

    Maybe a Microsoft near-monopoly on browsers is a bad thing. Maybe scripting would rock in a competitive market.
  61. Realistic production sites[ Go to top ]

    The points about Myfaces (Version 1.0.2) which were anyoing...Myfaces is not unfortunalty ready to use yet.

    Version 1.0.2 is very old. It's up to 1.0.7 now
  62. Realistic production sites[ Go to top ]

    The points about Myfaces (Version 1.0.2) which were anyoing...Myfaces is not unfortunalty ready to use yet.
    Version 1.0.2 is very old. It's up to 1.0.7 now
    1.0.8
    http://incubator.apache.org/myfaces/docs/gettingstarted.html
  63. I haven't used JSF yet and probably won't use it till will become (if ever) a stardard in production.
    I have heard in the past, from detractors, that JSF has issues with performance compared with current solutions, is that true? or it's just FUD.
  64. I haven't used JSF yet and probably won't use it till will become (if ever) a stardard in production.

    A high-quality implementation of the standard has been around for a while: www.myfaces.org
    I have heard in the past, from detractors, that JSF has issues with performance compared with current solutions, is that true? or it's just FUD.

    It can be slower if badly configured, not not much slower. Works fine for me.
  65. I haven't used JSF yet and probably won't use it till will become (if ever) a stardard in production.
    A high-quality implementation of the standard has been around for a while: www.myfaces.org
    I have heard in the past, from detractors, that JSF has issues with performance compared with current solutions, is that true? or it's just FUD.
    It can be slower if badly configured, not not much slower. Works fine for me.
    Steve,
     What tool are you using to develop JSF apps?
    Mark
  66. I haven't used JSF yet and probably won't use it till will become (if ever) a stardard in production.
    A high-quality implementation of the standard has been around for a while: www.myfaces.org
    I have heard in the past, from detractors, that JSF has issues with performance compared with current solutions, is that true? or it's just FUD.
    It can be slower if badly configured, not not much slower. Works fine for me.
    Steve,&nbsp;What tool are you using to develop JSF apps?Mark

    MyFaces and hand-coding.
  67. MyFaces and hand-coding.
    Thanks.

    Anyone using JSF with Tiles? Or something similar? Tiles is blocking my call to an action (works fine with tiles removed).
  68. I haven't used JSF yet and probably won't use it till will become (if ever) a stardard in production.I have heard in the past, from detractors, that JSF has issues with performance compared with current solutions, is that true? or it's just FUD.

    It more or less depends on the application. JSF seems targeted at intranet sites, or high-bandwidth sites since everything is server-side. Everything (including validation etc) is handled at the server. Using with an internet site this can lead to loads of requests.
    But my experience is that JSF is as fast as a Struts-based or plain JSP based site. I've refactored an application on www.europeanshoppingmall.com in JSF after initially developing it in Struts, that version never went live because a JSF prototype (to figure out JSF) was faster up to a level that I would ask others to look at it than the Struts prototype. So I moved to JSF all together (using SUN Java Studio Creator).

    Iwan
  69. What are your experiences with JSF?
    None, thanks god.
  70. What are your experiences with JSF?
    None, thanks god.

    Nice to see that people are prepared to put effort into a rational technical discussion of the benefits or otherwise of an important multi-vendor standard for Web interface development.

    Still, I guess if you have no experience with it, you can't have much to say?
  71. I plan to read but...[ Go to top ]

    I dunno, I have a hard time with Rick's espousal of JSF. Maybe he's Isaiah, the lone voice of God crying in the wilderness... or maybe he's the author of a number of JSF books, and his constant reference to JSF is self-serving.

    Like I said, though, I plan to read. I think JSF is at the point where there's a lot of smoke in the air about it, but most of it's generated by people who don't really know JSF in depth, or simply don't believe in it.
  72. a calculator is a superficial example and doesnt tackle the web application requirements.

    - tell me what happens if in each new project you have to work with a different JSF component provider? do you have to learn how to use the components again? really?

    - wasn't it supposed to be drag, drop and bind components?
  73. a calculator is a superficial example and doesnt tackle the web application requirements.- tell me what happens if in each new project you have to work with a different JSF component provider? do you have to learn how to use the components again?

    No. Different providers will implement the standard components. I can use exactly the same JSP tags and components in (for example) the myfaces implementation as in the reference implementation. Additional components will work with different providers' implementations (assuming they are written to the standard).
     
    wasn't it supposed to be drag, drop and bind components?

    Well, I don't use drag and drop - I prefer to hand-code (its very quick). But otherwise, that is how it works.
  74. wasn't it supposed to be drag, drop and bind components?

    This is one of the biggest benefits of JSF. Because JSF components come with their own descriptors, your company can develop their own components that can be imported into suites from IBM, BEA, Eclipse, or Sun's Creator and used via drag and drop or with property editors for rapid application development.

    I know that other vendors are already running with the concept of component models within the B2B tier, but an open standard within the UI realm is pretty cool-- imagine being able to download and drag and drop a charting component into your page, or drop in components that take care of all your navigation concerns.
  75. Another problem is how long the updates to the API take. JSF has been on the table for about 2 years and it still isn't as useable as the alternatives. Any developer worth their salt could code a framework with the strengths of JSF much quicker than that. But when you are trying to get some of the biggest IT companies around to agree on specs, its hard to see that it will ever be finished. Another JDO?

    Joking aside, the pull method is really useful, it completes the circle with jsp taglibs for creating reuseable components. But how much longer do we have to wait? The .Net camp with have page-centric and front-controller frameworks and tools long before JSF is ready for public consumption.
  76. wasn't it supposed to be drag, drop and bind components?
    This is one of the biggest benefits of JSF. Because JSF components come with their own descriptors, your company can develop their own components that can be imported into suites from IBM, BEA, Eclipse, or Sun's Creator and used via drag and drop or with property editors for rapid application development.

    I read that the Oracle suite only support Oracle JSF components. Do you know if this is in all JSF IDE?
  77. wasn't it supposed to be drag, drop and bind components?
    This is one of the biggest benefits of JSF. Because JSF components come with their own descriptors, your company can develop their own components that can be imported into suites from IBM, BEA, Eclipse, or Sun's Creator and used via drag and drop or with property editors for rapid application development.
    I read that the Oracle suite only support Oracle JSF components. Do you know if this is in all JSF IDE?

    No, this is not the case by any means. Each component has it's own descriptor that is standardized (like Javadoc) that any IDE can interpret and use in whatever form. While I cannot comment on Oracle's JSF IDE, again the goal is to allow developer components to work with any JSF IDE. I recommend you hop over to java.sun.com and check out Sun Creator. Best Regards
  78. I read that the Oracle suite only support Oracle JSF components. Do you know if this is in all JSF IDE?

    This is not true!

    Oracle JDeveloper let you develop with the standard JSF components as well as any other standard JSF components.

    There is a how-to for using the myFaces components in JDeveloper right now linked from the JDeveloper home page:
    http://otn.oracle.com/products/jdev

    The Oracle ADF Faces Components - is just a very rich set of JSF components that you can use inside JDeveloper or other JSF supporting IDEs.
  79. I know that other vendors are already running with the concept of component models within the B2B tier, but an open standard within the UI realm is pretty cool-- imagine being able to download and drag and drop a charting component into your page, or drop in components that take care of all your navigation concerns.

    VS.NET already has this (for years!), but it's helpful only for sites that have very simple layouts.
  80. JSF Like Chinese food[ Go to top ]

    <sarcasm>
    Why is JSF(which i hate) like Chinese food (which i love) ?

    Cause, both are left when they are half cooked ;-)
    </sarcasm>

    Alright, here is a heated discussion I have been involved with during this week ;-) http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=82&t=000018

    As I was saying in the forum, JSF might be the future. But, it is certainly not the present. We really need an open source JSF based framework over JSF to get the job done. Something like MyFaces components or ADF(i don't know if it is open source)
  81. JSF Like Chinese food[ Go to top ]

    JSF might be the future. But, it is certainly not the present.

    Lots of developers (like me) who are currently coding and deploying JSF projects would disagree with you.
    We really need an open source JSF based framework over JSF to get the job done. Something like MyFaces components

    You have got an open source JSF - that's what MyFaces is. It works fine. I can't see the problem.
  82. JSF Like Chinese food[ Go to top ]

    JSF might be the future. But, it is certainly not the present.
    Lots of developers (like me) who are currently coding and deploying JSF projects would disagree with you.

    Which part would you disagree with?
  83. JSF Like Chinese food[ Go to top ]

    JSF might be the future. But, it is certainly not the present.
    Lots of developers (like me) who are currently coding and deploying JSF projects would disagree with you.
    Which part would you disagree with?

    That it is not the present. As I am using it, and it works fine (for me), then it is a working solution to web coding right now.
  84. JSF Like Chinese food[ Go to top ]

    Anyway, thats my opinion after having worked with it for a project(it was not my decision!!!), if you really feel it flies right now, go ahead use it and be merry :-)

    I'll wait a 3-4 years more until the version 3 of JSF comes up before using it. :-)
  85. JSF Like Chinese food[ Go to top ]

    Anyway, thats my opinion after having worked with it for a project(it was not my decision!!!), if you really feel it flies right now, go ahead use it and be merry :-)I'll wait a 3-4 years more until the version 3 of JSF comes up before using it. :-)

    Personally, I'd be interested in the reason for your opinion - as I am using it heavily, it would be useful to know of problems that others have come across.
  86. Things about JSF[ Go to top ]

    Steve,

    Due to "corporate" reasons, we had to stick to IBM's implementation of JSF (which looks like a cheap wrapper over Sun's RI).

    As I was saying, we really to use something like MyFaces or ADF(i don't know if it is open source) over JSF to get the job done. Looks like you have taken the right path :-)

    I posted a forum link in one of my previous posts. Here it is again. http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=82&t=000018
    In the forum, i listed some of the "limitations" we were facing. This list is just from the top of my head, and some of them surely have work arounds. But, the point I wanted to drive was the inherent limitations of the current spec.
  87. Just a thought...[ Go to top ]

    It would be nice if somebody can list the advantages and disadvantages of JSF, Tapestry, Struts & Velocity. Or at least a comparison matrix between them.

    But I prefer JSF to Tapestry at the moment, albeit my Tapestry knowledge is fairly average.
    Standard or not JSF has enough in it to make me happy developing, but I'd like a good comparison with examples. JSFcentral.com has a good articles between JSF & Struts but not really picking sides... or giving example on speed, drawbacks and look&feel stuff.

    I can compare C to Java, .NET to J2EE or Hibernate to Cayenne and when to use them... but JSF to Tapestry, not to mention when Struts Shale emerges! There's seems to be way too much overlapping (I guess that's what the JSF standard was for)

    I've read Core JavaServer Faces but not Tapestry in Action yet.
  88. Just a thought...[ Go to top ]

    It would be nice if somebody can list the advantages and disadvantages of JSF, Tapestry, Struts &amp; Velocity. Or at least a comparison matrix between them.
    Tapestry is a top notch implementation of a component event driven web framework, while JSF is ... euh ... the specification for a component event driven web framework.

    What makes Tapestry shine is:
    - creation of your own custom components is piece of cake
    - line precise error reporting (no fooling around with jsp's which obfuscate the error reporting)
    - html templates which are viewable in the WHYSIWHYG HTML editor loved by your page designer

    Luckely the JSF spec has also some good points:
    - Backing beans, View handlers, Renderers ... enable you to have a larger part of your java code independent of the presentation technology you've chosen, which I consider as a
     good thing.

    Regarding Struts. Well it all depends of the kind of web applications you're creating, but I think I can be short. For me, Struts is legacy.

    My 2c
  89. Just a thought...[ Go to top ]

    Tapestry is a top notch implementation of a component event driven web framework, while JSF is ... euh ... the specification for a component event driven web framework.

    Koen, what would you recommend to improve JSF?
  90. Just a thought...[ Go to top ]

    Tapestry is a top notch implementation of a component event driven web framework, while JSF is ... euh ... the specification for a component event driven web framework.
    Koen, what would you recommend to improve JSF?

    1) A mechanism to create a custom component based on a template
    2) An alternative ViewHandler which do not use jsp's
    (This topic is pretty well detailed by Hans Bergsten.)

    My 2c
  91. Just a thought...[ Go to top ]

    Tapestry is a top notch implementation of a component event driven web framework, while JSF is ... euh ... the specification for a component event driven web framework.
    Koen, what would you recommend to improve JSF?
    1) A mechanism to create a custom component based on a template 2) An alternative ViewHandler which do not use jsp's(This topic is pretty well detailed by Hans Bergsten.)My 2c

    Thanks Koen!

    If we were to come up with a solution that pushed JSF view definition to another XML file, would you still expect other JSP tags to work with JSF?

    Does Tapestry allow other tag libraries to work along side their own components? Have you run into cases where you thought it would be nice to use JSP tags instead of Tapestry's component model?
  92. Just a thought...[ Go to top ]

    If we were to come up with a solution that pushed JSF view definition to another XML file, would you still expect other JSP tags to work with JSF?
    I guess that 'll be the price we have to pay. Anyhow, having a choice is certainy a good thing.
    Does Tapestry allow other tag libraries to work along side their own components?
    No, that it is not possible. But you can link Tapestry pages with jsp pages and vice versa. Using iFrames you have a workaround to include the jsp-parts.
    Have you run into cases where you thought it would be nice to use JSP tags instead of Tapestry's component model?
    It' s a price I'm willing to pay ;-)
  93. notes from nonbeliever[ Go to top ]

    Hello world is always look simple and good, and JSF is no exception.

    >>The first myth about JSF is that you need a WYSIWYG drag-and-drop tool to do JSF development
    I guess this is misinterpretation of complaints: we need a GUI tool for UI prototyping and it is equal pain with Strut development: there is no way to preview a page or a fragment. JSF requires a new tool to build JSF UIs while Tapestry requires nothing but HTML editor. JSF still requires developers to redo HTML design in JSF. No relief here – JSF did not address developer’s need.

    >>To mimic JSF's default error handling and validation you would have to configure Struts to use the validator framework or implement the equivalent in the validate method on an ActionForm.
    That is FUD. Validation in Struts is not difficult and provides more control over validation: it allows require or not certain field depending on operation(delete or create or update). Are we building something real?

    >>my estimate is that it would take at least twice the effort to create the Struts version of the simple JSF application you built here.

    I set Ant +XDoclet and then it will be a breeze to build. Again – initial ‘convenience’ vs long time benefits and timesavings.

    >>most all-encompassing myth about JSF development is that it's just plain difficult.
    JSF is difficult conceptually because of mixture of everything in it: JSF set of tags, old JSP snippets and JSP-Taglibs which may or may not work on some weird order. All that might make perfect sense for JSF inventors but IMO that makes same sense as madman fantasies.

    - JSF abstract developers from HTML(or whatever) – GOOD, but reality is that some people need to tweak resulting output and JSF looks too abstract here.
    - JSF has no notion of component UI templates – I have seen plenty of components doing bunch of “println”s – sweet.

    Note: Frameworks can be characterized by typical misuse and overall convenience. JSF does not seem to provide overall convenience (or substantial advantages over competitors) and encourages misuse and misinterpretation – not a good sign.
  94. notes from nonbeliever[ Go to top ]

    JSF requires a new tool to build JSF UIs while Tapestry requires nothing but HTML editor. JSF still requires developers to redo HTML design in JSF.

    I have never really understood this argument. Who says that HTML is the ultimate in web design? Good web design will involve a combination of HTML, CSS and JavaScript. You can consider JSF tags to be an abbreviation of these.
    Validation in Struts is not difficult and provides more control over validation: it allows require or not certain field depending on operation(delete or create or update).

    Struts can't provide more control over validation when there is no limit to the validation that can be performed by either validators or validation methods in JSF.
    JSF is difficult conceptually because of mixture of everything in it: JSF set of tags, old JSP snippets and JSP-Taglibs which may or may not work on some weird order.

    The idea of JSF is you should avoid old JSP snippets. You can use them, but the appropriate place for the logic is in the backing beans or controller classes, not in JSP code.
    JSF does not seem to provide overall convenience (or substantial advantages over competitors)

    Personally, I have found huge convenience advantages - it is very fast to develop with and test.
  95. notes from nonbeliever[ Go to top ]

    JSF requires a new tool to build JSF UIs while Tapestry requires nothing but HTML editor. JSF still requires developers to redo HTML design in JSF.
    I have never really understood this argument. Who says that HTML is the ultimate in web design? Good web design will involve a combination of HTML, CSS and JavaScript. You can consider JSF tags to be an abbreviation of these.
    Plain JSP taglib could be combination of HTML, CSS and JavaScript too. Could it?

    Again and again: conceptually all components are equal Applet, ActiveX, OCX, Bean, Taglibs, JSF, Tapestry, Echo.

    Evil is in details. I really suggest you creating couple of semi-real projects in Echo and Tapestry. Maybe then you will understand.
  96. notes from nonbeliever[ Go to top ]

    JSF requires a new tool to build JSF UIs while Tapestry requires nothing but HTML editor. JSF still requires developers to redo HTML design in JSF.
    I have never really understood this argument. Who says that HTML is the ultimate in web design? Good web design will involve a combination of HTML, CSS and JavaScript. You can consider JSF tags to be an abbreviation of these.
    Plain JSP taglib could be combination of HTML, CSS and JavaScript too. Could it?

    yes, but plain JSP taglibs aren't components with events bound to Java classes.... which is the point of JSF.
    Again and again: conceptually all components are equal Applet, ActiveX, OCX, Bean, Taglibs, JSF, Tapestry, Echo.Evil is in details. I really suggest you creating couple of semi-real projects in Echo and Tapestry. Maybe then you will understand.

    Perhaps, but all components aren't equal in practice. There is one component architecture that is a cross-platform multi-vendor standard with many companies providing GUI design tools and component libraries, and many companies providing implementations. That component architechure is JSF. That is a substantial advantage, and is why I use JSF.
  97. notes from nonbeliever[ Go to top ]

    There is one component architecture that is a cross-platform multi-vendor standard with many companies providing GUI design tools and component libraries, and many companies providing implementations.
    Vendors are much happier to support most obscure and meaningless technologies because those create DEMAND for their services. Consumers must keep them in check to preserve sanity.
  98. notes from nonbeliever[ Go to top ]

    Vendors are much happier to support most obscure and meaningless technologies because those create DEMAND for their services. Consumers must keep them in check to preserve sanity.

    That's true :-) But unlike other frameworks from vendors that are specific to them, this one is being produced through a standard JSR that lots of people are working on who aren't part of any product vendor.
  99. notes from nonbeliever[ Go to top ]

    You agreed, but it looks like my message did not quite came across.
    What I was saying is that it is not necessary for vendors to support only their own product or standard. They have infrastructure to build and will comply with whatever next BIG thing; therefore any kind of nonsense technology is beneficial for them.

    For example NON promoting healthy and sustainable lifestyle is equally beneficial for 99% of businesses.


    True believers are easily manipulated by participants in the silent plot.
  100. notes from nonbeliever[ Go to top ]

    Vendors are much happier to support most obscure and meaningless technologies because those create DEMAND for their services. Consumers must keep them in check to preserve sanity.
    That's true :-) But unlike other frameworks from vendors that are specific to them, this one is being produced through a standard JSR that lots of people are working on who aren't part of any product vendor.

    Thank goodness for EJBs!
  101. notes from nonbeliever[ Go to top ]

    Perhaps, but all components aren't equal in practice. There is one component architecture that is a cross-platform multi-vendor standard with many companies providing GUI design tools and component libraries, and many companies providing implementations. That component architechure is JSF. That is a substantial advantage, and is why I use JSF.

    Do you also use Entity beans?
  102. notes from nonbeliever[ Go to top ]

    Perhaps, but all components aren't equal in practice. There is one component architecture that is a cross-platform multi-vendor standard with many companies providing GUI design tools and component libraries, and many companies providing implementations. That component architechure is JSF. That is a substantial advantage, and is why I use JSF.
    Do you also use Entity beans?

    No. I use JDO. Another multi-vendor standard.
  103. notes from nonbeliever[ Go to top ]

    No. I use JDO. Another multi-vendor standard.

    Ah, so *you* are the one.
  104. notes from nonbeliever[ Go to top ]

    No. I use JDO. Another multi-vendor standard.
    Ah, so *you* are the one.

    There is a myth that JDO isn't much used. If you consider that there are dozens of implementations, and commercial vendors are investing (and making) considerable amounts of money in JDO, and there are over 15,000 members of the jdocentral site alone, this myth is obviously nonsense.

    I can see a parallel situation may arise with JSF - it could become widely used but without many developers realising this.
  105. notes from nonbeliever[ Go to top ]

    No. I use JDO. Another multi-vendor standard.
    Ah, so *you* are the one.
    There is a myth that JDO isn't much used. If you consider that there are dozens of implementations, and commercial vendors are investing (and making) considerable amounts of money in JDO, and there are over 15,000 members of the jdocentral site alone, this myth is obviously nonsense.I can see a parallel situation may arise with JSF - it could become widely used but without many developers realising this.

    That myth is a common one IMHO between the consulting/open source world, and those of us who have more permenant positions.

    There are completely different sets of requirements depending upon who is making the build vs. buy decisions, or what your product target market is.
  106. g machine[ Go to top ]

    oh,god,
        trust me,jsf will be the money making machine of big company like IBM,SUN etc.
  107. notes from nonbeliever[ Go to top ]

    there are over 15,000 members of the jdocentral site alone, this myth is obviously nonsense.

    Uh, what "jdocentral" site are you talking about? If you mean JDOCentral.com, it shows there are 1697 members (http://jdocentral.com/forums/index.php). The entire site routinely goes days without a post. Many forums have been inactive for months. Moreover, SPAM (like smoking cessation ads) are routinely on there for weeks without being cleaned up. Further, I find a huge majority of the posts are from vendors, there seems to be a very small ratio of actual "users".

    You're using an extremely poor example of JDO adoption, and are exaggerating the numbers by an order of magnitude on top of that.

     - Don
  108. notes from nonbeliever[ Go to top ]

    there are over 15,000 members of the jdocentral site alone, this myth is obviously nonsense.
    Uh, what "jdocentral" site are you talking about? If you mean JDOCentral.com, it shows there are 1697 members (http://jdocentral.com/forums/index.php). The entire site routinely goes days without a post. Many forums have been inactive for months. Moreover, SPAM (like smoking cessation ads) are routinely on there for weeks without being cleaned up. Further, I find a huge majority of the posts are from vendors, there seems to be a very small ratio of actual "users".You're using an extremely poor example of JDO adoption, and are exaggerating the numbers by an order of magnitude on top of that.&nbsp;- Don

    See front page of that site: 'Congratulations to our 15,000th member'. The number of people actively on forums is a measure of the quality of the site, but the number of people who have registered at any time is a better indication of the number of JDO developers.

    Let's look at another site: The free JDO product - JPOX. There was mention on a previous thread of several thousand downloads per month. This was being used to illustrate that JPOX use was only a fraction of the size of Hibernate use. However, combine this with the many thousands of developers who use other JDO products, and you end up with a likely number of JDO developers which is a significant proportion of Hibernate use. Hibernate is a great (well-deserved) success. Would you classify an technology that has, say, 30-40% of that use (if someone has actual JDO use figures, I would be interested) a failure? Of course not. (Even 10% of Hibernate's use would indicate that JDO was a significant technology, used by thousands of developers).
  109. notes from nonbeliever[ Go to top ]

    See front page of that site: 'Congratulations to our 15,000th member'.

    I did see that. And it was just as hilarious when it was posted as it is now. I'm surprised someone actually believed that number given the actual number, prominently displayed on the bottom of the forum, absolutely proves otherwise. Oh the hilarity of the creative marketing department.

    "Tens of thousands".

    LOL.

     - Don
  110. notes from nonbeliever[ Go to top ]

    See front page of that site: 'Congratulations to our 15,000th member'.
    I did see that. And it was just as hilarious when it was posted as it is now. I'm surprised someone actually believed that number given the actual number, prominently displayed on the bottom of the forum, absolutely proves otherwise. Oh the hilarity of the creative marketing department."Tens of thousands".LOL.&nbsp;- Don

    Fine. I just registered became member number 18,492. You realise that registering for the forums is a different process for registering on the site?

    Do you have evidence that JDOCentral is falsifying information?
  111. Poor example[ Go to top ]

    You're using an extremely poor example of JDO adoption

    Yes, I agree. It would make more sense to go to the actual forums of JDO products, like Open Access, Kodo, and JPOX. It'd be very enlightening for people who think that JDO has a small number of users.
    and are exaggerating the numbers by an order of magnitude on top of that

    I doubt it.

    On another note, I really do wish TSS would allow people to specify their employer. That way we could see "Donald Smith (Oracle croney)", attached to these biased posts, instead of simply, "Donald Smith".

    God bless,
    -Toby Reyelts
  112. notes from nonbeliever[ Go to top ]

    No. I use JDO. Another multi-vendor standard.
    Ah, so *you* are the one.
    There is a myth that JDO isn't much used. If you consider that there are dozens of implementations, and commercial vendors are investing (and making) considerable amounts of money in JDO, and there are over 15,000 members of the jdocentral site alone, this myth is obviously nonsense.I can see a parallel situation may arise with JSF - it could become widely used but without many developers realising this.

    Bawhahaha. The JDOCental site "alone" is pretty much dead. It is, as other has pointed out, just hilarious to see the 15,000 count. The forums are dead. The commercial vendors have invested a bare minimum of effort.

    This is not a myth. JDO is practically dead.
  113. notes from nonbeliever[ Go to top ]

    The forums are dead. The commercial vendors have invested a bare minimum of effort.This is not a myth. JDO is practically dead.

    Have you actually looked at the forums for JDO vendors? They are lively and very active. I think that companies like Solarmetric, Libelis and Versant would consider your statement about 'a bare minimum of effort' to be outrageous.

    I don't know what evidence you have that 'JDO is practically dead'. Perhaps you would care to post it. It reminds me of the frequent 'Java is doomed' posts on Slashdot!
  114. notes from nonbeliever[ Go to top ]

    Personally, I have found huge convenience advantages - it is very fast to develop with and test.

    Could not agree more. There is a learning curve, as with all new things, but it works quite well for me.
  115. notes from nonbeliever[ Go to top ]

    Ok,
      Anyone used Tiles + JSF (Not Struts though)? A good example with calling of JSF Actions?
  116. notes from nonbeliever[ Go to top ]

    Hello world is always look simple and good, and JSF is no exception.>>The first myth about JSF is that you need a WYSIWYG drag-and-drop tool to do JSF developmentI guess this is misinterpretation of complaints: we need a GUI tool for UI prototyping and it is equal pain with Strut development: there is no way to preview a page or a fragment. JSF requires a new tool to build JSF UIs while Tapestry requires nothing but HTML editor. JSF still requires developers to redo HTML design in JSF. No relief here

    JSF is ahead of its time. If anything, and I'm going out on a limb here, is that it promotes proper HTML development through web standards. I recommend that you read a blog entry of mine on the future of web application UIs.
    – JSF did not address developer’s need.>>To mimic JSF's default error handling and validation you would have to configure Struts to use the validator framework or implement the equivalent in the validate method on an ActionForm.That is FUD. Validation in Struts is not difficult and provides more control over validation: it allows require or not certain field depending on operation(delete or create or update). Are we building something real?

    I recommend that you take an honest look at JSF validators on your own before making statements like that.
    >>most all-encompassing myth about JSF development is that it's just plain difficult.JSF is difficult conceptually because of mixture of everything in it: JSF set of tags, old JSP snippets and JSP-Taglibs which may or may not work on some weird order. All that might make perfect sense for JSF inventors but IMO that makes same sense as madman fantasies.

    Madman programmers are probably the *coolest* people you will ever meet. Check out my previous post in this thread on JSF components vs. using control tags (JSTL). You may ask, what about the special case? In the next rendition of JSF (1.2) that we are openly developing, it will include a few fixes that will make JSF act a little more like what you expect it to. Trust me, EG members are expressing the same concerns as you are and they are being fixed promptly.
    JSF abstract developers from HTML(or whatever) – GOOD, but reality is that some people need to tweak resulting output and JSF looks too abstract here.- JSF has no notion of component UI templates – I have seen plenty of components doing bunch of “println”s – sweet.

    Again, I recommend you read my blog post that I linked above. JSF does take HTML out of the JSP page, but with good reason-- which may not be okay with everyone. UIComponents work to remove the need to use templating technologies by simplifying the content of the page (go from 100-200 lines of JSP code, broken up and included across some templating engine-- to maybe 20 lines of JSF tags that declare your specific JSP page). A JSF component for your menu, a JSF component for your shopping cart, a JSF component that can be used for displaying products or orders, etc. A couple JSF tags vs. 40-50 lines of control statements intermingled with HTML code.

    You may point out, well, we are just moving that complexity into Java code-- but where is your business logic expressed? In the view? No, why not levrage being able to call your business methods directly in a type safe manner instead of replicating variable/name guessing games in the view?

    It is very different and it's not for everyone.
  117. notes from nonbeliever[ Go to top ]

    missed that point, it makes widens the gap between design and development teams. there aren't many designers that would want to work with jsf compared to tapestry.
  118. notes from nonbeliever[ Go to top ]

    missed that point, it makes widens the gap between design and development teams. there aren't many designers that would want to work with jsf compared to tapestry.

    Again, read my blog entry on web application development. The designer should design with CSS. Our company has been migrating to that style of development-- along with Yahoo, ABC News, Mapquest, Sprint, FastCompany, and ESPN.

    It does create seperation, great!
  119. notes from nonbeliever[ Go to top ]

    straight up, front-end coding isn't my forte, but isn't CSS even more problematic (cross-browser issues) than plain html?
  120. notes from nonbeliever[ Go to top ]

    straight up, front-end coding isn't my forte, but isn't CSS even more problematic (cross-browser issues) than plain html?

    No, it's not the issue that it was years ago. CSS is so much more standardized now and that's why you are seeing such big companies committing to it.

    Another note.
  121. notes from nonbeliever[ Go to top ]

    straight up, front-end coding isn't my forte, but isn't CSS even more problematic (cross-browser issues) than plain html?
    CSS is supported pretty well by MSIE 6 (released 4 years ago!) in STRICT mode, and by Mozilla/Firefox (for quite a long time too). There is no reason to use plain HTML anymore.

    See www.csszengarden.com or www.alistapart.com for inspiration ;)
  122. notes from nonbeliever[ Go to top ]

    missed that point, it makes widens the gap between design and development teams. there aren't many designers that would want to work with jsf compared to tapestry.

    That is a matter of opinion. After all, they are just tags. Its simple to XSLT them to HTML for previewing if necessary, or just use a JSF design tool.

    Who wants designers coding logic? Why should the size of the gap be important?
  123. notes from nonbeliever[ Go to top ]

    ... That is a matter of opinion. After all, they are just tags. Its simple to XSLT them to HTML for previewing if necessary, or just use a JSF design tool.Who wants designers coding logic? Why should the size of the gap be important?

    Nobody wants designers coding logic - but I too have learned from experience that Tapestry allows coders and designers to work together more effectively.

    Not that I have used JSF. Only someone who has used both JSF and Tapestry in production can fairly compare them, and those people seem to be backing Tapestry.
  124. notes from nonbeliever[ Go to top ]

    Nobody wants designers coding logic - but I too have learned from experience that Tapestry allows coders and designers to work together more effectively.Not that I have used JSF. Only someone who has used both JSF and Tapestry in production can fairly compare them, and those people seem to be backing Tapestry.

    Out of curiosity, could you clarify how designers and programmers are collaborating within the same document? Nobody wants designers handling business logic, and it seems to be intertwined within Tapestry via scripting.

    Also, John brought up a point of focus with JSF vs. Tapestry, do you have any others in being able to compare the two specifically?

    Thanks!
  125. notes from nonbeliever[ Go to top ]

    Nobody wants designers handling business logic, and it seems to be intertwined within Tapestry via scripting.

    This level of ignorance regarding Tapestry basics is not tolerable. RTFM
  126. notes from nonbeliever[ Go to top ]

    Nobody wants designers handling business logic, and it seems to be intertwined within Tapestry via scripting.
    This level of ignorance regarding Tapestry basics is not tolerable. RTFM

    Apologies, I mean using OGNL for method calls within the HTML document. The same consequences apply with using JSTL in a model 1 architecture.

    Konstantin, there's no need to be so bellicose. I'm not forming an opinion on anything, just inquiring for more information :-)
  127. notes from nonbeliever[ Go to top ]

    Apologies, I mean using OGNL for method calls within the HTML document. The same consequences apply with using JSTL in a model 1 architecture.Konstantin, there's no need to be so bellicose. I'm not forming an opinion on anything, just inquiring for more information :-)
    OGNL on html is a shortcut, it does not have to be there, just jwcid. That makes cleanest HTML I ever seen.

    Having an opinion is no harm, quite contrary. Just do not carve it in stone and assume that it _might_ be wrong. Listening opponents and studying competitors does nothing but GOOD.
  128. notes from nonbeliever[ Go to top ]

    Konstantin, there's no need to be so bellicose.

    I am not, just a bit sick of leveled and watered down sentences.
    “just inquiring for more information”: How am I supposed to say that statement is so obviously wrong that everybody who just once glanced at Tapestry propaganda will not make it? :)
  129. notes from nonbeliever[ Go to top ]

    I recommend that you take an honest look at JSF validators on your own before making statements like that.
    Take honest look at your article and say if your validation example provides compelling case for Struts developers. Is not your article supposed to provide vivid and compelling reasons?
     JSF does take HTML out of the JSP page, but with good reason-- which may not be okay with everyone.
    If you are saying that it is OK for JSF to push HTML/wtfMarkup into Java code than thank-you-very-much JSF is definitely not for me.
  130. notes from nonbeliever[ Go to top ]

    JSF does take HTML out of the JSP page, but with good reason-- which may not be okay with everyone. UIComponents work to remove the need to use templating technologies by simplifying the content of the page (go from 100-200 lines of JSP code, broken up and included across some templating engine-- to maybe 20 lines of JSF tags that declare your specific JSP page). A JSF component for your menu, a JSF component for your shopping cart, a JSF component that can be used for displaying products or orders, etc. A couple JSF tags vs. 40-50 lines of control statements intermingled with HTML code.You may point out, well, we are just moving that complexity into Java code--

    Yes, componentization is nice. Many frameworks have it. Some of us even bothered to make it possible for the user to customize the output of the components by using templates that the components render when used. This makes things much easier and more maintainable because in the JSF world you have to write a new Renderer class with a bunch out println() statements to get a customized view.
  131. FUD?[ Go to top ]

    If there is any FUD about JSF it is because of its history and the performance of its "expert" group. JSF, a fairly simple and straightforward component API was about two years late and provided almost no ready to use components. No wonder people are slow to adopt it. In the time it took to wait for the JSF specification let alone a stable implementation it anyone could have build a couple of corporate gui rich transactional web sites using tcl and good old copy and paste....
  132. Nice Article[ Go to top ]

    Its certainly a good article, gave convincing explanations for the most common disbelief about JSF..
  133. What i don't like in JSF[ Go to top ]

    After using Struts and Tapestry, i played with JSF. And it seams like unfinished and unconsidered product.

    1. I can use actions only for CommandLink wich submit current page, in tapestry i can make action listener for DirectLink.

    2. I don't like writting custom components, i have to create a component + custom tag for it. In tapestry i only create components. Also in jsf components you have to write html in servlets style, or i don't know how to write template for components.

    3. No action for form submit, only for buttons or command link.

    4. Poor language expression after ognl which i used in tapestry.

    5. Poor default component library. Also i like conditional and foreach elements in tapestry, in sun jsf i don't have ones only ugly rendered attribute on components.

    6. Some strange behavior, for exm.
    <h:inputTextarea value="#{errorLogging.errorContent}" rendered="#{errorLoggin.initialized}" ...>
    in java bean method
    public String getErrorContent() throws IOException {
    ....
    }
    i have NPE if initialized equals false
    So i think if initialized equals false then #{errorLogging.errorContent} isn't invoked, but this method is invoked.
    Why ? I don't know, so now i have to write such code:
    public String getErrorContent() throws IOException {
     if(isInitialized()) {
      ....
     } else {
       return "";
     }
    }

    7. And etc.

    Now i see 2 main ways for java project: struts+tiles+velocity or tapestry. IMHO.
  134. XMLC and Tapestry Page rule![ Go to top ]

    Sofar I only see 2 presentation view types in XML families (HTML, WML, cHTML, ...) with future: XMLC and Tapestry Page. Add "id" in your XML files, that's it folks! No more no less! No mix with codes, preview with standard browsers, no taglibs, no extra tools, separation of designer and developer, etc...

    JSP which is the main presentation view type used by JSF has no future... I know that you can use JSF with other presentation view types but I just don't see any implementations, so for me JSF + JSP == useless presentation framework type + useless presentation view type.

    There are already a lot of reasons why JSP (so JSF) are useless so I don't need to repeat here...

    In XMLC it is very easy to do your own components:
    - Design your XML component which is mostly an HTML table (just like a portlet). Use CSS, etc. whatever you like... Put formular, button, text field etc... C'mon folks who want to build their own buttons, text field in HTML or WML? You can only use the standard components... :-)
    - Mark the table with an "id".
    - Compile the XML file to get a Java DOM file.
    - From here you can use OO methods (inheritance, method override, ...) to extend it your Java DOM component.
    - Plug it to your main XML file in the runtime wherever you like! Reuse it everywhere just like a portlet :-)

    In combination with a good presentation framework you'll have everything you need... :-)

    And before we are going to discuss about what presentation view and framework are the best, we need to go one level higher. Please make your own AndroMDA transformation cartridge(s) to build the presentation layer from one PIM.

    Wouter from AndroMDA team has done a great cartridge for Struts + JSP. I've done a simple cartridge for EAF + XMLC. Ingo is doing a cartrige for Eclipse RCP + SWT. Maybe the JCP team for JSF would do a cartridge for AndroMDA as well? So we can build from one "similar" PIM different kind of presentation layer implementations? And everybody can compare the advantages of each implementations?

    Cheers,
    Lofi.
  135. The same example app in Struts[ Go to top ]

    Rick HighTower:
    To build the same example app in Struts you would need two action classes for the two buttons, each requiring its own set of action mappings. You would also need an action mapping to load the first page, at least assuming you were following the Model 2 recommendation. To mimic JSF's default error handling and validation you would have to configure Struts to use the validator framework or implement the equivalent in the validate method on an ActionForm. You would also have to either declare a DynaValidatorForm in the Struts config or create an ActionForm and override the validate method or use the subclass of the ValidatorForm with the hooks into validator framework. And finally, you would probably need to configure some forwards (possibly two sets for each action) or global forwards to be used by all the actions.

    For this application I would have two action mappings (actually, I would have one, but synchronizing these two pages with the model each time a user clicks Back or Forward is too much for this small app, so I will put aside my favorite "no-store" header). No direct access to pages, so calc.do would show input page and result.do would show result page, both actions use the same form bean with session scope (just like the backing bean in this JSF example). The bean would store fields' intermediate data, error messages and a state, which would be "input" or "result".

    #1 When calc.do is called via a link or via address bar or via redirection, browser issues GET to the server. Calc Action forks on request type. If request type is GET, it shows the input page using current form data whatever it might be. By default fields are empty and there are no errors. But if redirected from itself, the form bean would contain previous field values and error messages.

    #2 Enter data and click Add or Multiply. Both buttons submit to the same calc.do mapping with cmd="Add" or cmd="Mult" parameter in the request. Action checks that the request method is POST (actually it is checked earlier in form.reset() method), which means that new input data was submitted. Existing errors are cleared. Values are validated, but form.validate() does not return error object, istead it stores errors in the form bean. If there are errors, action redirects to itself, goto #1. If there are no errors, result is stored in the form bean and action redirects to result.do, goto #3.

    #3 result.do displays value from the form bean.

    I might also add Clear button to clear the values and the error messages.

    Error handling is not a big deal, but I prefer to use String and boolean types only, (because HTTP cannot submit anything but strings anyway), and to validate every field manually. Also, client-side Javascript is really great for basic range or type validation.
  136. The bean would store fields' intermediate data, error messages and a state, which would be "input" or "result".
    This is not needed here since I would use two actions.
  137. The bean would store fields' intermediate data, error messages and a state, which would be "input" or "result".
    This is not needed here since I would use two actions.
    Shoot, no editing. I mean, "input" or "result" state is not needed.
  138. The same example app in Struts[ Go to top ]

    Rick HighTower: ... And finally, you would probably need to configure some forwards (possibly two sets for each action) or global forwards to be used by all the actions.

    Doesn't a truly stateless view philosophically beg to be reached only by global forwards? What's the point of a stateless view, if the developer declares from where it can be reached?
  139. flexible JSF is NOT PORTABLE[ Go to top ]

    yes, any easy and flexible implementation is not portable ,but it rely on vendor specific extensions,
    jsf in websphere portal is easy and flexible,try to port to weblogic and u will discover the fact yourself,it is non portable,even try it with the reference implementation tomcat and pluto,and see how it fail misrably
    jsf in oracle adf and websphere depend heavily on vendor extensions provided for flexibility and convinience that will lock u to that vendor
  140. page composition with tiles is a nightmare
    and with sitemesh is impossible (for real world page not the single form page u can demonestrate)
    only includes are possible so jsf withdraw us five years back
    please dear consider real world example with portable solution
  141. page composition with tiles is a nightmare and with sitemesh is impossible (for real world page not the single form page u can demonestrate)only includes are possible so jsf withdraw us five years back...

    Maybe the Java Portlet Specification has conquered these problems? I'm curious why you think Tiles is so bad? It seems very flexible at polymorphism.

    There are a variety of page composition mechanisms, and I've never seen a scientific comparison of client includes vs server includes, frames vs DHTML mutation, sequential preparation vs parallel preparation, etc.
  142. Most of you have probably noticed that inferior technology breeds fud while great and accessible technology usually doesn't.

    IMHO, JSF is dead within a year or two.
  143. Most of you have probably noticed that inferior technology breeds fud while great and accessible technology usually doesn't.IMHO, JSF is dead within a year or two.

    Well, IBM, Sun, Borland and Oracle and many others disagree. I would imagine they have put a lot of money and research into this matter.
  144. I'm Convinced[ Go to top ]

    After reading Mr. Hightower's article I'm convinced that JSF is just as bad as I thought it was beforehand.

    Mr. Hightower wants to dispell FUD, but JSF seems to be all about FUD.

    Mr. Hightower says "As previously mentioned, there are three big myths about JSF and the first is that it requires WYSIWYG tools to work. Well, that's bunk."

    The reason people make the association between JSF and WYSIGWYG tools is because Sun makes the association.
    Sun states the following at their site "JavaServer Faces Technology was designed for use inside of tools from the very beginning." ( http://java.sun.com/j2ee/javaserverfaces/jsfintro.html )

    So who is creating FUD here?

    Someone pointed out that it took two years to get the JSF spec out, (or to the point that it is currently at). This does seem like a long time. Maybe those developing the spec were waiting for a new version of .NET to come out so they could rip off more ideas from it. I asked on another thread at this site, "Why don't I just move to .NET now instead of bothering with JSF?". No one provided me with a good answer and I don't really expect one here. JSF looks to me to be basically a rip off of .NET's whole Web Forms architecture which I've never been a big fan of. But if JSF becomes very popular and I end up being more or less forced to use it might make more sense for me to move to .NET. You can say a lot of awful things about Microsoft, and Lord knows I've said plenty, but they do make a good development environment. If Sun wants to do things the Microsoft way, well, I might as well go all the way.

    If JSF is as easy as Mr. Hightower says it is why does he make the following comment in his article?

    "And with that -- whew! -- you're over the biggest hump of coding a JSF application."

    If it' so easy why is there a "hump"? In fact he makes it sound difficult with that "whew".

    You can say whatever you like, but by repeating it again and again it doesn't mean that it's true. From Mr. Hightower's article and other ones I have read JSF looks really complicated. Why don't people admit that there is a significant learning curve instead of going on about how much better and easier it is than Struts? There is nothing wrong with JSF being complicated if it's better than what it replaces. The problem is that I can't really see how JSF is that much better than Struts. According to the JSF FAQ at Sun' site the main advantage is that JSF has a "flexible, extensible UI component model". But on the other hand Struts has a more mature controller architecture, in fact there is no access to the controller in JSF. Struts has a great layout manager (Tiles) and a superior validation framework.

    It seems to me, and please correct me if I'm wrong but JSF looks like we have a tight binding between a JSP and a "Backing Bean". Without access to the controller I really don't like this architecture very much. Access to the controller gives me some application wide flexibility that I just don't see in JSF.

    One other thing that makes me very suspicious of JSF is how it always seems to be presented as so much better than Struts. No documentation I've read including Mr. Hightower's article has been able to explain to me why. Is it because of the UI component model? If that's all you got, well then you've got to do better, I don't spend most of my time developing the UI. What has JSF got to make my life easier when it comes to building my app as a whole? Not too much unless you consider taking access to the controller away from me an advantage.

    So in conclusion, I can see advantages to using Struts over JSF. The advantages to JSF (UI components) don't really impress me that much and if I'm forced to do things the JSF way, (which looks a lot like the Microsoft way), why don't I just go all the way and start using .NET to take advantage of Microsoft's great development environment? I'll bet that Microsoft reads the JSF spec and is just laughing and laughing at the whole Java community.
  145. I'm Convinced[ Go to top ]

    Mr. Hightower says "As previously mentioned, there are three big myths about JSF and the first is that it requires WYSIWYG tools to work. Well, that's bunk."The reason people make the association between JSF and WYSIGWYG tools is because Sun makes the association. Sun states the following at their site "JavaServer Faces Technology was designed for use inside of tools from the very beginning." ( http://java.sun.com/j2ee/javaserverfaces/jsfintro.html )So who is creating FUD here?

    There is a clear difference between something that is designed for use inside of tools and something that requires such tools. Saying the first is not the same as saying the second. That article. provides the full source code of a faces application, which can be (obviously) hand-edited.
    But on the other hand Struts has a more mature controller architecture,

    True.
    in fact there is no access to the controller in JSF.

    Not true. JSF is extremely customisable. You can plug in your own code to control almost anything. This is how projects such as Shale and jsf-spring work.
    Struts has a great layout manager (Tiles) and a superior validation framework.

    You can use Tiles with JSF. As far as I can tell there there is no validations that can be done in Struts that you can't do in JSF.
    One other thing that makes me very suspicious of JSF is how it always seems to be presented as so much better than Struts. No documentation I've read including Mr. Hightower's article has been able to explain to me why. Is it because of the UI component model?

    1. Many developers like me really like the event-driven way of coding. I find it intuitive and fast to develop.

    2. JSF is already building up a community of component developers.
    So in conclusion, I can see advantages to using Struts over JSF.

    I agree that Struts has features that would be good for JSF. That is the point of the Jakarta Shale project.
  146. Thanks...but you are creating more FUD[ Go to top ]

    FUD is created by misunderstanding.
    You are creating misunderstanding.

    I said:
    "...in fact there is no access to the controller in JSF."

    You said:
    "Not true."

    Sun says:
    "JavaServer Faces technology does not allow access to the controller."
    (http://java.sun.com/j2ee/javaserverfaces/reference/faqs/index.html#differences)

    Thanks for your input, but I'll take Sun's word over yours.
  147. Thanks for your input, but I'll take Sun's word over yours.

    You might want to recognize that you are taking one remark out of a FAQ completely out of context. A few other facts (from the JSF spec) might be of interest.

    The "controller" you must be referring to, I imagine, is javax.faces.webapp.FacesServlet. The following sentence from Section 10.1 is relevant: "Executing the request processing lifecycle by other mechanisms (for example, an MVC-based application framework can incorporate calling the correct phase implementations in the correct order; however, all JSF implementations must support the functionality described in this chapter to ensure application portabiity." You don't even HAVE to use the default controller if you do not want to.

    Even with the standard controller servlet, you have a large variety of mechanisms to customize it's behavior:

    * Pluggable implementation of the default ActionListener
      (the primary interface between view tier events and
      application actions), which is how the Struts-Faces
      integration library bridges between the two frameworks.

    * Pluggable implementation of NavigationHandler
      to manage navigation differently if you prefer.

    * Pluggable implementation of ViewHandler (to
      interact with view tier technologies in a manner
      different than the default RequestDispatcher.forward).
      Among other resources, see Hans Bergsten's JSF book
      and articles for worked-out examples of such
      implementations for non-JSP rendering choices.

    * Pluggable implementation of StateManager (to
      customize how component tree state information
      is saved and restored). You are not restricted
      to the solution provided by your JSF implementation.

    * Pluggable implementation of VariableResolver and
      PropertyResolver, so that you can specialize how
      value binding and method binding expressions are
      resolved (this is how Spring's IoC functionality
      has already been integrated with JSF in a manner
      that is transparent to JSF components).

    * The ability to register PhaseListeners that are
      notified before and after each phase of the request
      processing lifecycle, so you can customize behavior.
      (This, along with a pluggable ViewHandler, is how
      Shale provides custom lifecycle callbacks to application
      code that implements ViewController).

    If these capabilities don't satisfy your desire for "access to the controller", it would be interesting to see what use cases you have that aren't covered yet -- that would provide opportunities for enhancing the flexibility and pluggability of future versions of JSF for integrating into application architectures.

    Craig McClanahan
    (who, by the way, works for Sun :-)
    (and was co-spec-lead for JSF 1.0)
  148. "Executing the request processing lifecycle by other mechanisms (for example, an MVC-based application framework can incorporate calling the correct phase implementations in the correct order; however, all JSF implementations must support the functionality described in this chapter to ensure application portabiity."


    Rats ... no preview mode ... accidentally clipped part of the sentence. It should actually read as follows (up to the left parenthesis):

        Executing the request processing lifecycle
        via other mechanisms is also allowed ...

    Craig
  149. What context?[ Go to top ]

    Exactly which context am I taking the quote out of?
    Here's the entire quote.

    "Because Struts is a web application framework, it has a more sophisticated controller architecture than does JSF. It is more sophisticated partly because the application developer can access the controller by creating an Action object that can integrate with the controller, whereas JavaServer Faces technology does not allow access to the controller. In addition, the Struts controller can do things like access control on each Action based on user roles. This functionality is not provided by JavaServer Faces technology. "

    If the "controller" can be accessed and or customized as you indicate, maybe you folks at Sun should get your crap together. Don't you see any inconsistancies between what I have just quoted from the JSF FAQ at Sun' site and what you wrote in your post? If you do, then maybe it's you and your buddies at Sun that are responsible for some of the FUD surrounding JSF.
  150. Craig McClanahan(who, by the way, works for Sun :-)(and was co-spec-lead for JSF 1.0)

    Aren't you the guy who created Struts?
  151. Craig McClanahan(who, by the way, works for Sun :-)(and was co-spec-lead for JSF 1.0)
    Aren't you the guy who created Struts?

    Yep. And the one who has proposed a radical new direction for Struts 2.x, that recently got accepted as a Struts sub-project:

    http://wiki.apache.org/struts/StrutsShale

    (so you can tell that I'm something of a believer in JSF :-)

    Craig
  152. Craig McClanahan(who, by the way, works for Sun :-)(and was co-spec-lead for JSF 1.0)
    Aren't you the guy who created Struts?
    Yep. And the one who has proposed a radical new direction for Struts 2.x, that recently got accepted as a Struts sub-project:http://wiki.apache.org/struts/StrutsShale(so you can tell that I'm something of a believer in JSF :-)Craig

    Very cool. Within the last year or so my company migrated our business onto a web-based platform, and we're using JSF. We we fairly early adopters, so we didn't use any RAD tools for the GUI: just Eclipse. I've never understood the criticism about JSF requiring the use of a RAD tool; it's simply not true.

    I like JSF. I like the clean separation of concerns. I like the event model (i.e. request processing lifecycle). I like the component model. I like managed beans. I like the way navigation is decoupled.

    I wish JSF was a bit faster, and that the RI included some more advanced (i.e. full-featured) components, although we're filling some of those gaps, ourselves. I haven't had much opportunity to play with any of the RAD tools, but I'm interested in seeing what kind of code (and binding methods) the RAD tools generate for JSF.
  153. Struts has Controller.cache property to affect client-side caching. What about JSF?
  154. Client-Side Caching[ Go to top ]

    Struts has Controller.cache property to affect client-side caching. What about JSF?

    AFAIK, the Struts Controller interface doesn't have a cache property (i.e. no getters or setters for such a property). Are you talking about ControllerConfig.nocache? If so, I don't think that JSF has an equivalent property as part of the framework. However, this kind of thing (i.e. adding headers to all responses) can be handled with a Filter.

    As an aside, JSF does have a parameter that lets you specify where page state is saved: client or server. (If you save state on the client it saves the data in a hidden field on the page).
  155. Client-Side Caching[ Go to top ]

    AFAIK, the Struts Controller interface doesn't have a cache property (i.e. no getters or setters for such a property). Are you talking about ControllerConfig.nocache?
    Yes, I was talking about "nocache" attribute of "controller" element in struts-config file, but this is the same thing.
    If so, I don't think that JSF has an equivalent property as part of the framework. However, this kind of thing (i.e. adding headers to all responses) can be handled with a Filter.
    I did not think about a filter, thanks.
  156. I'm Convinced[ Go to top ]

    The reason people make the association between JSF and WYSIGWYG tools is because Sun makes the association. Sun states the following at their site "JavaServer Faces Technology was designed for use inside of tools from the very beginning."

    That's puzzling since Oracle insists that JSF isn't ready for use with design tools:

    "Although the faces-config.xml language allows a component author to express a great deal of information about their components and renderers, it only has standard syntax for expressing a very minimal set of design-time metadata. Fortunately, the faces-config.xml language is designed with convenient extension points that can be used to hold additional information. Unfortunately, there is no standard that defines what syntax a component author would use inside of these extension points. While tool vendors could invent their own syntax for associating metadata with faces components, the hope is that the community of tool vendors and component authors can agree upon a standard mechanism. If there is a standard in this area, component authors will be able to provide metadata in one format that will work in all tools, and the end user will be in the ideal situation of being able to pick the tool they want to use independently from the component set that best meets their needs."
  157. I'm Convinced[ Go to top ]

    The reason people make the association between JSF and WYSIGWYG tools is because Sun makes the association. Sun states the following at their site "JavaServer Faces Technology was designed for use inside of tools from the very beginning."
    That's puzzling since Oracle insists that JSF isn't ready for use with design tools

    That's not what the link says. Its about providing additional metadata for use with JSF in design tools. Oracle provide a JSF design tool in JDeveloper. Other JSF design tools are available: Borland JBuilder, Sun Studio Creator are examples.
  158. I'm Convinced[ Go to top ]

    That's not what the link says. Its about providing additional metadata for use with JSF in design tools.

    Oracle insists that the standardization of JSF design metadata is lacking. Oracle is proposing that the JSF specification be revised to encourage portability between JSF design tools.
  159. I'm Convinced[ Go to top ]

    That's not what the link says. Its about providing additional metadata for use with JSF in design tools.
    Oracle insists that the standardization of JSF design metadata is lacking. Oracle is proposing that the JSF specification be revised to encourage portability between JSF design tools.

    Saying that portability between design tools can be improved is not the same as saying that JSF is not ready for use in design tools.
  160. I found the article quite interesting, and look forward to the additional articles to follow. I've posted detailed notes on my blog.

    Basically, I still don't see much in JSF to excite Tapestry users. JSF has nearly caught up to where Tapestry was about two years ago, and Tapestry 3.1 will be a marked improvement over even Tapestry 3.0. I've personally promised members of the JSF EG that we'll keep raising the bar for them!
  161. I am the perfect target, in marketing terms, for the author.
    I am a nonbeliever of JSF, but true: that is basically because of what i read so far. I have very little hands-on experience with JSF.
    So i carefully studied the artice, downloaded the sourcecode
    and try to build it with Maven. And it fails!!

    (Something to do with the fact that some jsf jars can not be found at ibiblio.)
    I know this problem has nothing to with JSF itself, but it always very annoying that things (software/hardeware) that should run out-of-the-box, don't run when you press the start button.
  162. I have said this several times, but I can´t help it... :)
    JSF reminds me of an old Sun´s product: NetDynamics.
    Didn´t we stop using web events because they decided to leave Netdynamics and use another programming style in web applications?

    Joserra
    Najaraba
  163. Tapestry tutorials available[ Go to top ]

    As Tapestry is mentioned in some of the posts here but not
    all people know what it is, I'd like to point you to the
    tutorials we created on Tapestry at
    http://www2.cpttm.org.mo/cyberlab/softdev/tapestry/
    to quickly show how easy and powerful it is.
  164. Market demand for JSF[ Go to top ]

    CodeFutures has received about 10 requests for automatic Java code generation with JSPs and Struts for every request for JSF code generation.

    As a vendor, we need to respond to market demand as well as make decisions based on technical merits of technology.

    And there does not seem to be much demand for JSF at the moment.

    CodeFutures intends to adds support for JSF - so don't read this post as anti-JSF.

    It means that "10 times more Java developers that use FireStorm/DAO to generate data access objects as their data persistence tier, and have indicated their preference, want to use JSPs or Struts for their presentation tier".


    PJ Murray
    CodeFutures
    http://www.codefutures.com
  165. Market demand for JSF[ Go to top ]

    CodeFutures has received about 10 requests for automatic Java code generation with JSPs and Struts for every request for JSF code generation...And there does not seem to be much demand for JSF at the moment.

    I would suggests that this indicates a considerable potential demand for JSF: Usable implementations have only been out for a matter of months, whereas JSPs and Struts have been around for years. I'm surprised the figure is as high as 10% of requests for such a new technology.
  166. Market demand for JSF[ Go to top ]

    CodeFutures has received about 10 requests for automatic Java code generation with JSPs and Struts for every request for JSF code generation...And there does not seem to be much demand for JSF at the moment.
    I would suggests that this indicates a considerable potential demand for JSF: Usable implementations have only been out for a matter of months, whereas JSPs and Struts have been around for years. I'm surprised the figure is as high as 10% of requests for such a new technology.

    I agree that once the JSF's visual tools are more standardized, you will be seeing a whole market of drag 'n drop programmers that will now find Java technology more accessible. This will hopefully then open the doors for other open source, Java technologies from the community.

    Sun's group has been feverishly working on developing a technology for a market that has been relatively untouched except by MS. While there are many other frameworks out there that are more developed at this point, an open discussion such as this can help JSF stick to its guns and greatly appeal to experienced developers coming from any other framework.

    Truthfully, I don't think it would be too far fetched to see a developer actually integrate JSF into a framework such as WebWork, much like Struts and JSF were integrated as an optional path for UI development. Why would it hurt any framework to be able to eventually leverage a standardized UI tool offered from any corporate/open source vendor?
  167. Re: Market demand for JSF[ Go to top ]

    I agree that once the JSF's visual tools are more standardized, you will be seeing a whole market of drag 'n drop programmers that will now find Java technology more accessible.

    It's safe to say that the market is already there (although it's currently small). Those of us in the JSF community are also keenly aware of the amount of growing interest from other third-party vendors as well. For a list of what's out there currently, see http://www.jsfcentral.com/products/.
    Truthfully, I don't think it would be too far fetched to see a developer actually integrate JSF into a framework such as WebWork, much like Struts and JSF were integrated as an optional path for UI development. Why would it hurt any framework to be able to eventually leverage a standardized UI tool offered from any corporate/open source vendor?

    I'm glad that you mentioned that, because JSF is so extensible that it could easily work with these other frameworks (integration is also available for Spring). I would love to see additional bridges for Tapestry and WebWork. The power of JSF is really the component model (which sets the stage for third-party components, which makes development easier).

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info
  168. Tapestry how to[ Go to top ]

    Hi Howard

    I have read your book...very good...

    I was wondering... how can you do the equivilant of this:

    <jsp:include page="<%=url%>"/>

    in tapestry... where url is a dynamically generated url and the content is included i the page...
  169. The main problem for JSF is: it comes too late.

    You already have de-facto standard like JSP/Struts and you also already have other techniques available like Tapestry, XMLC, WebWork, Echo, etc. which are already very stable... So who needs JSF? Trying to put JSF as "de-jure" standard is quite difficult since we already have a very strong de-facto standard... It is an intelligent move to ask Apache to integrate JSF into Struts (project: Shale) because the only way to become a de-facto standard is to take over the already de-facto standard which is held by Struts today.

    And because Apache puts some efforts in JSF as well (MyFaces, Shale), the chance to make JSF as the de-facto standard will be very high. So, people, resistance is useless :-) Drop your tools...

    The same thing happens in persistance world as well: Hibernate (de-facto standard) against JDO (de-jure standard)... In this case Hibernate is more lucky because it will become an implementation of EJB3 so it will be de-jure standard as well... Not like Struts...

    Anyway, everything depends on the Open Source community. If a lot of developers say that they want to defend Struts' place as the de-facto standard, they can do it... This is the real power of de-facto standard... (not just on the paper like de-jure standard)...

    Whether you need more work with "pure" Struts instead of using JSF, it doesn't matter. It seems that the author never sees AndroMDA Cartridge for JSP/Struts. You can generate a running JSP/Struts application from a UML diagram, so to be honest: you can write Struts application a lot more faster than doing all the same stuffs in JSF + JSF tool (you surely can build JSF cartridge as well if you want to :-)). Check out this AndroMDA docu link:
    http://www.andromda.org/andromda-bpm4struts-cartridge/index.html

    And my comment to the blog: "Web Application Development". This is just an old story. Please, we need to go for a more "abstract" way to define our "presentation layer", so we can use one presentation layer description (UML, DSL) to generate all UI stuffs (Swing, SWT, JSF, JSP, XMLC, HTML, Struts, Lazzlo, ...). This will be a new way for all of us!

    Cheers,
    Lofi.
  170. Thanks for the feedback[ Go to top ]

    I enjoyed the comments by Steve Zara, Jacob Hookom, John Reynolds, James Treleaven, Jason Carreira, Howard Lewis Ship, Craig McClanahan, Jason Cone and more.

    I just found the post today. I know I checked TSS on Friday, but it must have come out afterwards or I missed it. I got the first clue about TSS post when I saw my blog traffic jump. The second clue was I was just biled again. I was hoping to fly under the bile radar for a while.

    Mike Wasserman post of 1,000 logical fallacies was the best. I laughed very loud when reading it. I hope he was joking. I think he was. If not, sorry I did mean to criticize you.

    Steve Zara's zeal and ability to respond to questions is amazing. I was considering responding to quite a few posts, but found Steve wrote basically what I would have wrote anyway. Steve, if I see you at TSSS in Vegas, let's go get a beer. I owe you one.

    I put two JSF medium to low traffic production apps into production and consulted on many more JSF projects. I really enjoy working with JSF (and SpringMVC, Spring, Hibernate, etc. etc.). I have not written any JSF books (an earlier reader claimed I wrote several which nonplused me to no end). Only one JSF app I consulted on was a high traffic app, and I can not talk about it. (They do exist.) I know of another that is high traffic and planned for later this year. I am a JSF enthusiast not a JSF zealot. I would like to be on the JSF JSR group, but am stretched thin already, and was never asked.

    Jason Carreira makes a very good point about investigating other frameworks. Digging into XWork and WebWork opened my eyes to a lot of things. I do not claim to be an XWork/WebWork expert by any stretch of the imagination, but studying them and poking around gave me a lot of really good ideas. The same could be said for SpringMVC, which I know more about than WebWork. These are amazing frameworks developed by extremely talented folks. Even if you decide to keep using Struts or straight JSP or use JSF, I think studying these frameworks will give you a lot of really good ideas.

    The existence of JSF validates the existence of Tapestry. I hope one if not both become the de facto standards for web development. I am hooked on the Web component model and its event driven nature. This is not to say I think that every web app needs this or this model fits every web app.

    I worked with one client recently who is working on a *very* high traffic app, and stated they would rather chew on glass than use JSF. In their case, I see their point. Most web apps are not ebay or amazon apps.

    There are shortcomings of JSF sited here, and hopefully they get addressed in future specifications and through support and extensions of JSF by the Shale project. Jason Carreira made some thoughtful comments about templating and JSF components. Extensions that allow Velocity-style templating for JSF components as an option would be great. It feels dirty to mix Java code and HTML when writing JSF components. Tapestry really seems to have this figured out. Howard Lewis Ship is brilliant. He needs to be drafted into the JSF JSR effort by force if needed.

    I could make a wish list of things I would like to see in JSF and Shale. I need to see what Shale already provides first.

    I do not claim that JSF is perfect. I think it is a strong base to build future frameworks on top of. I would love to see some of the Tapestry-style features incorporated into JSF. I hope Shale is to JSF what Struts is to JSF/Servlet/Custom Tags.

    Regarding (robin bakkerus):
    "If JSF is so easy, why does the example not work I am the perfect target, in marketing terms, for the author. (What am I marketing to you? I do not sell JSF. I am just as happy if you use Tapestry or Spring or JSP.) I am a nonbeliever of JSF, but true: that is basically because of what i read so far. I have very little hands-on experience with JSF.
    So i carefully studied the article, downloaded the source code and try to build it with Maven. And it fails!!"
     
    My Response (Rick Hightower): Sorry life sucks. I should have used MyFaces for the example since its jar files are hosted on ibiblio. There are the usual jar file distribution and licensing issues. However, if you look in the resource section, you will see a link to a web page (look for "For detailed install and build instructions for Ant and Maven, see the JSF resources for this series"). On this web page are instructions on how to find the jar files and run the build. There is even an Ant build file for the Maven impaired. Please send any error message you have and I will help you fix the problem and then post the error message and fix on the build resource page mentioned above.

    Regarding (robin bakkerus): "I know this problem has nothing to with JSF itself, but it always very annoying that things (software/hardware) that should run out-of-the-box, don't run when you press the start button."

    My Response (Rick Hightower): I agree 100%. If you are not familiar with Maven please use the Ant build file. This way you can focus on JSF and skip learning about Maven to a future date. In other words, if you used Maven before I think you could have fixed said problem in 5 seconds. You did not so you do not so use Ant that is why I provided it.
  171. I hope you did laugh[ Go to top ]

    because you'd have to be laughing at yourself.

    If you think what I said was illogical then you and the rest of your JSF buddies should take a look at how you're communicating your information.

    I've never seen a technology presented in such an embarrassing manner.
    Read your own article.
    Then read the Sun JSF FAQ.
    Then read Hans Bergsten's book.
    Then read Core JavaSever Faces.

    After that you may realize how confusing all you JSF people sound. I'm beginning to think that JSF is better than I thought, but no thanks to you.

    There is so much in your article that just doesn't make sense. You stated:
    "Just in case you're thinking that doing it with Struts would have been easier, my estimate is that it would take at least twice the effort to create the Struts version of the simple JSF application you built here."

    That may be true, if I didn't already know Struts. If I know Struts but don't know JSF it's going to take longer to do almost anything in JSF. So I should learn JSF so that one day I may be slightly faster (because we all know that faster is always better) at developing?

    You even admit that one may be left shaking their head after looking at your "very simple demonstration of JavaServer Faces technology", yet you stated at the beginning of your article "if you think JSF development is difficult you're probably not doing it right" and "As previously mentioned, the JSF framework is designed to be remarkably easy on the application developer." If this technology is so easy why am I shaking my head at the end of your simple demonstration? Don't you see a conflict here? Or does JSF only become easy once you've mastered the difficult part (like anything else that is difficult)?

    What was the objective of your article? Was it to introduce me to a technology that you think is really good and that you suggest I investigate further and adopt?
    Well it' safe to say that you failed. It actually achieved the opposite.

    Mr. McClanahan' suggested that I look into JSF more and I realized that he was right, and that maybe the sources I was using, (your article and Sun's FAQ for example), may have been deficient, and there may be better ones (Hans Bergsten's book for example).

    Thanks for the lession in logic Mr. Hightower.

    Maybe you can tell me who's being illogical now?
  172. I hope you did laugh[ Go to top ]

    You even admit that one may be left shaking their head after looking at your "very simple demonstration of JavaServer Faces technology", yet you stated at the beginning of your article "if you think JSF development is difficult you're probably not doing it right" and "As previously mentioned, the JSF framework is designed to be remarkably easy on the application developer." If this technology is so easy why am I shaking my head at the end of your simple demonstration? Don't you see a conflict here? Or does JSF only become easy once you've mastered the difficult part (like anything else that is difficult)?

    I know your comments were not addressed to me, but I hope I can contribute a useful reply.

    I was just like this about JSF - I was a real fan of JSPs and had recently started to use Struts. JSF looked complex. But, I persevered and after re-visiting JSF many times, eventually I got there, and now I do consider JSF to be very simple to use.

    The problem I found was that it was a totally different paradigm from using previous frameworks I had used (JSP/Struts), and it took me time to get into the JSF 'way of thinking'. I don't think there is anything wrong with something like JSF requiring a different way of thinking, or that because it does, that makes JSF difficult. This is the nature of different approaches in IT.

    I personally found the best way to think of JSF is as if you were coding a client-side GUI. I find the process of coding the components + events + validators model to be very similar to how I would work with Swing or SWT.
    I should learn JSF so that one day I may be slightly faster (because we all know that faster is always better) at developing?

    I would (and did) learn JSF initially just because I felt it would be a huge advantage to learn a new approach. Whether or not I end up using that new approach, it makes me a better and more versatile programmer. I would have looked at Tapestry, but it seemed that JSF was intended to be a new standard. Comments in this thread have made me want to look at Tapestry in detail. Not because I might use it (although I might), but because it will broaden my knowledge of web frameworks.
  173. I hope you did laugh[ Go to top ]

    Thanks for your reply Steve.

    I have started to take a closer look at JSF and my view is changing.

    What I really don't like about the Hightower article is the approach. I think he is really doing a disservice to the JSF and Java communities. The problem is that his article is as much propaganda as it is technical. Propaganda doesn't attract me to a technology. An intelligent, concise investigation of the topic does.
    I re-read his article and I could enumerate the flaws in it, but what's the point? I'm sure he's not interested in my opinion.

    I've found conflicts between various sources of information on JSF and Mr. Hightower's article just contributes to the confusion. I could point out how in detail, but why should I bother? Afterall he thinks that laughing at me somehow adds to his stated goal of explaining JSF.

    If I can make a suggestion to the JSF proponents. Stop talking about Struts. Stop comparing JSF to Struts. Talk about JSF on its own. Stop telling me how great JSF is. Just tell me what JSF is. Follow the lead of David Geary and Cay Horstmann. Their book Core JavaServer Faces is a great example of how to talk about a technology. They just explain JSF plain and simple. They let the reader decide how good it is. Also, being consistent in your ideas is a valuable aspect of communication. Going on and on about how great something is, especially in reference to something else doesn't make it great. It just results in pedantic articles that don't really help the Java community at all.

    Thanks again Steve.
    Your comments are much more constructive than Hightower's or McClanahan's.
  174. Stop talking about Struts. Stop comparing JSF to Struts. Talk about JSF on its own. Stop telling me how great JSF is. Just tell me what JSF is.
    You said that you already know Struts. Why don't you want JSF to be compared to the framework that you know? I personally want to understand the major differences and benefits of JSF over Struts, and are these benefits worth moving to JSF.

    From what I learned now, the major difference is that in Struts JSP pulls data from beans, whereas in JSF components render themselves. This is a huge difference, which makes JSF less flexible than Struts in terms of serving different clients and adapting to different styles. This is not necessarily a bad thing. Struts does not care much about View, it is almost presentation-agnostic, it is a controller framework. All Struts does is provides convenient access to the bean properties.

    JSF tags allow to define component placeholders on a page, and then components render themselves. This is handy in a way that components do not have to know how other components are rendered. And because components are rendered after model has been updated, they do not depend on each other on render phase. Having components rendering themselves allows to move a component presentation part from one page to another.

    On the other hand, properly defined XHTML page with DIV markup allows to perform the same trick using regular JSP or Struts tags, just instead of one tag you would have to move a DIV block. But all this markup can be stored in custom tag, so there is no much difference here.

    UI component bean and Struts form bean are very alike. Value change handlers? Just a handy wrapper over tiresome code in Struts setters like

      public void setMyData(String value) {
        if (value.equals(this.myData)) return;
        this.myData = value; // or set data in the handler
        onMyDataChange(value);
      }

    where onMyDataChange() is your value change handler.

    Error management must be surely better. Struts error messages live during only one request/response cycle, so if you redirect, messages are gone. In my Struts projects I do not return errors from validate(), I store them in the form bean with session scope instead. JSF has a similar approach, it stores UI elements including error messages in the UI bean.

    When you read JSF examples, see how most of the beans have session scope to store UI values between requests. Add redirect element in JSF config file and you will GET view independent on previous POST, which can be safely reloaded. With this approach JSF does not need to pass ugly _viewdata, so JSF is not at all a cheap ASP.NET ripoff. JSF apps should be more robust than ASP.NET in terms that a user can leave a page, browse somewhere else and then return back and get the proper view, because state was saved on the server.
  175. Because it creates confusion.
    The whole point of Hightower's article was to clear up much of the confusion surrounding JSF. Comparing it to Struts just creates confusion.

    Our friend Mr. McClanahan pointed me to Hans Bergsten's book on JSF. Bersten says:

    "You may have noticed that I refer to Struts and similar frameworks as application frameworks, and to JSF as a user interface framework. I do this to emphasize that they have different objectives. An application framework's objective is to support the development of complete applications; it's concerned with the Big Picture. This type of framework acts as a traffic cop, routing HTTP requests to request handling code and internal view requests to response rendering code based on mappings between symbolic names and the different types of application components. An application framework doesn't care about details, such as how the user interface is rendered, or make any distinction between user actions that only affect the user interface (e.g., asking for the next set of rows to be displayed in a table) and actions that need to be processed by backend code (e.g., processing an order on an e-commerce site). Struts, for instance, can use JSP, Velocity, XSLT, or any other presentation layer technology to render a response. The Struts servlet just routes requests to application classes that process them and then tell Struts which page to display next.

    A user interface framework, on the other hand, focuses on the user interface details and isn't concerned with how the rest of the application is implemented. It defines a detailed API for user interface components, for how user actions result in user interface events and how these events are handled, how the components are tied to the business data they visualize, and so on.

    With these differences in mind, it should come as no surprise that it's possible to use JSF with an application framework like Struts. Basically, all requests are processed by JSF until it's clear that backend code needs to be invoked. The control is then passed on to Struts, and eventually comes back to JSF for rendering of the response.

    There's some overlap between Struts and JSF, though. Both define mechanisms for page navigation and validation, for instance, but they are so flexible that you can pick and choose which should be in charge of these tasks. The JSF custom tag libraries also make some of the Struts counterparts obsolete, but the Struts Action and model classes can be used without any modification in most cases."

    If they have different objectives then stating that JSF can replace Struts doesn't make much sense. They seem to compliment eachother not compete. So why create a competition via comparison? It's just plain confusing.
  176. If they have different objectives then stating that JSF can replace Struts doesn't make much sense. They seem to compliment eachother not compete. So why create a competition via comparison? It's just plain confusing.

    I totally agree that it is confusing, particularly having read, and re-read the quotes you put in your post.

    However, I think some sort of comparison is appropriate because JSF is an full alternative to Struts. I don't agree that Struts and JSF have different objectives, as JSF has application framework features as well: it is weaker in some areas, and has more emphasis on the view side of things, but it is possible (and I find it very easy) to create complete web applications with JSF alone. Also, JSF has many of the same features as Bergsten described for Struts: JSF is designed to be independent of the rendering technology - it does not have to use JSP: this is simply the technology shipped with the RI. (Personally, I found that quote from Bergsten to be very obscure and potentially confusing for a beginner).

    Struts has far more powerful controller features, JSF has (in my opinion) better (and easier to use) view features, but both can be used as full web application frameworks, both can have different rendering technologies.

    I really looking forward to Shale, which should combine the strengths of JSF and Struts.
  177. I hope you did laugh[ Go to top ]

    Stop talking about Struts. Stop comparing JSF to Struts. Talk about JSF on its own.
    Yeah! You! -Stop talking about those wheels! Just look how beautiful and functional my wheel is! It runs smoothly, very robust and easy to repair.
    And stop talking about those round wheels, just look at nice hexagonal shape of my wheel! Feel it, touch it, isn’t it nice?!
  178. Try all of them and make a choice![ Go to top ]

    I am using Struts for two years. I started three months ago trying other presentation frameworks including JSF. My modest conclusion is: Tapestry is the best. I won’t say anything about it. Try it yourself. Here a tutorial of one hour:
    http://www2.cpttm.org.mo/cyberlab/softdev/tapestry/tutorial1/GettingStartedWithTapestry.html
    If you like it, try also these tutorials (Tapestry+Spring+Hibernate):
    http://www.sandcastsoftware.com/articlesandtutorials/brownbag/index.html#tapestry

    After this please try JSF if you didn’t yet, and make your decision.
    The choice is always yours ;)
  179. ... and make your decision.The choice is always yours ;)

    In General you're right, everyone building a web application with Java has a different focus, so most of the technologies which were also mentioned here have their audience. Java is an open standard, so you have the choice.

    But however, for me as a sytem archtitect I really like to have a real standard for building my application, because a lot the frameworks mentionened here will propable disappear in the near future, and that means I'm sitting an a dead technology an have to migrate again with a real big effort.
    We were using Apple WebObjects 4 years ago, and at the point of time it was the best technology, which was available.
    But there is no real development going on and it's definitly not the future.

    I see really good chances for JSF to become a real standard, that's why I'd really like to become JSF being accepted by the community.
    I do not deny that there are problems with the current Verison of JSF, it took 3 years to finish it, and when it started it was build an JSP 1.1, when it was finished JSP 2.0 was out already, which lead to probelms with the exisiting technologies (EL, JSTL etc.). But in JSF 1.2 goes in the right direction and fixes these things.

    So I have really FUD about the current situation with no real standard, that's a really bad situtation for every company. I really hope that JSF is the solution!
  180. JSF much easier to learn[ Go to top ]

    Regarding: "That may be true, if I didn't already know Struts. If I know Struts but don't know JSF it's going to take longer to do almost anything in JSF. So I should learn JSF so that one day I may be slightly faster (because we all know that faster is always better) at developing?"

    Hmmm... There was a day when you did not know either. I believe the learning curve to learn JSF or Tapestry is worth the trouble. It will pay you back many times over.

    If you were new to JSF or Struts, I know you would learn JSF faster (on average). I know this b/c I have taught classes on both and I have consulted on projects when people were new to both.

    JSF is very intuitive.

    I apologize I should not have resorted to an obvious personal attack. It is just that you earlier comments.... opps... I almost did it again.