Discussions

News: Creating a JSF div component

  1. Creating a JSF div component (92 messages)

    IT-eye, a blog focusing on Oracle and Java technology, posted a blog entitled "Creating a JSF div component," which shows code for a JSF custom component that - surprisingly - renders an HTML div tag. As another blog entry ("JSF Productivity") describes, some see it as an explanation of JSF's flaws, but it also shows how easy it is to create a component.

    The argument against productivity can be summarized as "See how much work goes into just creating an HTML div in JSF." While accurate, the authors point out that one doesn't normally have to use a custom tag just to create a DIV (and, presumably, one shouldn't use a custom tag for this.)

    What do you think of JSF's component creation vs., say, Tapestry's component model? Which is better under what conditions?

    Threaded Messages (92)

  2. From: JSF Productivity:
    To be truly productive you need more than a powerful framework, you also need IDE support.

    My take: If a web-framework requires IDE-support to overcome the complexity of creating a component, something is wrong.

    That being said: I haven't used JSF myself yet, so I cannot really comment objectively on the framework. I do know that creating a DIV doesn't require a custom component in Tapestry at and that creating custom components in Tapestry seems much simpler to do. On the other hand: Tapestry has quite a learning curve as well IMHO.
  3. It all depends how you intend to use JSF.

    Facelets extension will reduce the amount of coding making component writing as simple as writing HTML templates, but since there is a different reason for all the steps shown in the example, this will be a tradeoff from some aspects plain JSF is able to offer as-is.

    I'd like to see optional leveraging of JSP 2.0 simple tag functionality in component/renderkit writing instead of reducing the glue code with Clay, Facelets, Myfaces alias tags or you-name-it.
  4. RE: Creating a JSF div component[ Go to top ]

    My take: If a web-framework requires IDE-support to overcome the complexity of creating a component, something is wrong.

    <em>Creating</em> (writing) a component will always be a PITA, that's not the job of the IDE.

    <em>Using</em> the component, once created, should be a snap. The component must be flexible and easy to "tool". The IDE's job is to make it easy to use a powerful component.

    John.
  5. RE: Creating a JSF div component[ Go to top ]

    <em>Creating</em> (writing) a component will always be a PITA, that's not the job of the IDE.
    <em>Using</em> the component, once created, should be a snap. The component must be flexible and easy to "tool". The IDE's job is to make it easy to use a powerful component.John.

    Well this is the reason a lot of JSP's out there are filled with ugly scriptlets causing a maintenance nightmare: Creating custom tags is too cumbersome, so people just inline their code and be done with it.
    If you offer a component based web framework, make sure creating components is easy and using the components is even easier. This is one area where I like the Tapestry approach.
  6. inine code? Rubbish, I say![ Go to top ]

    Creating custom tags is too cumbersome, so people just inline their code and be done with it.

    That's one theory - other factors behind the usage of scriptlets might include JSP custom tag spec volatility, framework profusion/confusion, etc.

    It seems to me like the Facelets + Seam combo will eliminate the need for most existing Web-MVC frameworks - it's going be hard to get easier than this combo. Of course a combo like this wouldn't be possible without all the lessons learned by framework and Java spec attempts.

    Flame away!
  7. Oopss....[ Go to top ]

    My take: If a web-framework requires IDE-support to overcome the complexity of creating a component, something is wrong.
    <em>Creating</em> (writing) a component will always be a PITA, that's not the job of the IDE.<em>Using</em> the component, once created, should be a snap. The component must be flexible and easy to "tool". The IDE's job is to make it easy to use a powerful component.John.

    Interestingly, creating components is really easy in ASP.Net (as well as some other Java frameworks).

    This is an extremely major weakness of JSF.
  8. RE: Creating a JSF div component[ Go to top ]

    Creating (writing) a component will always be a PITA, that's not the job of the IDE. Using the component, once created, should be a snap.
    I keep seeing arguments like this one, and I can't help but think that a good (though imperfect) analogy would be an object-oriented language that makes it hard to code new objects. Language evangelists might tell developers that they'll rarely need to code new objects and that they'll spend most of their time reusing existing frameworks and third party libraries, but the fact of the matter is that at some point you are going to want to build your own hierarchy of objects, and a suboptimal way of expressing this hierarchy is going to get in the way.
  9. RE: Creating a JSF div component[ Go to top ]

    My take: If a web-framework requires IDE-support to overcome the complexity of creating a component, something is wrong.

    Well, I use JSF a lot. Would IDE support make things easier? Maybe, but we do all of our JSF coding *by hand*. XML Configs, templates (JSP and Facelets). All of it. We've found it to be be pretty easy. Honestly, I don't understand all of the "JSF requires good tool support" choruses I keep hearing. We do just fine without a fancy gui. *shrug*

    jason lee
  10. RE: Creating a JSF div component[ Go to top ]

    My take: If a web-framework requires IDE-support to overcome the complexity of creating a component, something is wrong.
    Well, I use JSF a lot. Would IDE support make things easier? Maybe, but we do all of our JSF coding *by hand*. XML Configs, templates (JSP and Facelets). All of it. We've found it to be be pretty easy. Honestly, I don't understand all of the "JSF requires good tool support" choruses I keep hearing. We do just fine without a fancy gui. *shrug*jason lee

    Well depends something like the Creator2 give a real rad approach to the mix. Adding tools can help to jump between form, navigation and code, but not adding tools to the mix does not really slow things down too much, it still is way easier than doing the stuff with Struts.
  11. Tired old FUD Song[ Go to top ]

    My take: If a web-framework requires IDE-support to overcome the complexity of creating a component, something is wrong.
    Well, I use JSF a lot. Would IDE support make things easier? Maybe, but we do all of our JSF coding *by hand*. XML Configs, templates (JSP and Facelets). All of it. We've found it to be be pretty easy. Honestly, I don't understand all of the "JSF requires good tool support" choruses I keep hearing. We do just fine without a fancy gui. *shrug*jason lee

    I agree. It is a tired old FUD song. JSF takes a lot XML configuration than Struts and many other web frameworks.

    I hear this chorus from the following:
    1) advocates of other web frameworks,
    2) folks who are just repeating what they have heard and have not used JSF
    3) folks who took years to learn Struts and don't want to try something new no matter how much simpler it will make their life

    JSF is easier (even by hand w/o fancy GUIs) than all other mainstream frameworks. You will get more done with less effort.

    On top of this, there is a metric ton of Component frameworks.
  12. From: JSF Productivity:
    To be truly productive you need more than a powerful framework, you also need IDE support.
    My take: If a web-framework requires IDE-support to overcome the complexity of creating a component, something is wrong.That being said: I haven't used JSF myself yet, so I cannot really comment objectively on the framework. I do know that creating a DIV doesn't require a custom component in Tapestry at and that creating custom components in Tapestry seems much simpler to do. On the other hand: Tapestry has quite a learning curve as well IMHO.

    First: You don't need an IDE to create a JSF app.

    See:
    Clearing up the JSF FUD
    http://www-128.ibm.com/developerworks/library/j-jsf1/
    http://www-128.ibm.com/developerworks/library/j-jsf2/
    http://www-128.ibm.com/developerworks/library/j-jsf3/
    http://www-128.ibm.com/developerworks/library/j-jsf4/

    It is much easier to create applications with JSF than Struts and other Model 2 style frameworks.

    Tapestry has a much steeper learning curve than JSF.

    JSF is much easier to learn than Struts, Tapestry, etc., etc.

    Facelets closes that gap between JSF and Tapestry quite a bit.

    My guess is that a lot more developers will be doing JSF development b/c:
    1) small learning curve,
    2) major issues w/ JSF fixed in Facelets and JSF 1.2 (and JSP 2.2)
    3) tool support
    4) component libraries
    5) active developer community

    The div issue has been solved many times in many ways.
  13. RE: Creating a JSF div component[ Go to top ]

    JSF is much easier to learn than Struts

    this is hard ?
    ren *.html *.jsp

    ha, ha, ha, ha.

    .V
  14. The bottleneck that make component creation (and some other details in JSF) complex is JSP integration.

    You have to define JSP tag class and XML Tag Library Descriptor for each component and you can’t just extend existing descriptor if you want to extend existing tag.

    Some complexity is introduced to make renderer kit switching possible. But at the end of the story, you can’t switch renderer kit easy because there are separate tag libraries for each renderer kit. Bottleneck is again in JSP integration.

    There is impossible to encapsulate JSP tag definition in some other framework (like JSF).
    We need more generic tag definitions in JSP to make this possible.

    Nebojsa
  15. Creating a JSF div component[ Go to top ]

    The bottleneck that make component creation (and some other details in JSF) complex is JSP integration.You have to define JSP tag class and XML Tag Library Descriptor for each component and you can’t just extend existing descriptor if you want to extend existing tag.Some complexity is introduced to make renderer kit switching possible. But at the end of the story, you can’t switch renderer kit easy because there are separate tag libraries for each renderer kit. Bottleneck is again in JSP integration.There is impossible to encapsulate JSP tag definition in some other framework (like JSF).We need more generic tag definitions in JSP to make this possible. Nebojsa

    Actually there are three bottlenecks in jsfs component api.
    The JSP Tag definition,
    way too much boilerplate code in the component itself, which could be resolved by annotations or sane defaults with introspection,
    the PrintWriter API which makes component renderer creation harder than it should be (and a maintenance nightmare once the markup becomes more complicated)

    Facelets for instance resolve most of this problem.
    What jsf really needs is to get rid of jsp, add annotations for sane component defaults, and get rid of the writer api or allow more abstraction for the markup like an on the fly compile step which compiles the markup into printwriter code on the fly (just as jsp does to servlet)

    A parsable interpreted tree does not make too much sense on component api level due to the fact that there is not too much structure below the writer api.
  16. Creating a JSF div component[ Go to top ]

    I actually like the ResponseWriter API, there are times when you want to have compile-time security of what's being produced written. I've also started to play around with JavaScript push with JSF so you can do:
    boolean show = this.isShown();
    ClientWriter cw = new ClientWriter(rw);
    Script replace = Insertion.replace().start("span").event("click", Element.toggle()).text("Hello World").end("span");

    cw.select("div#body .menuItem", replace, Element.toggle(show));

    Which generates the JavaScript:
    $$('.foo').each(function(e){e.innerHTML='<span onclick="this.style.display=((this.style.display=='none')?'':'none');">Hello World</span>';e.style.display='';});

    Now, would I want to write the JS like that? Probably not.
  17. Honestly I dont want to bash but this is the perfect example of how rotten the spec is. The java code is clean no problem there but man o man that configuration gives me the creaps. It makes me pissed because by now all new jobs require jsf knowledgde and i just dont wanna know it. As one stated earlier, when we need tools to manage this then it is fundamentally wrong. Tooling should be complementary not mandatory.
  18. Creating a JSF div component[ Go to top ]

    Honestly I dont want to bash but this is the perfect example of how rotten the spec is. The java code is clean no problem there but man o man that configuration gives me the creaps. It makes me pissed because by now all new jobs require jsf knowledgde and i just dont wanna know it. As one stated earlier, when we need tools to manage this then it is fundamentally wrong. Tooling should be complementary not mandatory.

    As an app developer you probably will never touch the component api anyway, and yes I think it is one of the broken aspects of the mix, while the rest is really good.
    As an app developer I would use existing component packs and once I need something more complicated I would revert to client side component techs for jsf, like faclets, or shale clay. (Or if I would use Creator, I would look at the compound component facility, which gives visual componentization)

    And yes I agree the component API is broken, due to api and configuration overkill, but it is not a remedy without cures in existence.
  19. Creating a JSF div component[ Go to top ]

    Honestly I dont want to bash but this is the perfect example of how rotten the spec is. The java code is clean no problem there but man o man that configuration gives me the creaps. It makes me pissed because by now all new jobs require jsf knowledgde and i just dont wanna know it. As one stated earlier, when we need tools to manage this then it is fundamentally wrong. Tooling should be complementary not mandatory.
    As an app developer you probably will never touch the component api anyway, and yes I think it is one of the broken aspects of the mix, while the rest is really good.As an app developer I would use existing component packs and once I need something more complicated I would revert to client side component techs for jsf, like faclets, or shale clay. (Or if I would use Creator, I would look at the compound component facility, which gives visual componentization)And yes I agree the component API is broken, due to api and configuration overkill, but it is not a remedy without cures in existence.
    what i just dont understand is that in a normal gui api i just make a new instance of a component and add that to another component. When stuff should be visible you call show() or something like that. The example provided doesn't even have the navigation code included, with that added it becomes even more. How can we programmers make the mindshift from page thinking to component thinking if we are still bothered with concepts like navigation, taglibs, markup (JSP) etc.

    I wanna be able to do something like

    public class MyDiv extends Div{
       
       @Override
       public void htmlConstruct(){
           setScreenText("hello world");
           add( new Div("hello again") );
       }
       @Override
       public BaseProperties newHtmlProperties(){
            return new BaseProperties(){
                public String getOnclick(){
                    return "alert('you clicked me')";
                }
            }
       }
    }


    new MyDiv().render(stream);

    Actually i can do so in my own framework, but i wish this could be standard so that i can always do it like that. When you work like this your codebase is fully refactorable, wich is invaluable to me.
  20. Creating a JSF div component[ Go to top ]

    what i just dont understand is that in a normal gui api i just make a new instance of a component and add that to another component. When stuff should be visible you call show() or something like that. The example provided doesn't even have the navigation code included, with that added it becomes even more. How can we programmers make the mindshift from page thinking to component thinking if we are still bothered with concepts like navigation, taglibs, markup (JSP) etc. I wanna be able to do something like

    public class MyDiv extends Div{
    @Override...
    }new MyDiv().render(stream);Actually i can do so in my own framework, but i wish this could be standard so that i can always do it like that. When you work like this your codebase is fully refactorable, wich is invaluable to me.

    Well you have to look at the things the api designers probably wanted to achieve.
    They wanted an abstracted component definition with mvc
    on component level, to allow different technologies
    targets or different skins.

    They also wanted to have a legacy hook which is jsp.
    So you end up with 3 classes under normal circumstances (you can shortcut this by including the renderer into the component)
    Add to that that they wanted to achieve maximum render performance and you end up with a servlet printwriter api
    on the component side, which gives a linear runtime complexity on the rendering side.

    and they wanted to have tool support which means it is easiest to add that by introducing an xml glue.


    Get rid of JSP and you have gotten rid of about 1/3rd of the glue code (taglib xml def and jsp binding class)

    Inheritance is there in the api, components are derived from other components and renderer, but as things look simple if you just want to render away html, and do not have things like event handlers etc. they become complicated once you try to reach the targets the api designers tried to reach in their component api.

    As I said it is broken, because they shot over the top without providing a fast and easy layer which can cover 99% of all usecases in normal production systems (while other frameworks try only to cover those)

    I am glad that others already have produced this easy layer on top of jsf, all it needs is a push of one of those easy layers into the official specs.
  21. Creating a JSF div component[ Go to top ]

    I am glad that others already have produced this easy layer on top of jsf, all it needs is a push of one of those easy layers into the official specs.
    That is what i tried also, i mean i want my stuff to be JSF compatible but have a hard time finding out how. I think i will give it another try and see how far i can come this time. The code of the renderer is almost the same as what i do except that jsf seems to have a renderer for every component whereas i have one renderer for every technology (HTML,backbase,laszlo,swing etc). My htmlrenderer is the only one that is full fledged but it is really cool to see the apps you build popup in different view technolgies. On the other hand i do see no reason now to have different technolgies supported if everything runs fine in the browser but it is nice to be on the safe side when something new comes up. If you write jsp with html in between you can forget about other technolgies without touching your application code.
  22. Creating a JSF div component[ Go to top ]

    Get rid of JSP and you have gotten rid of about 1/3rd of the
    >glue code (taglib xml def >and jsp binding class)

    if you will use jsf components in any markup language you need to describe them for the parser anyway. It is what taglib (or whatever it would be) is for.

    Dmitry
    http://www.servletsuite.com
  23. >Get rid of JSP and you have gotten rid of about 1/3rd of the >glue code (taglib xml def >and jsp binding class)if you will use jsf components in any markup language you need to describe them for the parser anyway. It is what taglib (or whatever it would be) is for.Dmitryhttp://www.servletsuite.com

    I think you don't get the problem. One of the main problems of coupling JSP with JSF is that JSP doesn't have a clue about the JSF request lifecycle. Facelets and Shale Clay do a far better job at it.

    http://www.theserverside.com/news/thread.tss?thread_id=26514

    I totally agree on this. Dump JSP and JSF become very easy to use.
  24. Dump JSP and JSF become very easy to use.

    JSP here == HTML (or WML or any markup you name). Drop JSP and you need do all the stuff in JSF only. So drop HTML people also etc. Is not it the same as "drop SQL and use EJB QL only"? Who was the winner there?

    Marina
    http://www.servletsuite.com
  25. Dump JSP and JSF become very easy to use.
    JSP here == HTML (or WML or any markup you name). Drop JSP and you need do all the stuff in JSF only. So drop HTML people also etc. Is not it the same as "drop SQL and use EJB QL only"? Who was the winner there?Marinahttp://www.servletsuite.com

    I am not getting fully what you want, jsp is one of the myriad of templating technologies in existence, it does not have anything to do with html.
    You can get rid of jsp by using Freemarker, Velocity or whatever, so dropping jsp in favor of facelets (nobody mentioned the enourmous speed increase facelets bring over jsp btw...) as alternating templating technology is a viable choice.
  26. See the original message:
    One of the main problems of coupling JSP with JSF is that JSP doesn't have a clue about the JSF request lifecycle. Facelets and Shale Clay do a far better job at it.

    So now is your wririting:
    You can get rid of jsp by using Freemarker, Velocity or whatever ...

    Are you sure that they (Freemarker, Velocity or whatever) have clue about the JSF request lifecycle?

    Marina
    http://www.servletsuite.com
  27. See the original message:
    One of the main problems of coupling JSP with JSF is that JSP doesn't have a clue about the JSF request lifecycle. Facelets and Shale Clay do a far better job at it.
    So now is your wririting:
    You can get rid of jsp by using Freemarker, Velocity or whatever ...
    Are you sure that they (Freemarker, Velocity or whatever) have clue about the JSF request lifecycle?Marinahttp://www.servletsuite.com

    You are mixing posts not written by the same guy! I wrote the first one which was specific about not using JSF and JSP together. The second one is from Werner who was explaining what a template language is.
  28. Alexadre, I am not mixing. At the first hand I've answered to your message. I've tried to explain that dropping JSP is not a good idea unless you are ready to replace all the things with JSF.
    I've quoted the original message from the same sub-tree.

    Marina
    http://www.servletsuite.com
  29. Alexadre, I am not mixing. At the first hand I've answered to your message. I've tried to explain that dropping JSP is not a good idea unless you are ready to replace all the things with JSF. I've quoted the original message from the same sub-tree.Marinahttp://www.servletsuite.com

    You mix things up here, it is not really that much of an afterthought of replacing jsp, since you are in a page centric model anyway, you can replace some jsp legacy stuff with different templating techs over time.
    I have a system running here, which started to embracy Jetspeed early up, once the customer decided not to use the portlet functionality anymore using the entire velocity infrastructure on top of jetspeed/turbine only made partially sense and for small things some parts were moved over to simple jsp, with jsf being added experimentally to the mix (sort of a proof of concept in a spare time)
    The idea was to phase out the old codebase if the system needs an overhaul in the future and base it on something easier to maintain, better suitable for the task, without interrupting the production use significantly.
  30. Creating a JSF div component[ Go to top ]

    Ah an one word about the lifecycle handling, of course you cannot interrupt into the jsf lifecycles from outside of a jsf context (after all the lifecycles are triggered by the underlying servlet)
    but you can reach the JSF infrastructure and even trigger it.
    JSF has quite a smart design in this regard by utilizing request scoped singleton patterns and Factories internally.

    Adding a different rendering infrastructure to JSF is possible but a lot of work.
    But this is an issue which never occurs in a typical migration situation where you phase out view technologies over time.
  31. Creating a JSF div component[ Go to top ]

    I don't think we are all clicking here with what JSF is trying to do-- you shouldn't have to be writing/developing components. Taking your example, screenText should just be an EL binding from the UI.
    <<t:div onclick="alert('makes sense');">#{myBean.that.does.not.have.any.ui.code}</t:div>

    With all of these frameworks, you are developing two different artifacts-- your view and then your wiring code. You shouldn't have to do wiring code with JSF and if you do, it should be as minimal and as agnostic as possible.

    Some of the 'stuff' I'm working on now and has been done by Exadel and Oracle, is making your views dynamic-- so your ONE declaration of UI concerns can be operated/evaluated in different modes without asserting development special cases in *your* business code.
  32. Creating a JSF div component[ Go to top ]

    I don't think we are all clicking here with what JSF is trying to do-- you shouldn't have to be writing/developing components. Taking your example, screenText should just be an EL binding from the UI.

    EL is exactly what i dont wanna use because it is not refactorable. When i do

    @Override
    public String getScreenText(){
        return getUser().getContact().getSearchName();
    }

    I can seamlessly refactor the getContact method of the user. How would i do that with EL?

    And as someone stated earlier I like building custom compositions. Extending components and adjust them a little to suite the needs for the context works out great for me. From what i read from the posts there are enough programmers that like to work with an API, the expert group seems to think that everybody wants to use JSP, I think it is clear now that this is not the case.
    With all of these frameworks, you are developing two different artifacts-- your view and then your wiring code. You shouldn't have to do wiring code with JSF and if you do, it should be as minimal and as agnostic as possible.

    Can you please explain what you mean by wiring code in this context. And how jsf doesn't need it, a little example would help because i really like to understand what you mean here.
  33. Creating a JSF div component[ Go to top ]

    I can seamlessly refactor the getContact method of the user. How would i do that with EL?

    You would reference the property directly in EL or alias it within a nother variable. I know it's different than your solution but you end up controlling the need for intermediate layers such that you can use #{user.contact.searchName} directly without a component or you can create a POJO facade to instead reference #{backingBean.screenText}. It's up to you.
    With all of these frameworks, you are developing two different artifacts-- your view and then your wiring code. You shouldn't have to do wiring code with JSF and if you do, it should be as minimal and as agnostic as possible.
    Can you please explain what you mean by wiring code in this context. And how jsf doesn't need it, a little example would help because i really like to understand what you mean here.

    http://weblogs.java.net/blog/jhook/archive/2006/03/extending_the_w.html
  34. Creating a JSF div component[ Go to top ]

    I can seamlessly refactor the getContact method of the user. How would i do that with EL?
    You would reference the property directly in EL or alias it within a nother variable. I know it's different than your solution but you end up controlling the need for intermediate layers such that you can use #{user.contact.searchName} directly without a component or you can create a POJO facade to instead reference #{backingBean.screenText}. It's up to you.
    With all of these frameworks, you are developing two different artifacts-- your view and then your wiring code. You shouldn't have to do wiring code with JSF and if you do, it should be as minimal and as agnostic as possible.
    Can you please explain what you mean by wiring code in this context. And how jsf doesn't need it, a little example would help because i really like to understand what you mean here.
    http://weblogs.java.net/blog/jhook/archive/2006/03/extending_the_w.html

    Your suggestions add unnessecary verbosity to application code, to me that is unacceptable. That a component knows about its children and parent seems dangerous and inflexable but i learned out of experience that it is actually more flexible than restrucuring markup, eventually it is all code no matter how you call it. If xml-ish like syntax was so comfortable then wouldn't james made java like that. If i wanna use something that is not java it should be at least less verbose and more readable. AFAIAC there is no such thing. Jacob dont get me wrong, i am not trying to push my framework, i am trying to have some influence on the imposed standard. I think EG should give guys/girls that wanna code like this a way to do so. Dont protect us against our selves. I know it can be done right now but not in an intuitive manner.
  35. Creating a JSF div component[ Go to top ]

    I think EG should give guys/girls that wanna code like this a way to do so. Dont protect us against our selves. I know it can be done right now but not in an intuitive manner.

    I could do:
    public void setComponent(HtmlOutputText text) {
      text.setTransient(true);
      text.setValue("This is my text");
    }

    and in the UI
    <h:outputText binding="#{bean.component}"/>

    So you can (somewhat) in the current JSF spec, just that not many people do it. The carstore demo included with the JSF RI does this to basically build a whole view/form from a properties file.
  36. I think EG should give guys/girls that wanna code like this a way to do so. Dont protect us against our selves. I know it can be done right now but not in an intuitive manner.
    I could do:
    public void setComponent(HtmlOutputText text) {&nbsp;&nbsp;text.setTransient(true);&nbsp;&nbsp;text.setValue("This is my text");}
    and in the UI
    <h:outputText binding="#{bean.component}"/>
    So you can (somewhat) in the current JSF spec, just that not many people do it. The carstore demo included with the JSF RI does this to basically build a whole view/form from a properties file.
    thkx, i will have a look at the demo you mention
  37. Creating a JSF div component[ Go to top ]

    As an app developer you probably will never touch the component api anyway, ...

    Wrong.

    Sometimes you have redudancy in your JSF views you can reduce by define a component. For instance:

    - A set of related fiels repeats on meny forms. You want to put them in a custom component.

    - There are set of properties you allways set to the same
    values for each instance of a component type. Yo want to make a component just with different defaults.

    I have to mention JSP tag files here. There are designed to solve this kind of problems. But all standard JSF tag attributes use rtexpvalue=false, and you can't put even <f:subview id="${id}"> in a tag file.

    Nebojsa
  38. Exactly Nebojsa. I asked for easy functionality to extract groupings of layout and component 'invocations'to a component/module like thing during the public review of JSF 1.2. I think the response was that it was too late for that.
    It seems that facelets make that very easy, though.
  39. I asked for easy functionality to extract groupings of layout and component 'invocations'to a component/module like thing during the public review of JSF 1.2. I think the response was that it was too late for that.
    It seems that facelets make that very easy, though.

    Looks like tag files will be more usable for this kind of functionality in JSF 1.2/JSP 2.1.
    In the specification drafts I have just read:

    JavaServer™ Faces Specification, Version 1.2 Proposed Final Draft 2, Section 9.3.1.1 Past and Present Tag constraints:
    Tags that use the Unified EL have the following constraints:
    ■ all tag attributes must not have an rtexprvalue attribute

    JavaServer Pages™ Specification, Version 2.1(ProposedFinalDraft2), Section JSP.8.3 Semantics of Tag Files:
    tagf.tag:

    <%attribute name="attr1" deferredValue="true"/>
    <%attribute name="attr2" deferredMethod="true"/>
    <c:out value="${attr1.bar}"/>
    <h:commandButton value="#{attr1.foo}" action="#{attr2}"/>

    used in test.jsp

    <%taglib prefix="my" tagdir="/WEB-INF/tags"%>
    <my:tagf attr1="#{someExpr}" attr2="#{someMethod}"/>

    I will try JSF 1.2 with JSP 2.1 before I finaly decide to migrate to Facelets.

    Nebojsa
  40. Creating a JSF div component[ Go to top ]

    As an app developer you probably will never touch the component api anyway, ...
    Wrong. Sometimes you have redudancy in your JSF views you can reduce by define a component. For instance:- A set of related fiels repeats on meny forms. You want to put them in a custom component.- There are set of properties you allways set to the samevalues for each instance of a component type. Yo want to make a component just with different defaults.I have to mention JSP tag files here. There are designed to solve this kind of problems. But all standard JSF tag attributes use rtexpvalue=false, and you can't put even <f:subview id="${id}"> in a tag file.Nebojsa

    Ahem you did not get my point entirely, as an app developer you can define components, but if I would not do it for general use, just for the project and inhouse projects, I probably nowadays would go a different way and use facelets for component definition, not the component API
  41. As an app developer you probably will never touch the component api anyway, ...
    Wrong. Sometimes you have redudancy in your JSF views you can reduce by define a component. For instance:- A set of related fiels repeats on meny forms. You want to put them in a custom component.- There are set of properties you allways set to the samevalues for each instance of a component type. Yo want to make a component just with different defaults.I have to mention JSP tag files here. There are designed to solve this kind of problems. But all standard JSF tag attributes use rtexpvalue=false, and you can't put even <f:subview id="${id}"> in a tag file.Nebojsa

    I agree and this is what I call a panel (a component aggregating others components). JSF native panel component suck but Facelets ui tags make those kind of components easy to produce (similar as writing a tag file).
  42. JSF sucks bigtime[ Go to top ]

    There is actually no good reason why reusing something should be much harder than just writing it otherwise. This is VB all over again, where you could program more-or-less fine, but couldn't write DLLs without resolving to incredible hacks.

    The JSF standard demonstrates how easy it is to come up with complex solutions for simple things. I don't see why making a div custom tag in JSF should be any harder than it is in JSP...

    --
    Jevgeni Kabanov
    http://www.araneaframework.org
  43. JSF sucks bigtime[ Go to top ]

    There is actually no good reason why reusing something should be much harder than just writing it otherwise. This is VB all over again, where you could program more-or-less fine, but couldn't write DLLs without resolving to incredible hacks.The JSF standard demonstrates how easy it is to come up with complex solutions for simple things. I don't see why making a div custom tag in JSF should be any harder than it is in JSP...--Jevgeni Kabanovhttp://www.araneaframework.org

    actually if you have it encapsuled it is easy to write, if you use facelets you can write it in a few lines of code as well and then have a custom tag.

    the main problem is if you go through all the hoops of the JSF component api, then things become really complicated. Fortunately for in project tags this is not necessary anymore thanks to stuff like shale clay or facelets (or even the myfaces aliasbeans)
  44. Div component in Facelets[ Go to top ]

    <arc:div styleClass="hello">
    Hello
    <arc:div styleClass="world">
    World !
    </arc:div>
    </arc:div>
  45. Div component in Facelets[ Go to top ]

    *Sorry about the last post.

    Let's try again:

    1. Taglib File:
    ...
      <tag>
        <tag-name>div</tag-name>
        <source>tags/div.xhtml</source>
      </tag>
    ...

    2. Component File (tags/div.xhtml):
    <ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets">
      <div class="#{styleClass}">
        <ui:insert/>
      </div>
    </ui:composition>

    3. In your page:
    ...
    <z:div styleClass="hello">
      Hello
        <z:div styleClass="world">
          World !
        </z:div>
    </z:div>
    ...

    For such a simple component, Facelets tag library definition is perfect.

    For more complex components, JSF adds a lot more flexiblity, at an added cost. Are we comparing Hello World again ?

    Regards,

    Nick
  46. Div component in Facelets[ Go to top ]

    Interesting example Nicolas. I'll have to delve into facelets, but this gives me a pretty good impression it seems.

    I must say this thread is (up to now...) a pleasant surprise to me: people with JSF experience pointing out shortcomings and strengths and pointing out fixes. A refreshing contrast to the usual TSS "JSF Sux, use OtherFramework, it rox" or "With MyOwnFramework this is very easy" with the obligatory linking sig.
  47. I think that JSF is rightfully trashed more than other frameworks because:
    - it came after many very good and high quality web frameworks were in production for prolonged period of time, so it supposed to learn the lessons;
    - JSF folks set the expectations that it will be THE THING;
    - it turned out that JSF is pretty much like Enterprise Beans – cumbersome and very painful without help from non-standard open source tools like XDoclet and alike or from high-end and very costly IDE;

    It is still debatable if JSF is like Entity Beans ( unusable) or Session Beans ( somehow usable), but my impression is that in any case in 99% of all cases there are better alternatives available.
  48. I think that JSF is rightfully trashed more than other frameworks because:- it came after many very good and high quality web frameworks were in production for prolonged period of time, so it supposed to learn the lessons;- JSF folks set the expectations that it will be THE THING;- it turned out that JSF is pretty much like Enterprise Beans – cumbersome and very painful without help from non-standard open source tools like XDoclet and alike or from high-end and very costly IDE;It is still debatable if JSF is like Entity Beans ( unusable) or Session Beans ( somehow usable), but my impression is that in any case in 99% of all cases there are better alternatives available.

    This is what I call FUD, tired of saying this kind of attitude. You don't like JSF and you prefer let's say Wicket or Tapestry. Fine! But back up your claims with technical argument instead of using the very easy sensationalist EJB argument. Some people see "JSF" and jump on the thread to write "How it's suck and how this other framework is the solution". What is funny is most of them haven't tried JSF...

    Anyway, it's getting hard to have a nice technical discussion on JSF. For instance, I agree with Werner, JSF component API needs some work but there are great work around out there. I was afraid at first to use JSF but after trying it and used it in couple of projects now, I must say it rocks!! Maybe it is why some people hate it so much ;)
  49. What is funny is most of them haven't tried JSF...

    Please prove that posters who didlike JSF never tried the technology.
    Anyway, it's getting hard to have a nice technical discussion on JSF.
    Ever wondered why?
  50. What is funny is most of them haven't tried JSF...
    Please prove that posters who didlike JSF never tried the technology.
    Anyway, it's getting hard to have a nice technical discussion on JSF.
    Ever wondered why?

    I can tell by the stupid comments that are patently false.

    How can someone claim to be a former or current user of JSF and not realize that you don't have to create a JSF component to output a <div/> tag.

    If it sounds like a Duck, walks like a Duck, then it is usually a Duck.

    P.S. AFLAK! I mean Quack!
  51. Div component in Facelets[ Go to top ]

    Maybe you should read people comments better before flagging them as "stupid" or "just FUD".

    The discussion (and the original posting itself) is not about the usefullness of that particular <div>-component but about how easy it is to create a custom component with JSF.

    It is not easy with JSF (even with Facelets) if your component is complex enough and also includes subcomponents (which is the case in "real" applications). It is much easier in other mature frameworks like Tapestry.

    Maturity is very important too. JSF is way behind other component-oriented frameworks. And, yes, I did try it and described my experience in

    http://jroller.com/page/obon?entry=my_first_experience_with_jsf
  52. Div component in Facelets[ Go to top ]

    Maybe you should read people comments better before flagging them as "stupid" or "just FUD". The discussion (and the original posting itself) is not about the usefullness of that particular <div>-component but about how easy it is to create a custom component with JSF.It is not easy with JSF (even with Facelets) if your component is complex enough and also includes subcomponents (which is the case in "real" applications). It is much easier in other mature frameworks like Tapestry. Maturity is very important too. JSF is way behind other component-oriented frameworks.

    I wouldn't say it's immature, just works differently-- the development emphasis is put elsewhere (out of the component and into the 'binding' flexability and model agnostic approaches).

    http://weblogs.java.net/blog/kito75/archive/2006/04/job_stats_indee.html
  53. Market acceptance[ Go to top ]

    Thank you Jacob, your argument (the link) is heavy enough, so I better follow the herd, right? ;-)

    Well I think I'll try my best to give "better" frameworks that just don't have "standards" written on them their fair share. I think it will be better for my customer too. In the meantime I wish you guys the best in improving your products and I will try to help you.

    If the JSF family were mature I wouldn't have to debug it in depth just to find out why nothing happens when I click some link (see my blog).
  54. Market acceptance[ Go to top ]

    Thank you Jacob, your argument (the link) is heavy enough, so I better follow the herd, right? ;-)Well I think I'll try my best to give "better" frameworks that just don't have "standards" written on them their fair share. I think it will be better for my customer too. In the meantime I wish you guys the best in improving your products and I will try to help you.If the JSF family were mature I wouldn't have to debug it in depth just to find out why nothing happens when I click some link (see my blog).

    No one in the EG says JSF is perfect at all things (see JSF J1 session abstracts), we all have the desire to make it better with annotations and other developer feedback in the 2.0 version starting up shortly. JSF does afford the luxury of being a standard which has already blossomed a large community that is making it better-- like the chaps involved with MyFaces or developers with IceFaces, Oracle, Sun, Exadel, IBM, BEA, JBoss, etc.
  55. Div component in Facelets[ Go to top ]

    Maybe you should read people comments better before flagging them as "stupid" or "just FUD". The discussion (and the original posting itself) is not about the usefullness of that particular <div>-component but about how easy it is to create a custom component with JSF.It is not easy with JSF (even with Facelets) if your component is complex enough and also includes subcomponents (which is the case in "real" applications). It is much easier in other mature frameworks like Tapestry. Maturity is very important too. JSF is way behind other component-oriented frameworks. And, yes, I did try it and described my experience inhttp://jroller.com/page/obon?entry=my_first_experience_with_jsf

    For a component framework to be popular, it would need a lot of people creating components for it. In this regard, JSF wins hands down.

    For a component framework to be popular, it would need to be easy to learn and use. In this regard, JSF wins hands down.

    For a component framework to be popular, it would need to toolable. In this regard, based on the number of vendors that support it, JSF wins hands down.

    For a component framework to be popular, it would need to be useable with simple IDEs. In this regard, based personal experience, JSF wins hands down.

    Yes the JSF component API is not quite up to snuff. Yes it is harder to create real JSF components in JSF than Tapestry. But Facelets closes the gap with composition components. Facelets composition components allow children.

    In general, the market has decided and JSF is the leading component framework in the Java web development space. Don't make me do a Dice poll.

    JSF is not perfect. But it is very good. Tapestry has parts that are better than JSF, but Tapestry has its own problems as well. No framework is perfect.
  56. Div component in Facelets[ Go to top ]

    Maybe you should read people comments better before flagging them as "stupid" or "just FUD". The discussion (and the original posting itself) is not about the usefullness of that particular <div>-component but about how easy it is to create a custom component with JSF.It is not easy with JSF (even with Facelets) if your component is complex enough and also includes subcomponents (which is the case in "real" applications). It is much easier in other mature frameworks like Tapestry. Maturity is very important too. JSF is way behind other component-oriented frameworks. And, yes, I did try it and described my experience inhttp://jroller.com/page/obon?entry=my_first_experience_with_jsf
    For a component framework to be popular, it would need a lot of people creating components for it. In this regard, JSF wins hands down.For a component framework to be popular, it would need to be easy to learn and use. In this regard, JSF wins hands down.For a component framework to be popular, it would need to toolable. In this regard, based on the number of vendors that support it, JSF wins hands down.For a component framework to be popular, it would need to be useable with simple IDEs. In this regard, based personal experience, JSF wins hands down.Yes the JSF component API is not quite up to snuff. Yes it is harder to create real JSF components in JSF than Tapestry. But Facelets closes the gap with composition components. Facelets composition components allow children.In general, the market has decided and JSF is the leading component framework in the Java web development space. Don't make me do a Dice poll.JSF is not perfect. But it is very good. Tapestry has parts that are better than JSF, but Tapestry has its own problems as well. No framework is perfect.

    For the record.... I never called anyone stupid.
  57. Div component in Facelets[ Go to top ]

    Don't make me do a Dice poll.

    No, please, no more Dice trolls.
  58. Dice Pool (not a troll)[ Go to top ]

    Don't make me do a Dice poll.
    No, please, no more Dice trolls.

    Seems like you were taunting me so here goes....

    Dice Poll for Web Component Frameworks

    JSF 265
    Tapestry 62
    Wicket 3

    :o)

    BTW JSF is higher than Struts was when it was only two years old.
  59. Dice Pool (not a troll)[ Go to top ]

    Don't make me do a Dice poll.
    No, please, no more Dice trolls.
    Seems like you were taunting me so here goes....Dice Poll for Web Component FrameworksJSF 265Tapestry 62Wicket 3:o)BTW JSF is higher than Struts was when it was only two years old.

    Yeah, that's really very meaningful. It's great to be amongst people that love technology.
  60. Dice Pool (not a troll)[ Go to top ]

    Don't make me do a Dice poll.
    No, please, no more Dice trolls.
    Seems like you were taunting me so here goes....Dice Poll for Web Component FrameworksJSF 265Tapestry 62Wicket 3:o)BTW JSF is higher than Struts was when it was only two years old.
    Yeah, that's really very meaningful. It's great to be amongst people that love technology.

    I do love technology. I love JSF, Spring, Tapestry and Hibernate. I even love Rife, Spring MVC, WebWork, etc.

    I took a look at Wicket. I did not like what I saw. It is nothing personal. I don't agree with the approach.

    It is an awfully big world with a lot of technologies. Different strokes for different folks....


    Rick Hightower (linked in),blog
    JSF, Spring, and Hibernate training and consulting
  61. Dice Pool (not a troll)[ Go to top ]

    I do love technology. I love JSF, Spring, Tapestry and Hibernate. I even love Rife, Spring MVC, WebWork, etc. I took a look at Wicket. I did not like what I saw. It is nothing personal. I don't agree with the approach.

    I think no-one would take that personal. Even the argument of taste is 1000 times better than pointing at Dice. Wicket is ranked #74 at sourceforge this month, and we're in the top 10 of their mailing lists. What does it mean? Nothing, which is exactly the reason I never boast them - except for the example now - on forums like this. I don't care about Dice numbers as it has nothing to do with technical (or even artistic) merrits.
  62. Dice Pool (not a troll)[ Go to top ]

    I do love technology. I love JSF, Spring, Tapestry and Hibernate. I even love Rife, Spring MVC, WebWork, etc. I took a look at Wicket. I did not like what I saw. It is nothing personal. I don't agree with the approach.
    I think no-one would take that personal. Even the argument of taste is 1000 times better than pointing at Dice. Wicket is ranked #74 at sourceforge this month, and we're in the top 10 of their mailing lists. What does it mean? Nothing, which is exactly the reason I never boast them - except for the example now - on forums like this. I don't care about Dice numbers as it has nothing to do with technical (or even artistic) merrits.

    I still rather do Wicket than Struts. :o)
  63. For a component framework to be popular, it would need a lot of people earning money on it. Not the 'evangelists' or tech. writers/copy pasters but the developers. In this regard, JSF ...
  64. For a component framework to be popular, it would need a lot of people earning money on it. Not the 'evangelists' or tech. writers/copy pasters but the developers. In this regard, JSF ...

    I put my first JSF app into production almost two years ago. I'v worked with many JSF apps since then. I use JSF in anger. :o)
  65. I can tell by the stupid comments that are patently false.How can someone claim to be a former or current user of JSF and not realize that you don't have to create a JSF component to output a <div/> tag.If it sounds like a Duck, walks like a Duck, then it is usually a Duck.P.S. AFLAK! I mean Quack!

    LOL, someone might say exactly the same about technologies (not limited to JSF mind you) just by reading specs and seeing that other people do with it.

    It it looks like c-p, smells like c-p, then it is c-p. No need to taste ;)

    Please give credit to people's intelligence. If a technology invites misuse then there is something wrong somewhere :)
  66. It looks like this thread is breaking down, but I thought I'd chip in anyway.

    I want to like/love JSF. I really do. There isn't any Java-centric web-view-creation framework out there that I'm really enamored with (WebWork comes closest). I gave JSF a try a month or so ago to develop a personal web site of mine. I found the experience to be frustrating. But I don't hate JSF. I think it has promise.

    I educated myself on JSF by reading Rick's JSF series on DW (thank you, Rick). Other resources I've found include stuff written by Jacob (thank you) and bits and pieces on the MyFaces site. Beyond these resources, I've had a difficult time Googling for answers to my JSF-related questions. I don't see a lot of "grass-roots" activity.
    How can someone claim to be a former or current user of JSF and not realize that you don't have to create a JSF component to output a <div/> tag.

    Rick, I think your statement is presumptious. I mean, if this is true, why does Tomahawk include a div component? There must be/must have been- some issue with using div tags in JSF.

    Truth be told, I remember having problems with the div tag a few weeks into my JSF ramp-up, but I think it was Facelets-specific, not JSF-specific. I seem to remember trying to output "<div> </div>", but kept ending up with "<div />" in my response, which the browser wasn't tolerating very well. For whatever reason, I ended up using the <t:div> tag.

    Rick, you also state:
    The "issues" raised in this posting have been solved 100 ways + they are fixed in later specs.

    That's great, but where are these solutions? Again, I don't remember having much luck Googling for JSF help, not for anything beyond the basics. Mind you, I'm not blaming anybody for this. Expecting to get everything for free is stupid. It seems like a lot of the best JSF tips and information comes out through threads such as these when JSF-advocates work to defend JSF from the JSF-haters. For example, I've used Facelets and like it very much, but it wasn't until reading this thread that I really came to understand just how much Facelets can be used to create custom components.

    One of my biggest problems with JSF is the feeling that you have to place a whole lot of trust that everything has been thought-out for you - at least from a component standpoint. And the fact (I believe) that all of the HTML tags that you write are internalized and regurgitated to be JSF-friendly makes me queasy.

    I believe that I had to create my own JSF component to create <script> tags for importing external JavaScript source files because the existing component didn't allow for a "source" attribute (it assumed that you were using it to inline script logic). I could be wrong.

    I also remember having a problem with Facelets' munging of HTML comment tags when I tried to make use of conditional comments (e.g., "<!--[if lte IE 6]>"). This got fixed in a later/recent release.

    I have more thoughts, but I don't want to bore people. I've enjoyed this discussion.
  67. It looks like this thread is breaking down, but I thought I'd chip in anyway.I want to like/love JSF. I really do. There isn't any Java-centric web-view-creation framework out there that I'm really enamored with (WebWork comes closest). I gave JSF a try a month or so ago to develop a personal web site of mine. I found the experience to be frustrating. But I don't hate JSF. I think it has promise.I educated myself on JSF by reading Rick's JSF series on DW (thank you, Rick). Other resources I've found include stuff written by Jacob (thank you) and bits and pieces on the MyFaces site. Beyond these resources, I've had a difficult time Googling for answers to my JSF-related questions. I don't see a lot of "grass-roots" activity.
    How can someone claim to be a former or current user of JSF and not realize that you don't have to create a JSF component to output a <div/> tag.
    Rick, I think your statement is presumptious. I mean, if this is true, why does Tomahawk include a div component? There must be/must have been- some issue with using div tags in JSF. Truth be told, I remember having problems with the div tag a few weeks into my JSF ramp-up, but I think it was Facelets-specific, not JSF-specific. I seem to remember trying to output "<div> </div>", but kept ending up with "<div />" in my response, which the browser wasn't tolerating very well. For whatever reason, I ended up using the <t:div> tag.Rick, you also state:
    The "issues" raised in this posting have been solved 100 ways + they are fixed in later specs.
    That's great, but where are these solutions? Again, I don't remember having much luck Googling for JSF help, not for anything beyond the basics. Mind you, I'm not blaming anybody for this. Expecting to get everything for free is stupid. It seems like a lot of the best JSF tips and information comes out through threads such as these when JSF-advocates work to defend JSF from the JSF-haters. For example, I've used Facelets and like it very much, but it wasn't until reading this thread that I really came to understand just how much Facelets can be used to create custom components.One of my biggest problems with JSF is the feeling that you have to place a whole lot of trust that everything has been thought-out for you - at least from a component standpoint. And the fact (I believe) that all of the HTML tags that you write are internalized and regurgitated to be JSF-friendly makes me queasy.I believe that I had to create my own JSF component to create <script> tags for importing external JavaScript source files because the existing component didn't allow for a "source" attribute (it assumed that you were using it to inline script logic). I could be wrong.I also remember having a problem with Facelets' munging of HTML comment tags when I tried to make use of conditional comments (e.g., "<!--[if lte IE 6]>"). This got fixed in a later/recent release.I have more thoughts, but I don't want to bore people. I've enjoyed this discussion.

    Agree with you it's frustrating to have to connect all those little pieces but a lot of those ideas are probably going to make it to the 2.0 specification. You can't get everything right in your first release. So I hope the 2.0 version will come out quickly.
  68. What is funny is most of them haven't tried JSF...
    Please prove that posters who didlike JSF never tried the technology.

    How to tell someone hasn't tried JSF :

    1) He doesn't seem to get anything at all about JSF. I'm not saying that because he doesn't like JSF, he doesn't get it (I hate this attitude). But some people comments clearly show they haven't tried JSF.

    2) He uses the typical FUD stuff "JSF needs tools support", "JSF is an overgengineed solution", "JSF is heavyweight", "JSF is for beginner only", "JSF is VB while [insert your framework here] is Java",... This list could go on and on.

    3) Bash JSF using the oversused old EJB or other ideological arguments. This *argument* is usually about JSF standard status.
    Anyway, it's getting hard to have a nice technical discussion on JSF.
    Ever wondered why?

    My guess? Some people want to push their ultimate favorite solution and they see red whatever they hear or read that several people love JSF. It's seem some people will always spit on official specification because it comes from *big capitalist companies who don't care about the technical stuff and just want to force me to pay for their crappy product*. Quite a simple vision if you ask me but hey you are free to think whatever you want!

    Also, in the last year, TSS has played the sensationalism card (especially on JSF) quite a lot, too much if you ask me. It's their choice but this site is becoming more and more like Slashdot.
  69. My guess? Some people want to push their ultimate favorite solution and they see red whatever they hear or read that several people love JSF. It's seem some people will always spit on official specification because it comes from *big capitalist companies who don't care about the technical stuff and just want to force me to pay for their crappy product*.

    To save you guess work I can tell exactly why I do not like JSF: I tried several times and even was able to create some working JSF UI:
    - very counterintuitive in many places even after reading Kito's book (zero substance in printed part, some usefulness in the complementary PDF);
    - Studio Creator was not working on Linux for few years because of JVM bug and they did not work around it as all other products – so I was not able to use 'tooling';
    - JSF implementations were incompatible;
    - same stupidity of endless cycle of recreation in JSF whatever HTML designers came up this day ( no, I do not have luxury dictating how everything should look and behave);


    Summary: FRUSTRATION.
  70. My guess? Some people want to push their ultimate favorite solution and they see red whatever they hear or read that several people love JSF. It's seem some people will always spit on official specification because it comes from *big capitalist companies who don't care about the technical stuff and just want to force me to pay for their crappy product*.
    To save you guess work I can tell exactly why I do not like JSF: I tried several times and even was able to create some working JSF UI:- very counterintuitive in many places even after reading Kito's book (zero substance in printed part, some usefulness in the complementary PDF);- Studio Creator was not working on Linux for few years because of JVM bug and they did not work around it as all other products – so I was not able to use 'tooling';- JSF implementations were incompatible;- same stupidity of endless cycle of recreation in JSF whatever HTML designers came up this day ( no, I do not have luxury dictating how everything should look and behave);Summary: FRUSTRATION.

    Well that's better, if JSF frustrates you and you are still concerned about it (since you participate in this thread), express you concerns. JSF isn't the best thing since sliced bread and has like other products shortcomings. I agree with lot of posters on this, the API to implement new components could be made more simple.
  71. Facelets are not enough[ Go to top ]

    A refreshing contrast to the usual TSS "JSF Sux, use OtherFramework, it rox" or "With MyOwnFramework this is very easy" with the obligatory linking sig.

    We aim to be obnoxious :)

    But seriously JSF is not "The Only Choice". What bothers me is not only that it is bad by itself, but that it is promoted by enough big players, that everything else must be compared to it.

    JSP was bad enough when it came out, and it took quite a time to get it done right (basically not before JSP 2.0). And JSP was a simple technology compared to JSF. Yes, facelets do simplify the task somewhat, but they are targeted at reusing view, not controller. So if I want to capture a encapsulated component of, let's say, client searching, I'm still stuck with a backing bean attached to a bunch of tags (correct me if I'm wrong, I haven't programmed with facelets).

    The obligatory link pointing to the web framework that provides the best solution to reuse in the wild, or your 5$ back ;)
    http://www.araneaframework.org
  72. Facelets are not enough[ Go to top ]

    Yes, facelets do simplify the task somewhat, but they are targeted at reusing view, not controller.

    First, here's what I get of JSF architecture. JSF separates the request treatment lifecycle (the application controller) in 6 distinct and well define phases. The controller delegates most of its jobs to UIComponents and backing beans. A backing bean is a simple business helper adapting the model to a specific View-Controller combo. Hence only when it comes to acccess and adapt the model, JSF effectivly merges the V and the C together like Swing does too. If it wouldn't, you would have the same mess as in Struts (separated Action and ActionForm). But good news, if you want to only reuse some controller functionnalities, JSF doesn't force you to implement event handlers in a backing bean. It just more convenient for the majority of use cases. An event handler can be implemented in a totally independant class equivalent to Struts Actions (the class only has to implement a given interface). So it is quite easy to reuse controllers in JSF. I really don't get your point here, please precise.
    So if I want to capture a encapsulated component of, let's say, client searching, I'm still stuck with a backing bean attached to a bunch of tags (correct me if I'm wrong, I haven't programmed with facelets).

    You lost me there. You want to have a generic reusable UI component (independant of the model) or reuse a complete part of the application? If you want the second, then it's normal you ship the bean with the pages, no??? Some search UI components already exist but they certainly don't force to use a certain model and it's better like that. Separation of concerns!

    By the way, a UI component is far from being a simple *tag*. It is a complete view helper.
  73. Facelets are not enough[ Go to top ]

    So it is quite easy to reuse controllers in JSF. I really don't get your point here, please precise.
    So if I want to capture a encapsulated component of, let's say, client searching, I'm still stuck with a backing bean attached to a bunch of tags (correct me if I'm wrong, I haven't programmed with facelets).
    You lost me there. You want to have a generic reusable UI component (independant of the model) or reuse a complete part of the application?

    We are talking in different languages here :) I'm fairly familiar with the JSF programming model, I just haven't programmed with the Facelet extension for JSF.

    My point was that to reuse custom application components in JSF you have to jump through quite a few hoops. Writing components is just too complex, and I really don't understand why such reusing should be harder than just writing such functionality in the first place.
  74. Div component in Facelets[ Go to top ]

    *Sorry about the last post. Let's try again: 1. Taglib File:...&nbsp;&nbsp;<tag>&nbsp;&nbsp;&nbsp;&nbsp;<tag-name>div</tag-name>&nbsp;&nbsp;&nbsp;&nbsp;<source>tags/div.xhtml</source>&nbsp;&nbsp;</tag>...2. Component File (tags/div.xhtml): <ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="" rel="nofollow">http://java.sun.com/jsf/facelets">&nbsp;&nbsp;<div class="#{styleClass}">&nbsp;&nbsp;&nbsp;&nbsp;<ui:insert/>&nbsp;&nbsp;</div></ui:composition>3. In your page: ...<z:div styleClass="hello">&nbsp;&nbsp;Hello&nbsp;&nbsp;&nbsp;&nbsp;<z:div styleClass="world">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;World !&nbsp;&nbsp;&nbsp;&nbsp;</z:div></z:div>...For such a simple component, Facelets tag library definition is perfect. For more complex components, JSF adds a lot more flexiblity, at an added cost. Are we comparing Hello World again ?Regards, Nick

    Good job!

    It is amazing how quick you can develop tags in Facelets.

    See: http://www-128.ibm.com/developerworks/java/library/j-facelets/

    The "issues" raised in this posting have been solved 100 ways + they are fixed in later specs.


    Rick Hightower (linked in),blog
    JSF, Spring, and Hibernate training and consulting
  75. Div component in Facelets[ Go to top ]

    *Sorry about the last post. Let's try again: 1. Taglib File:...&nbsp;&nbsp;<tag>&nbsp;&nbsp;&nbsp;&nbsp;<tag-name>div</tag-name>&nbsp;&nbsp;&nbsp;&nbsp;<source>tags/div.xhtml</source>&nbsp;&nbsp;</tag>...2. Component File (tags/div.xhtml): <ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="" rel="nofollow">http://java.sun.com/jsf/facelets">&nbsp;&nbsp;<div class="#{styleClass}">&nbsp;&nbsp;&nbsp;&nbsp;<ui:insert/>&nbsp;&nbsp;</div></ui:composition>3. In your page: ...<z:div styleClass="hello">&nbsp;&nbsp;Hello&nbsp;&nbsp;&nbsp;&nbsp;<z:div styleClass="world">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;World !&nbsp;&nbsp;&nbsp;&nbsp;</z:div></z:div>...For such a simple component, Facelets tag library definition is perfect. For more complex components, JSF adds a lot more flexiblity, at an added cost. Are we comparing Hello World again ?Regards, Nick

    In facelets you would just use a div....

    From http://article.gmane.org/gmane.comp.java.tapestry.user/36197

    in Tapestry:

    <div jwcid=" <at> Any" put="" whatever="" you="" like="" here="">
    </div>


    in Facelets:

    <div jsfid="" Any" put="" whatever="" you="" like="" here="">
    </div>

    In JSF:

    http://www.it-eye.nl/weblog/2006/04/25/creating-a-jsf-div-component/

    Yikes is right, but you would never have to do this b/c of http://myfaces.apache.org/tomahawk/htmlTag.html.

    The whole complaint is bogus. If you want Tapestry style components you can create them. If you want JSF style component development, use FreeMarker.

    You don't have to create a component to render a div tag. He was just so an example on how to create a component.
  76. Re: Creating a JSF div component[ Go to top ]

    As pointed out by plenty of others:

    * creating JSF components _is_ unnecessarily difficult, at least if you are targetting JSP (if you are targetting only facelets, it is easy)

    * this problem needs to be fixed by the next rev of the spec

    * however, day-to-day JSF development should not involve a lot of time spent writing JSF components (if you are doing this, you are probably "using it wrong")

    By nature, when you are creating new JSF components, you are solving some complex problem. The litmus test for a framework is: simple things easy, complex things possible, and JSF lives up to this. Certainly there is no reason on earth to write a JSF component to create divs! You are usually writing JSF components only if you want complex things like tab groups and pageable lists (which are _already_ complex).

    Basically, the biggest "problems" with JSF all come from problems with JSP. Ditch JSP and JSF is a real pleasure to use (almost all of the time).
  77. Re: Creating a JSF div component[ Go to top ]

    The litmus test for a framework is: simple things easy, complex things possible, and JSF lives up to this.

    Unfortunately, frameworks that "make the easy things easier and the hard things harder" also fit in your definition. I'm an idiot but not a total idiot, so I really don't need a framework to make easy stuff easier. I need frameworks that make the hard stuff easier. Most of what I see is framework developers building libraries that are easy for them to build but don't address the tough problems. Which means developers get pissed off over and over because they keep having to solve the same problems over and over. Seriosly, we're only just now starting to see continuation support in Java frameworks (like Rife and Seam)... sad.
  78. Re: Creating a JSF div component[ Go to top ]

    however, day-to-day JSF development should not involve a lot of time spent writing JSF components (if you are doing this, you are probably "using it wrong")

    Do you really think so? It's the thing I enjoy most about working with a (competing) component based framework: creating custom components. Mostly composite components, like an edit panel that I'll reuse throughout the same app, but also anything from specialized ajax components to other fancy stuff. It's a good way to get rid of code duplication.
  79. however, day-to-day JSF development should not involve a lot of time spent writing JSF components (if you are doing this, you are probably "using it wrong")
    Do you really think so? It's the thing I enjoy most about working with a (competing) component based framework: creating custom components. Mostly composite components, like an edit panel that I'll reuse throughout the same app, but also anything from specialized ajax components to other fancy stuff. It's a good way to get rid of code duplication.

    Based on your comment, you lack understanding of:

    a) what he is trying to say
    b) JSP 2.2 and Facelets role in creating "composition components"

    JSP 2.2 and Facelets allow you to create "composition components". This is what most app developer will create. You do not have to create components on a day to day basis to do JSF app development.

    Read:

    http://www-128.ibm.com/developerworks/java/library/j-facelets/

    "Trying to combine JSF and JSP is like trying to shoehorn a foot into a glove: it's possible, but it's really just a stopgap measure until something better comes along. In this article, (the author) introduces you to what he likes best about Facelets: easy HTML-style templating and reusable composition components."


    "While working on a JavaServer Faces (JSF) project recently, I had the pleasure of using Facelets for the first time. What I most liked about Facelets was that it let me create reusable composition components. Being able to take a page (like a JSP) and turn it into a component has been a real boon to my JSF development ever since. My conclusion? If you're not using Facelets (or JSP 2.2 or Clay), you're not getting the most you can out of JSF."

    "The mismatch between JSF and JavaServer Pages technology is a serious problem in JSF development. The issue is how to integrate JSP's dynamic content into JSF's component-based model. JSP is singularly focused on generating dynamic output, whereas JSF requires JSP to coordinate building a component model. The disjunct occurs because that task is beyond the original intention of JSP."

    ...

    "Composition components

    If you used Facelets only to define and use templates, you might be a bit disappointed. Although Facelets templating is full-featured and rich, it doesn't have as many features as a framework like Tiles, which is good for defining defaults, hierarchies of related templates, and such. (BTW Clay seems to do a better job of templating)."

    "Templating isn't where Facelets really shines, though: Facelets puts its best foot forward with composition components. (Interestingly, composition components also lend some benefits to Facelets templating; for example, you can leave out f:verbatim tags and miscellaneous h:outputText tags in Facelets because everything is treated as a component in a component tree. More on this later.)"

    "For the remainder of the article, I'll focus on the steps involved in creating and using composition components. Before I do that, though, let's make sure you have a clear picture of what makes these handy little code snips so great."

    http://www-128.ibm.com/developerworks/java/library/j-facelets/
  80. Based on your comment, you lack understanding of:a) what he is trying to say

    Ow gawd. I'm not worthy.
    b) JSP 2.2 and Facelets role in creating "composition components"JSP 2.2 and Facelets allow you to create "composition components".

    I don't frigging care about that! Will you please read what *I* wrote instead of assuming I was attacking JSF or any other framework?

    I said I especially enjoy the fact that component based frameworks allow you to create custom components. *Like* composite component, but it could be anything. Just like I'll sometimes use the collections API and sometimes I'll create my own datastructures. That shouldn't be rocketscience?!

    So for clarity: all I'm saying is that a component based framework should make it easy to create and work with custom components. To me, it's the whole point of these frameworks!
  81. Trying to integrate business logic into UIComponents via the Java API is difficult. JSF almost forces you to separate your model from the presentation teir based on the request lifecycle. So anything that would've been expressed in a custom business component is now delegated to EL and consequently, you end up with a pluggable/reusable component that can be used in other contexts. So the logic that other frameworks would more easily route right into the component, instead gets referenced in pojo beans with JSF and declared in a model 1-ish scenerio in your UI.

    Is the tradeoff worth it? -- probably not as a internal developer. Then again, JSF's delegation to EL means you shouldn't need to write your own components from scratch. You can create a sortable/pagable/editable table over data without 'creating' a component, putting that logic into pojo beans instead of components.

    I've been ramping up for J1 and completed an inputsuggest component that can be used with any POJO bean:
    <e:suggest id="foo" value="#{page.employee}" from="#{company.suggestEmployees}">
    #{item.lastName}, #{item.firstName}
    </e:suggest>

    In the example above, I was able to use AJAX with any business object available over EL and customize the output, inlined in the UI-- which is hella better than RoR/Scriptaculous's customized example. With JSF, you declared your partially renderable view once, and then your backing bean (2 steps), with the RoR example, you had: initial view, controller, backing 'bean', and page fragment to coordinate. Who needs [(a-zA-Z)+]ails anyways?
  82. <e:suggest id="foo" value="#{page.employee}" from="#{company.suggestEmployees}">#{item.lastName}, #{item.firstName}</e:suggest>
    In the example above, I was able to use AJAX with any business object available over EL and customize the output, inlined in the UI-- which is hella better than RoR/Scriptaculous's customized example. With JSF, you declared your partially renderable view once, and then your backing bean (2 steps), with the RoR example, you had: initial view, controller, backing 'bean', and page fragment to coordinate. Who needs [(a-zA-Z)+]ails anyways?


    Right. But there are no magic things. It means that "[(a-zA-Z)+]ails" goes to your Java code presented by #{ } references. Sometimes it is good, but sometimes is not. Can you use another JSF page for the prepared suggestions? In other words can you eliminate the Java (the second step) at all (that is what PHP, RoR etc. are about)? E.g. sometimes do all the things in JSP is just much more easy from the deployment point of view (e.g. in hosted environment).

    Marina
    http://www.servletsuite.com
  83. Based on your comment, you lack understanding of:a) what he is trying to say
    Ow gawd. I'm not worthy.
    b) JSP 2.2 and Facelets role in creating "composition components"JSP 2.2 and Facelets allow you to create "composition components".
    I don't frigging care about that! Will you please read what *I* wrote instead of assuming I was attacking JSF or any other framework?I said I especially enjoy the fact that component based frameworks allow you to create custom components. *Like* composite component, but it could be anything. Just like I'll sometimes use the collections API and sometimes I'll create my own datastructures. That shouldn't be rocketscience?!So for clarity: all I'm saying is that a component based framework should make it easy to create and work with custom components. To me, it's the whole point of these frameworks!

    I agree. JSF with Facelets does this today. JSF 1.2 with JSP 2.2 does it as well. Without these JSF is less perfect but still very useful (you could still use subviews or create custom components but it was clunky).

    I'll admit JSF is not perfect, but it is very useful and productive. The post in question (the response to the original post) was spreading FUD: plain and simple.

    Your main points are moot b/c you can create composition components easily with JSF.
  84. Re: Creating a JSF div component[ Go to top ]

    As pointed out by plenty of others:* creating JSF components _is_ unnecessarily difficult, at least if you are targetting JSP (if you are targetting only facelets, it is easy)* this problem needs to be fixed by the next rev of the spec* however, day-to-day JSF development should not involve a lot of time spent writing JSF components (if you are doing this, you are probably "using it wrong")By nature, when you are creating new JSF components, you are solving some complex problem. The litmus test for a framework is: simple things easy, complex things possible, and JSF lives up to this. Certainly there is no reason on earth to write a JSF component to create divs! You are usually writing JSF components only if you want complex things like tab groups and pageable lists (which are _already_ complex).Basically, the biggest "problems" with JSF all come from problems with JSP. Ditch JSP and JSF is a real pleasure to use (almost all of the time).

    +1

    TSS seems to like to look through the smallest JSF fud and make a big posting about it.

    I know they like Tapestry (and I don't dislike it), but the fud is funny.

    Rick Hightower (linked in),blog
    JSF, Spring, and Hibernate training and consulting
  85. Creating a JSF div component[ Go to top ]

    Creating such a trivial component doesn't really expose any flaws or strengths of JSF. For example, over the last few months I have been building (in my spare time, somewhat slowly) JSF components for:

    - Yahoo Maps
    - Google Maps
    - Ajax operations

    Writing the taglibs and other JSP stuff isn't fun, but it is manageable. Many of the other minor annoyances I've found in JSF have been resolved in the 1.2 spec. Having to write things out using the ResponseWriter in your components, is however, a serious weakness and leads to spaghetti code of HTML, JavaScript, and Java.

    Sure this is fine for really simple components, but as you start getting into more complex components that may contain a bunch of HTML and a fair amount of JavaScript, you soon have a mess on your hands. I've been able to clean things up by refactoring the JavaScript quite a bit and letting it sit in its own file, but that simply ignores the problem.

    It would be really nice to see a more elegant way of handling this in the future.
  86. I've created a screencast showing tooling support in JDeveloper for JSF: IDE productivity for JSF: a screencast.
  87. Why do they create a div tag? Why not just use an h:panelGroup which renders a div?

    Or if you want to generate any HTML tag and you are using JSP instead of Facelets....

    You could just use:

    <t:htmlTag value="br" />

    OR

    <t:htmlTag value="div" > [Other JSF tags/content] </t:htmlTag>


    From....

    http://myfaces.apache.org/tomahawk/htmlTag.html

    Since there are so many common ways to render a div, why even post this stuff. There was no need to create a div component anyway.

    The biggest issue with developing JSF components seems to be the components look like a Servlet from 1998 (pre JSP).

    Hmmm... what did we do back then... We used templates. Use FreeMarker or Velocity if you must and get over it. They will add support at some point in the future. We created Servlets before JSP. We created custom tags before JSF tagfiles. We can create JSF components before compfiles or whatever they will be called. Just use FreeMarker for now... It will be added, and as Gavin stated you won't need to create comps that often. And, there is always Facelets where you don't have to create comps at all due to composition components.

    Also, it seems Facelets can be used as the templating mechanism inside of a component (although I can't confirm this).

    So let me say this about this post: FUD FUD FUD FUD

    Don't believe it for a second.

    Please read:
    http://www-128.ibm.com/developerworks/java/library/j-facelets/



    --Rick Hightower

    Info:
    LinkedIn https://www.linkedin.com/in/rickhigh
    Blog http://www.jroller.com/page/RickHigh
    Company http://www.arc-mind.com JSF, Spring, and Hibernate training and
    consulting
    Clearing up the JSF FUD
    http://www-128.ibm.com/developerworks/library/j-jsf1/
    http://www-128.ibm.com/developerworks/library/j-jsf2/
    http://www-128.ibm.com/developerworks/library/j-jsf3/
    http://www-128.ibm.com/developerworks/library/j-jsf4/

    Rick Hightower (linked in),blog
    JSF, Spring, and Hibernate training and consulting
  88. I agree, a div tag doesn't make much sense, i've stated this in my post. I just wanted to describe what is involved in creating a minimal jsf component.

    Btw, i think the panelGroup component doesn't create divs, it creates spans, and only if you provide it with an attribute. Otherwise it doesn't write out the span tag. This was actually going to be my next post, to describe how you can create a custom renderer for an existing component, the panelGroup tag.
  89. I agree, a div tag doesn't make much sense, i've stated this in my post. I just wanted to describe what is involved in creating a minimal jsf component.Btw, i think the panelGroup component doesn't create divs, it creates spans, and only if you provide it with an attribute. Otherwise it doesn't write out the span tag. This was actually going to be my next post, to describe how you can create a custom renderer for an existing component, the panelGroup tag.

    Hey thanks for responding. I get it now. You create a simple example to show how to create a component (an easy one at that), and then someone writes about how dumb JSF is b/c you have to write a component to output a div tag (which is untrue). This was FUD from the get go. Thanks for clarifying it. (Yours was not FUD but the response was.)

    I do remember panelGroup outputting a span instead of a div. It just seems wrong. Is this the case with every renderer? Still the tomahawk htmlTag let's you output anything, and then there is Facelets that handles div and other html/component mixing with ease.

    Rick Hightower (linked in),blog
    JSF, Spring, and Hibernate training and consulting
  90. Rick introducing a template technology like Freemarker and Velocity to overcome the pains of the printwriter api (I know what I am talking about, I am currently into this mess)
    is not an option, due to the fact that they all are interpreted and you get a speed hit once you introduce them on a level where the templates are rendered 100 times away.
    It worked in velocity because mostly you rendered away entire pages and used its macro mechanism (which is an elegant componetization mechanism btw)

    It has been done to add velocity to the component API, Matthias Wessendorf gave it a try, but I dont think this is the solution to the problem. The solution in my opinion on this level of rendering is to introduce a postcompile step which compiles a good template markup on the fly into the api.

    Interpretation in my opinion does not make sense at that stage of rendering, while it can make a lot of sense at a higher level, thanks to better caching being achievable there.
  91. Rick introducing a template technology like Freemarker and Velocity to overcome the pains of the printwriter api (I know what I am talking about, I am currently into this mess)is not an option, due to the fact that they all are interpreted and you get a speed hit once you introduce them on a level where the templates are rendered 100 times away.It worked in velocity because mostly you rendered away entire pages and used its macro mechanism (which is an elegant componetization mechanism btw)It has been done to add velocity to the component API, Matthias Wessendorf gave it a try, but I dont think this is the solution to the problem. The solution in my opinion on this level of rendering is to introduce a postcompile step which compiles a good template markup on the fly into the api.Interpretation in my opinion does not make sense at that stage of rendering, while it can make a lot of sense at a higher level, thanks to better caching being achievable there.

    You make a good point and I think you are right. Perhaps Facelets would make a much better templating mechansim for JSF components (not composition components but the real thing). I don't know if this is possible with Facelets b/c I have not tried it, but based on what I know it seems possible. Based on the Facelets manual it seems possible since you can create a component tree using the API.

    Thus Facelets with its EL support and component aware-templating would allow you to get around many problems with JSF component development (the real component development not the composition components).

    The JSF API for component development is an evolutionary step to something better. There are better things today. Some of these ideas will make it into the official spec. someday.
  92. Creating a JSF div component[ Go to top ]

    LOL. Several dogs ...
  93. Creating a JSF div component[ Go to top ]

    Yes, several dogs defend the grave.