Discussions

News: JSF 2.0 Cross-field Form Validation – With Seam, Simple in Reality

  1. From @ocpsoft and @lincolnthree. Read the original article on OcpSoft.

    I’d like to start by saying that using JSF by itself can sometimes feel trying to pull your own teeth out with a pair of tweezers, but there’s hope. JSF was designed to be a platform of extensions – a foundation for building web-frameworks, and that it’s done very well. JSF 2.0 addresses most of the concerns about usability (so there’s less tooth pulling,) and provides even more extensibility. That’s where Seam Faces comes in, that’s where PrettyFaces comes in.

    On many occasions you might find yourself needing to compare the values of multiple input fields on a given page submit: confirming a password; re-enter password; address lookups; and so on. Performing cross-field form validation is simple – just place Seam’s <s:validateForm> component in the form you wish to validate, then attach your custom Validator.

    I’d like to introduce you to Seam’s intuitive answer, taken directly out of the reference manual. If you want to try it out, you can check out the source or use a snapshot:

    <dependency>
    <groupId>org.jboss.seam.faces</groupId>
    <artifactId>seam-faces</artifactId>
    <version>${seam-faces-version}</version>
    </dependency>

    Seam Faces’ <s:validateForm>

    <h:form id="locationForm">
    <h:inputText id="city" value="#{bean.author}" />
    <h:inputText id="state" value="#{bean.title}" />
    <h:inputText id="zip" value="#{bean.text}" />
    <h:commandButton id="submit" value="Submit" action="#{bean.submitPost}" />
     
    <s:validateForm validatorId="locationValidator" />
    </h:form>

    The corresponding Validator for the example above would look something like this:

    @FacesValidator("locationValidator")
    public class LocationValidator implements Validator
    {
    @Inject
    Directory directory;
     
    @Inject
    @InputField
    private Object city;
     
    @Inject
    @InputField
    private Object state;
     
    @Inject
    @InputField
    private ZipCode zip;
     
    @Override
    public void validate(final FacesContext context, final UIComponent comp, final Object values) throws ValidatorException
    {
    if(!directory.exists(city, state, zip))
    {
    throw new ValidatorException(new FacesMessage("Sorry, that location is not in our database. Please try again."));
    }
    }
    }

    Tip – You may inject the correct type directly.

    @Inject
    @InputField
    private ZipCode zip;

    Notice that the IDs of the inputText components match the IDs of your Validator @InputFields; each @Inject @InputField member will be injected with the value of the form input field who’s ID matches the name of the variable.

    In other words – the name of the @InputField annotated member variable will automatically be matched to the ID of the input component, unless overridden by using a field ID alias (see below.)

    <h:form id="locationForm">
    <h:inputText id="cityId" value="#{bean.author}" />
    <h:inputText id="stateId" value="#{bean.title}" />
    <h:inputText id="zip" value="#{bean.text}" />
    <h:commandButton id="submit" value="Submit" action="#{bean.submitPost}" />
     
    <s:validateForm fields="city=cityId state=stateId" validatorId="locationValidator" />
    </h:form>

    The field with ID “zip” will still be referenced normally; you need only specify aliases for fields that differ in name from the Validator @InputFields.

    Tip – Using @InputField

    Using @InputField("customID") with an ID override can also be used to specify a custom ID, instead of using the default: the name of the field. This gives you the ability to change the name of the private field, without worrying about changing the name of input fields in the View itself.

    @Inject
    @InputField("state")
    private String sectorTwo;

    A few last thoughts

    First, as of the current version, cross-field validation does not work unless you are using the <s:validateForm> component. As soon as a new version of weld-extensions is released, however, this functionality will work even without the <s:validateForm> component, and you’ll be able to reference cross-fields in any JSF validator!

    For right now, however, you’ll have to deal with using the component – but – it’s really not that complicated if you think about it Happy coding!

    About the author:

    Lincoln Baxter, III is a Senior Software Engineer at Red Hat, Inc., working on JBoss open-source projects. This blog represents his personal thoughts and perspectives, not necessarily those of his employer.

    He is a founder of OcpSoft, the author of PrettyFaces: bookmarking, SEO extensions for JSF, and an individual member of the JavaServer™ Faces Expert Group. When he is not swimming, running, or playing Ultimate Frisbee, Lincoln is focused on promoting open-source software and making web-applications more accessible for small businesses, individuals. His latest project is ScrumShark, an open-source, agile project management tool.

    Threaded Messages (26)

  2. My Solution[ Go to top ]

    Hi Mr. Baxter. I propose that you try Wicket instead.

    I've been using it and I have all my teeth intact.

    I also propose that JSF 3.0 be made more inline with the Wicket Web Framework way of doing things so as not to reinvent the wheel for each major JSF release.

    I hope Oracle notices Wicket and the Wicket team.  Those Wicket guys are devilishly smart people.

    Don't get me wrong. JSF 2.0 is an improvement, but Wicket is really nicer. You get less noise.

    Peace.

  3. JSF 3?[ Go to top ]

    JSF 3.0? Wow, we're just starting to figure out the pros and cons associated with JSF 2!

  4. Primitive[ Go to top ]

    But why on the earth after about 2 decades of Java and zillion of frameworks covering almost everything, spec 1.0 of something is always so primitive.

    It's true for Servlet

    It's true for JSP EL

    It's true for JPA.

    It's true for JSF

    OK, stop here, naming EJB would be as shooting the red cross. 

    I don't think that JSR EGs have "make developer life easy" as their first purpose.

     

    Guido

  5. Pretty neat![ Go to top ]

    Lincoln, this is actually pretty neat!

    What I currently use as trick to achieve this is using f:param tags on one of the components, and these f:param tags get a reference to the other components (I bind those other components to a map that's declared as a managed bean, so I can easily pass 'references' to them to other components).

    This however is MUCH nicer! The annotations for declaring faces artifacts like components and validators already made our lives much easier and this just continues the trend :)

    One thing I also really would like to see, is the ability to somehow declare the Facelets tag attributes as well as the tag name and name space of my Java based custom component using annotations.

    So something like:

    @FacesComponent

    @Facelets(name="Foo", name-space="com.bar.kaz/components")

    public class Foo extends UIComponentBase {

     

    }

    With maybe some clever defaults, so you can omit the tag name and then the class name will be used instead.

    Additionally, some smart injection might be used to inject the dynamic values from the value expressions in the attribute map of the component, which at the same time could be read by the editors to help in content assisting:

     

    @FacesComponent

    @Facelets(name-space="com.bar.kaz/components")

    public class Foo extends UIComponentBase {

    @Inject

    @Attribute

    String color; // will be injected with getAttributes("color") 

     

    @Inject

    @Attribute(shortDescription="This will determine the ...", required=true)

    String style;

    }

     

    E.g. something like the annotations equivalent for cc:attribute in composite components.

  6. Nice idea[ Go to top ]

    I like the proposed API -- I'll see what we can do :)

  7. Nice idea[ Go to top ]

    I like the proposed API -- I'll see what we can do :)

     

    Thanks a lot just for considering this :) I would be really over the moon if something like that would eventually appear in either JSF itself or be available via some Seam extension.

  8. Sheesh...[ Go to top ]

    Some topics generate meaningless comments very predictably.  Maybe TSS should implement comment filtering.  If the article contains "IBM," invariably someone always chimes in about IBM being the worst thing since bubonic plague.  If the topic is "JSF", someone always chimes in with "JSF sucks. Try [Wicket|Stripes]"

  9. Sheesh...[ Go to top ]

    That last bit was supposed to be "Try Wicket, or Stripes, or Tapestry"

  10. Sheesh...[ Go to top ]

    That last bit was supposed to be "Try Wicket, or Stripes, or Tapestry"

    It's typically Wicket when it concerns JSF and Spring when it concerns EJB. The thing is that both are really not bad technologies by them selves. I've started to build some things with Wicket, and it actually really is a nice framework if you're a fan of defining your GUI in Java (I personally am as I have a strong desktop background, but not everybody is).

    The thing is that this "JSF sucks" and "Wicket is orders of magnitude better" is just completely nonsense. There is an amazing amount of development going on with JSF and I think many parts of the framework are quite elegant.

    I think this continuous harassment only works against Wicket. I proposed Wicket for some project a while back, but some of the other developers' reaction was: isn't that from those guys who are always such a nuisance on the Net?

  11. Sheesh...[ Go to top ]

    I think this continuous harassment only works against Wicket. I proposed Wicket for some project a while back, but some of the other developers' reaction was: isn't that from those guys who are always such a nuisance on the Net?

    Just for the record, none of Wicket committers engage in such "harassment".

  12. Sheesh...[ Go to top ]

    I think this continuous harassment only works against Wicket. I proposed Wicket for some project a while back, but some of the other developers' reaction was: isn't that from those guys who are always such a nuisance on the Net?

    Just for the record, none of Wicket committers engage in such "harassment".

    Of course, that goes without saying. I'm sorry if my post implied otherwise. 'from those guys' referred to some of the trolls on the boards, not the original developers.

     

  13. Sheesh...[ Go to top ]

    I think this continuous harassment only works against Wicket. I proposed Wicket for some project a while back, but some of the other developers' reaction was: isn't that from those guys who are always such a nuisance on the Net?

    So when people are so excited about a tool (which is hardly ever criticized, BTW) and recommend it to others, they are a nusiance?  That sounds like a rationalization to me.  Let alone the complete irrationality of thinking that how annoying (or not) the vocal users of a tools are has anything to do with whether it's a good technical tool.  You can call me a jerk but I think that if you can't discuss something without invoking fallacies, you shouldn't be anywhere near a programming tool (or making any decisions IMO.)

    A few years back, I saw dynamic language adovocates as being annoying.  One day I realized that unless I tried it, I had no basis for dismissing them.  So I tried out Python and it turned out to be a really great choice.  I still use Java but I have a much better perspective on it's strengths and weaknesses.

    I think that people need to stop treating ideas that are foreign to them like some sort of brain infecting heresy.  What are people so afraid of?  Could it be finding out that there's a better way than what they've been doing?  Does it really make sense to blindly follow a path without exploring other options?

    I remember a time when people used to champion Hibernate in EJB discussions and that they were deingrated for doing so.  A short time later, EJB basically adopted the hibernate methodology.  This is how these changes happen.  This is where the debate is held.

  14. I think this continuous harassment only works against Wicket. I proposed Wicket for some project a while back, but some of the other developers' reaction was: isn't that from those guys who are always such a nuisance on the Net?

    So when people are so excited about a tool (which is hardly ever criticized, BTW) and recommend it to others, they are a nusiance?  That sounds like a rationalization to me.  Let alone the complete irrationality of thinking that how annoying (or not) the vocal users of a tools are has anything to do with whether it's a good technical tool.  You can call me a jerk but I think that if you can't discuss something without invoking fallacies, you shouldn't be anywhere near a programming tool (or making any decisions IMO.)

    A few years back, I saw dynamic language adovocates as being annoying.  One day I realized that unless I tried it, I had no basis for dismissing them.  So I tried out Python and it turned out to be a really great choice.  I still use Java but I have a much better perspective on it's strengths and weaknesses.

    I think that people need to stop treating ideas that are foreign to them like some sort of brain infecting heresy.  What are people so afraid of?  Could it be finding out that there's a better way than what they've been doing?  Does it really make sense to blindly follow a path without exploring other options?

    I remember a time when people used to champion Hibernate in EJB discussions and that they were deingrated for doing so.  A short time later, EJB basically adopted the hibernate methodology.  This is how these changes happen.  This is where the debate is held.

    +1 Mr. James Watson.

    Thanks for posting this thoughtful piece Mr. Watson.  I agree with everything you've said here.

     

    You get the feeling that you're in some kind of medieval technological age, and where you'll be branded and targeted as a heretic if you come out and say "Hey, this technology is not a the center of the technological universe."  Or worse yet, "This tech is crap compared to this one."

    As Mr. Watson has said, at least take a look-see first at the proposed alternative before start calling people trolls, or harrasers.

    -1 for Igor for falling into the group/herd effect trap.  Someone's promoting your hard work, so it's best to just take a bow.  To paraphrase you, "The Wicket committers don't harass."

     

    To borrow a nice phrase from a smart guy I know, "Don't become intellectually materialistic."  Technology comes and goes.  I'm open minded enough, and independent minded enough to look around.  You learn stuff that way, otherwise you end up not knowing better.

     

    So for those who don't know better, take a look at Wicket.  When you're done, come back and post your findings on this thread.

    By the way Igor, this link (http://wicket.apache.org/docs/wicket-1.3.2/wicket-extensions/) is not working on the Wicket site.  Can you take a look at that for me please.

    Peace out. :-)

  15. Sheesh...[ Go to top ]

     

    I remember a time when people used to champion Hibernate in EJB discussions and that they were deingrated for doing so.  A short time later, EJB basically adopted the hibernate methodology.  This is how these changes happen.  This is where the debate is held.

     

     

    Cut the crap James, that's a rather different situation and you know it. I remember that time well. Even the greatest EJB2 fans from back then loathed EJB entity beans. It was only natural something else was needed. The problem with Hibernate back then was not in its concepts (which basically everyone praised), but in its immature implementation and the many, many, many bugs. TopLink back then was a whole different beast; mature when Hibernate was still young and relatively few bugs.

    To compare the EJB/Hibernate situation from then to JSF/Wicket from now is silly at least and probably even deliberately misleading.

    Contrary to EJB session beans, JSF is an excellent technology. I know it's a popular thing to just bash everything from the Java EE standard, but bashing just for the sake of bashing is just stupid. If the Wicket guys came up with some valid points to criticize JSF with, then it might be semi-okay to post that (but better, write an article having that as the main topic and don't hi-jack a topic such as this).

    However, the average Wicket zealot only sees the word: "JSF", gets a pavlov reaction kicking in where his hands start typing : "JSF SUCKS!, JSF SUCKS! USE WICKET! WIKCET DUDE! WICKET IS THE BEST! WICKET IS NOT FROM AN EVIL COMMERCIAL VENDOR! WICKET IS GRASSROOT! GRASSROOT MEN! OPEN SOURCE! GRASSROOT + OPEN SOURCE IS GOOOOOOOOOOOOOD!"

    Well, I execrated a little, but that's basically what happens. Spring zealots have the same pavlov reaction when they see EJB: "EJB???? IS THAT STILL ALIVE? ROD TOLD US WE WON! ROD TOLD US WE MUST HATE! HATE EJB! HATE THE CONTAINER! AAARRRGGH!! USE SPRING! MAKE ROD RICH!!!" etc.

    It's all a little silly, really...

    The reaction of the other developers when I proposed Wicket is defendable. Sure, you should look primarily at the technology, but don't forget that at some point you have to hire new developers. In addition to that, you also have to ask questions on forums, interact with other Wicket users.

    If the believe is there that a majority of the Wicket users are those crazy seaolots, then this can detract from the attractiveness of using such a technology. As mentioned, we're also using JSF in our shop, the last thing we're waiting for is a Wicket zealot running around screaming like a madmen that each and every project in our portfolio has to be converted to Wicket.

    -That's- why the other guys in my team had some reservations about adopting Wicket for some particular project.

     

  16. Sheesh...[ Go to top ]

     

     

     

    I remember a time when people used to champion Hibernate in EJB discussions and that they were deingrated for doing so.  A short time later, EJB basically adopted the hibernate methodology.  This is how these changes happen.  This is where the debate is held.

     

     

     

     

     

     

    Cut the crap James, that's a rather different situation and you know it. I remember that time well. Even the greatest EJB2 fans from back then loathed EJB entity beans. It was only natural something else was needed. The problem with Hibernate back then was not in its concepts (which basically everyone praised), but in its immature implementation and the many, many, many bugs. TopLink back then was a whole different beast; mature when Hibernate was still young and relatively few bugs.

     

    To compare the EJB/Hibernate situation from then to JSF/Wicket from now is silly at least and probably even deliberately misleading.

     

    Contrary to EJB session beans, JSF is an excellent technology. I know it's a popular thing to just bash everything from the Java EE standard, but bashing just for the sake of bashing is just stupid. If the Wicket guys came up with some valid points to criticize JSF with, then it might be semi-okay to post that (but better, write an article having that as the main topic and don't hi-jack a topic such as this).

     

    However, the average Wicket zealot only sees the word: "JSF", gets a pavlov reaction kicking in where his hands start typing : "JSF SUCKS!, JSF SUCKS! USE WICKET! WIKCET DUDE! WICKET IS THE BEST! WICKET IS NOT FROM AN EVIL COMMERCIAL VENDOR! WICKET IS GRASSROOT! GRASSROOT MEN! OPEN SOURCE! GRASSROOT + OPEN SOURCE IS GOOOOOOOOOOOOOD!"

     

    Well, I execrated a little, but that's basically what happens. Spring zealots have the same pavlov reaction when they see EJB: "EJB???? IS THAT STILL ALIVE? ROD TOLD US WE WON! ROD TOLD US WE MUST HATE! HATE EJB! HATE THE CONTAINER! AAARRRGGH!! USE SPRING! MAKE ROD RICH!!!" etc.

     

    It's all a little silly, really...

     

    The reaction of the other developers when I proposed Wicket is defendable. Sure, you should look primarily at the technology, but don't forget that at some point you have to hire new developers. In addition to that, you also have to ask questions on forums, interact with other Wicket users.

     

    If the believe is there that a majority of the Wicket users are those crazy seaolots, then this can detract from the attractiveness of using such a technology. As mentioned, we're also using JSF in our shop, the last thing we're waiting for is a Wicket zealot running around screaming like a madmen that each and every project in our portfolio has to be converted to Wicket.

     

    -That's- why the other guys in my team had some reservations about adopting Wicket for some particular project.

     

    For the record, I didn't really listen to ROD.  My current stack is: Wicket + EJB 3.1 + JPA 2.0.

    Plus I also prefer using a real fullfledged Java EE application server over a servlet container, for my deployments.

    Like I said before, I like to look around, and please watch the broadside generalizations.

     

    Peace.

  17. Sheesh...[ Go to top ]

     

     

    For the record, I didn't really listen to ROD.  My current stack is: Wicket + EJB 3.1 + JPA 2.0.

    Plus I also prefer using a real fullfledged Java EE application server over a servlet container, for my deployments.

    Like I said before, I like to look around, and please watch the broadside generalizations.

     

    I think we're on the same page really ;) I too like to like around and as I said, Wicket is a pretty nice framework. Just like JSF it's component oriented. The main difference, as I think everyone knows, is that you define your UI using plain Java.

    There's also still a crowd who opposes the entire component idea for web development. In that battle, I think JSF and Wickets are partners, not enemies ;)

  18. Sheesh...[ Go to top ]

    I think we're on the same page really ;) I too like to like around and as I said, Wicket is a pretty nice framework. Just like JSF it's component oriented. The main difference, as I think everyone knows, is that you define your UI using plain Java.

    That sounds like a description of GWT to me, not Wicket.  In Wicket the UI is defined in HTML.  You can generate much of your page dynamically using Java (as I often do) so I can see where you are coming from.

    I know very little about JSF (which is why I have no opinion on it) but from what I can tell the main difference is that Wicket uses straight (valid) HTML for the page layout and JSF uses a template language.

  19. Sheesh...[ Go to top ]

    Cut the crap James, that's a rather different situation and you know it. I remember that time well. Even the greatest EJB2 fans from back then loathed EJB entity beans. It was only natural something else was needed. The problem with Hibernate back then was not in its concepts (which basically everyone praised), but in its immature implementation and the many, many, many bugs. TopLink back then was a whole different beast; mature when Hibernate was still young and relatively few bugs.

    "Cut the crap, James."  Is that your idea of a reasoned debate?  I'm not clear what your little screed is supposed to prove.

    In any event, that was not my recollection at all.  When hibernate first came on the scene, I would constantly see people bashing EJB and saying Hibernate was better.  There were plenty of EJB defenders saying that the Hibernate people were zealots and whatnot.

    If you look at the discussions here from 2004 you will see plenty of people defending J2EE (specifically entity beans) from the Hibernate zealots.  I can also point you to a Bilblog entry from the same time having a similar sentiment but the language is bit rough for work:

    http://www.theserverside.com/search/query?start=0&filter=1&q=J2EE+EJB+Hibernate

    To compare the EJB/Hibernate situation from then to JSF/Wicket from now is silly at least and probably even deliberately misleading.

    That you think I am comparing the two demonstrates that you completely misunderstood my point.  I'm  not saying the situation is the same.  I'm not even saying JSF is bad.  Why are you reading things from my words that I didn't write?

    I don't really see anyone here 'bashing' JSF.  Why does everyone have to go right to the ad hominem attacks?  I also don't see anyone saying why the Wicket advocate is wrong.  Maybe the person who likes Wicket over JSF has a good argument, maybe they don't.  All of this name calling is pointless.  Instead of discussing the merits of the different solutions we just have people cheering for their team or saying that both teams are OK.  None of this produces any meaningful dialog.  It's a shame too because on a rare occasion these forums can be quite illimuniting.

  20. Sheesh...[ Go to top ]

    I also don't see anyone saying why the Wicket advocate is wrong.  Maybe the person who likes Wicket over JSF has a good argument, maybe they don't. 

    The only reason I chimed in is because Douglas did not have an argument. The main article was not about pain points in JSF, so why post something about Wicket? And if you are going to do that at least have the descency to post some code and show WHY Wicket is better as related to the particular usecase being discussed in the main article. I thought substantiating once's claims was a common accepted practice even on the internets.

    I've been a Wicket committer for about five years and I can list off a hundred reasons why I think Wicket is better then JSF, but a comment thread on a JSF recipe article is hardly a place to do that...

  21. Sheesh...[ Go to top ]

    I also don't see anyone saying why the Wicket advocate is wrong.  Maybe the person who likes Wicket over JSF has a good argument, maybe they don't. 

     

    The only reason I chimed in is because Douglas did not have an argument. The main article was not about pain points in JSF, so why post something about Wicket? And if you are going to do that at least have the descency to post some code and show WHY Wicket is better as related to the particular usecase being discussed in the main article. I thought substantiating once's claims was a common accepted practice even on the internets.

     

    I've been a Wicket committer for about five years and I can list off a hundred reasons why I think Wicket is better then JSF, but a comment thread on a JSF recipe article is hardly a place to do that...

     

    Igor, please!!!

     

    What do you mean I don't have an argument?

     

    I can't read you. You are the one who went off and joined a team that developed an alternative web framework to JSF not me.  I on the other hand just simply said that I prefer working with Wicket rather than JSF.

     

    Since you have a 100 different reasons why Wicket is better than JSF then enlighten us.  You mean to tell me that if I hadn't said anything about Wicket vs JSF, you the Wicket committer would have just sat there and not said anything educational on the subject.  You'd rather direct your comments to my little Wicket plug. Wow.

     

    Okay then, let me say something educational then.  The main reason for me working with Wicket is that it's more productive and sane.  You just work with Java + XHTML.  No middle man technologies needed.  There, that's it. So for anyone who wasn't aware of that, now you know.  Igor can fill you in on the other 99 reasons why Wicket is a nicer choice over JSF.  

     

    Please note that there is no JSF bashing statement made here.  I'm just pointing out the obvious.

     

    And spare me the self righteous talk about posting Wicket stuff on a JSF thread.  It's an interactive medium.  I can post whatever I want.  You need to compare stuff where the opportunity presents itself so that the next version of the thing is better then the last one and people get a chance to see why one thing is better than the next.  That's why we now have JSF 2.0 and guess what, it's likely that you will have a JSF 3.0 right?

     

    Also, this is just the kind of post that got me to check out Wicket.  Some audience members like this kind of thing OK.  In an odd way, it also educates on choices.  Example, why I would use JSF 2.0 to build a web application rather than Perl. See what I'm saying here?

     

    Trust me man, just let it go please.  You're a Wicket committer.  I respect that.  Don't let me lose that respect ok.  This a JSF post and it sounds weird that a Wicket committer guy is talking about JSF thread posting etiquette.

  22. Sheesh...[ Go to top ]

    The only reason I chimed in is because Douglas did not have an argument. The main article was not about pain points in JSF, so why post something about Wicket?

    The original article starts with the line: "I’d like to start by saying that using JSF by itself can sometimes feel trying to pull your own teeth out with a pair of tweezers, but there’s hope."  Sounds like a pain point to me.  But I don't feel we have any argument here.  I don't recall anything you posted being directed at anyone or being especially accusatory.

    Maybe it's just what I have been taught from a young age, but it bothers me when people attack others for stating an unwelcome opinion.  Yes, it's possible to be disruptive but I don't see that as the case here.  Wicket has basically the same use as JSF, it's Java, runs on a servlet container.  It's not like bringing up .NET or something.

    Personally, while I don't know JSF, I wonder why a tool created to make JSP better needs something else to make it better.  If there were no other solutions, I would just accept it.  But knowing Wicket, it's hard for me not to think about how nice it is when I read things about 'pulling teeth'.  My guess is Douglas had the same kind of thoughts.

    I don't want to belabour this but we're all friends here, right?  I'd like to think so.  We can disagree about these things and still be friends.

  23. Sheesh...[ Go to top ]

    The original article starts with the line: "I’d like to start by saying that using JSF by itself can sometimes feel trying to pull your own teeth out with a pair of tweezers, but there’s hope."  Sounds like a pain point to me.  But I don't feel we have any argument here.  I don't recall anything you posted being directed at anyone or being especially accusatoryPersonally, while I don't know JSF, I wonder why a tool created to make JSP better needs something else to make it better.  If there were no other solutions, I would just accept it.  But knowing Wicket, it's hard for me not to think about how nice it is when I read things about 'pulling teeth'.  My guess is Douglas had the same kind of thoughts.

    The thing is that just saying "Wicket is better", doesn't contribute a lot. It would have been interesting if an example was given how easy and powerful cross-field form validation is in Wicket. Give a code example of how such a thing is done in Wicket and compare that with the JSF recipe this whole article was about in the first place.

    After that, there would maybe have been some room for saying that Wicket is overall better and then point to an article specifically about that (and if there isn't any one, start your own and we will continue the discussion there).

    This is where things could start to get interesting. This whole Wicket is better, Wicket is easier, even if it's not explicitly said that JSF sucks or is bad, just doesn't have any substance. There was a blog a while back about exactly this debate: http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/ It's an interesting read. Wicket guys claim JSF is bad. JSF guys ask 'what is exactly bad', Wicket guys beat around the bush a little, JSF guys ask to be more detailed, Wicket guys say something can not be done in JSF, JSF guys explain how it can be done, and so on and so forth.

    As it appears, a lot of this "JSF is bad" stuff is often fairly outdated. I.e. "JSF is bad because it has life-cycle conflicts". Uhm, hello 2010, hello Facelets? And "JSF is bad because it only supports POST", uhm view parameters in JSF 2.0 and even simple param bindings in the bean declaration in JSF 1.2 will give you GET support. "JSF is bad because custom components are incredibly complex", uhm JSF 2.0/Facelets composite components? Or using Java, it's 1 simple class that extends UIComponentBase with a simple annotation and there's your Java based custom component. Etc etc.

    But even though they are outdated, the above at least are concrete claims. Again, just saying that Wicket is better is pretty useless comment.

  24. Sheesh...[ Go to top ]

    But even though they are outdated, the above at least are concrete claims. Again, just saying that Wicket is better is pretty useless comment.

    I don't have any disagreement with what you have said here and I appreciate that you are making a real effort to be fair.  It's just very easy to get overly heated about these things.  Believe me, I know.  I have been a repeat offender.  I just want to be clear that I don't think I'm superior to anyone or anything like that.

    So along those lines, I think Douglas looked at the comment about pulling teeth and thought something like "that doesn't sound good.  I'll suggest Wicket."  I don't get a feeling that there were any bad intentions.

    Again I don't know JSF.  I'm really happy with Wicket and I tend to be a pretty harsh critic of tools.  So, I don't have a lot of impetus to look at JSF right now especially given that I don't really do web stuff for work.  Anyway, I'd like debating (even arguing) but I don't like it when it gets angry or nasty and personal.  Perhaps it's just my personal penance but I feel like trying to move these forums in a more friendly debate direction.

    Have a good one.  I look forward to reading your posts.

  25. I had similar thoughts a few years back:

    http://weblogs.java.net/blog/2004/07/06/improve-jsf-decoupling-form-rules-presentation-components?