Discussions

News: Article: Introducing Apache Wicket

  1. Article: Introducing Apache Wicket (89 messages)

    When you're learning a new technology or framework, it's helpful to gain an understanding of the terms and concepts, then move on to how the pieces come together. "Introducing Apache Wicket," by Nick Heudecker, approaches Apache Wicket by presenting the core concepts behind the framework, and moves to reinforce those concepts with an example leveraging some of Wicket's strengths. For those interested in learning more about Wicket, Nick will be presenting a talk on the subject at TSSJS this March. Session details to follow shortly.

    Threaded Messages (89)

  2. Nice article, but when will the Wicket in Action book be available?
  3. We finished writing and are now in the final stage of the bookwriting process. All the chapters should be available through MEAP (Manning Early Access Program) soon, and the print version is scheduled for June.
  4. Awesome job! It gets the point across! Just hope first/last names don't have have as narrow a limit as you imposed in a real-life situation (as i critiqued earlier.)
  5. Here is an example of a success story using Wicket http://javathoughts.capesugarbird.com/2008/01/year-of-wicket.html
  6. Here is a tech brief of Nick speaking about Wicket and how he believes it to be better for development than other web frameworks: http://www.theserverside.com/news/thread.tss?thread_id=45507 Cheers, Eugene Non-stop action. A vulnerable hero. A quest to save the world. It's the most exciting novel of the decade and Amazon best-seller Dec. 2007: The Tesla Testament ISBN: 1-4116-7317-4 - BISAC: FIC031000
  7. Here is a tech brief of Nick speaking about Wicket and how he believes it to be better for development than other web frameworks:
    Am I wrong (I can't understand spoken english very well) or he starts the Wicket-JSF comparison claiming the the problem of JSF is also the obsolete JSP technology? If so, he probably doesn't know almost anything of the current JSF status, and he can't do any comparison.
  8. Here is a tech brief of Nick speaking about Wicket and how he believes it to be better for development than other web frameworks:


    Am I wrong (I can't understand spoken english very well) or he starts the Wicket-JSF comparison claiming the the problem of JSF is also the obsolete JSP technology?

    If so, he probably doesn't know almost anything of the current JSF status, and he can't do any comparison.
    Without going into details, I seriously think we as a community should ditch JSF ASAP. I remember having heated discussions with some of the JSF proponents on this forum 2-3 years ago; and looks like they still don't get it. As I said then and now saying it again, they should have learn a lot from ASP.NET when it comes to GUI building. What webforms achieved almost 6-7 years ago Java is still struggling; but I am glad Tapestry and Wicket folks got it right this time.
  9. Without going into details, I seriously think we as a community should ditch JSF ASAP. I remember having heated discussions with some of the JSF proponents on this forum 2-3 years ago; and looks like they still don't get it. As I said then and now saying it again, they should have learn a lot from ASP.NET when it comes to GUI building. What webforms achieved almost 6-7 years ago Java is still struggling; but I am glad Tapestry and Wicket folks got it right this time.
    I seriously think you should support better you assertions. If you don't go into details we could think you speak without knowing. Since 2-3 years ago, JSF is rellay improved, and thanks to its pluggability we are seeing a lot of framework built upon it. Do you see any framework better then Seam out there? It is built over JSF. Do you see better component libraries then RichFaces, IceFaces, Trinidad, Tobago, Woodtock...(and I could go on)? It has a full AJAX support, templating support. What is missing from JSF? Please, tell me.
  10. Do you see better component libraries then RichFaces, IceFaces, Trinidad, Tobago, Woodtock...(and I could go on)
    Take a look at gwt-ext or mygwt, it may be interesting.
  11. Re: Article: Introducing Apache Wicket[ Go to top ]

    they should have learn a lot from ASP.NET when it comes to GUI building.
    Yup. Some good lessons. And a bunch of bad ones. ;)
  12. Am I wrong (I can't understand spoken english very well) or he starts the Wicket-JSF comparison claiming the the problem of JSF is also the obsolete JSP technology?

    If so, he probably doesn't know almost anything of the current JSF status, and he can't do any comparison.
    Sure you can use Facelets and such with JSF. But because JSP was a requirement in the JSF design, it complicated the overall architecture. If JSF had started out fresh without all the baggage from JSP and Struts, you would probably have something very similar to Wicket.
  13. Am I wrong (I can't understand spoken english very well) or he starts the Wicket-JSF comparison claiming the the problem of JSF is also the obsolete JSP technology?

    If so, he probably doesn't know almost anything of the current JSF status, and he can't do any comparison.


    Sure you can use Facelets and such with JSF. But because JSP was a requirement in the JSF design, it complicated the overall architecture. If JSF had started out fresh without all the baggage from JSP and Struts, you would probably have something very similar to Wicket.
    I don't think because JSP involves only a component inside the JSF architecture: the view handler. JSP didn't overcompilicated anything...you could instead say that the view handler for JSP is complicated..I don't know. But what does this concern with the framework? Can you tell us where it is overcomplicated because of JSP?
  14. MEAP[ Go to top ]

    I bought the MEAP (Wicket in Action) and am very satisfied already.
  15. Re: MEAP[ Go to top ]

    That's great to hear. We're amateur writers but we've worked hard on it for the last two years. We hope it will help readers take full advantage of the framework.
  16. MEAP- good[ Go to top ]

    Went through first four chapters of wicket in action and found it good. Two thumbs up!! May be it will do to web framework what hibernate did in ORM market and Spring to aplication server microcontainer. Just simple POJOs. cool.. Architecture is not complicated like tapestry. Although some extra java code, design looks clean. I need to read Kent Tong's book as well(which I liked the free chapters). Howard Lewis Ship should be supporting wicket than JSF. JSP is awful!!
  17. Can some one shed some light how wicket is different than apache Tapestry? Or some advantages of using it over Tapestry? Thanks, RJ
  18. Can some one shed some light how wicket is different than apache Tapestry? Or some advantages of using it over Tapestry?

    Thanks,
    RJ
    - Exellent built-in support for Ajax; - ability to alter page structure programmatically; - it is impossible to have code in templates;
  19. Can some one shed some light how wicket is different than apache Tapestry? Or some advantages of using it over Tapestry?

    Thanks,
    RJ

    - Exellent built-in support for Ajax;
    - ability to alter page structure programmatically;
    - it is impossible to have code in templates;
    Not to discourage any one here, but can't we take Tapestry and add these features on top of it. Why we have to invent a new frame work every month, or should I say every week. Some times I really wonder, now a days do Java developers really code some real application or their main job is just to learn Yet Another Framework (YAF):-)
  20. Can some one shed some light how wicket is different than apache Tapestry? Or some advantages of using it over Tapestry?

    Thanks,
    RJ

    - Exellent built-in support for Ajax;
    - ability to alter page structure programmatically;
    - it is impossible to have code in templates;


    Not to discourage any one here, but can't we take Tapestry and add these features on top of it. Why we have to invent a new frame work every month, or should I say every week.

    Some times I really wonder, now a days do Java developers really code some real application or their main job is just to learn Yet Another Framework (YAF):-)
    Actually I find it amusing you use the word "discourage" here. Personally, I think those are some of the reasons wicket creators felt "encouraged" to go and invent YAF. But then am just a wicket user. Either way, if you wonder why - Exellent built-in support for Ajax; - ability to alter page structure programmatically; and - it is impossible to have code in templates are such a big deal, you should read this article and then may be find something similar for tapestry and feel the difference in the programming model for yourself.
  21. Actually, Tapestry has had some form of AJAX support for longer than I've known Wicket existed. It's gotten fairly robust over the years. http://tapestry.apache.org/tapestry4.1/
    ..are such a big deal, you should read this article and then may be find something similar for tapestry and feel the difference in the programming model for yourself.
  22. Actually, Tapestry has had some form of AJAX support for longer than I've known Wicket existed. It's gotten fairly robust over the years.
    But would also like to mention that the lastest release of Tapestry, Tapestry 5 ( an entirely different Tapestry) hasn't yet got full Ajax support, right or wrong, Mr Kuhnert? Wicket's last release is 1.3 but has full Ajax support. Jan
  23. Actually no, you are wrong on both counts. Tapestry 5 does have some AJAX support - but you have to use it or read about it to learn that. Tapestry 4 is being developed concurrently with Tapestry 5 - a new release should be coming out next week. You may sometimes find that software is maintained in concurrent versions of development. This seems normal to me for a mature code base.
    Actually, Tapestry has had some form of AJAX support for longer than I've known Wicket existed. It's gotten fairly robust over the years.


    But would also like to mention that the lastest release of Tapestry, Tapestry 5 ( an entirely different Tapestry) hasn't yet got full Ajax support, right or wrong, Mr Kuhnert? Wicket's last release is 1.3 but has full Ajax support.

    Jan
  24. Actually no, you are wrong on both counts. Tapestry 5 does have some AJAX support - but you have to use it or read about it to learn that.
    I know Tapestry 5 has some ajax support and I did mention that. Wicket 1.3 has full in-built ajax support.
    Tapestry 4 is being developed concurrently with Tapestry 5

    You may sometimes find that software is maintained in concurrent versions of development. This seems normal to me for a mature code base.
    Actually, it was the only option left for you to do since both versions are radically different and thus the current not a bit backward compatible with the former. Jan Disclaimer: I am not a Wicket user and not related to Wicket in any way but a frustrated Tapestry user.
  25. Another main difference among the two frameworks is the documentation: Tapestry 5 is not documented! And does not exist any book on it! So, you have to use the old version 4. I'm using Tapestry 4, and I would like discourage every one to use it. I'm interesting in Apache Wicket, yes, it is YAF (another MVC for java!), but it is very simple to understand and to use, it is well documented and there are some good books on it. IMHO I prefer WingS over Wicket & al. but this is another story... Anyway, Wicket is good (with some strange architectural choice). Bye!
  26. Another main difference among the two frameworks is the documentation:
    Tapestry 5 is not documented!

    And does not exist any book on it! So, you have to use the old version 4.
    Are you being funny or just not informed? The first book on Tapestry 5, Tapestry 5: Building Web Applications, is available for several months already.
    Enjoy it, /lubor
  27. Can some one shed some light how wicket is different than apache Tapestry? Or some advantages of using it over Tapestry?

    Thanks,
    RJ

    - Exellent built-in support for Ajax;
    - ability to alter page structure programmatically;
    - it is impossible to have code in templates;


    Not to discourage any one here, but can't we take Tapestry and add these features on top of it. Why we have to invent a new frame work every month, or should I say every week.

    Some times I really wonder, now a days do Java developers really code some real application or their main job is just to learn Yet Another Framework (YAF):-)
    Tapestry and Wicket have very different, incompatible foundations. Tapestry provides a declarative programming model, whereas Wicket provides an imperative programming model. There are pros and cons to both. For instance, an advantage of declarative programming models is that execution can more easily be optimized - theoretically at least - and users can often get away with writing fewer lines of code. An imperative programming model typically allows for more flexibility. You can easily fill a book on such pros and cons (certainly when applied to languages), but the main reason for Wicket's existence is that no framework that supports regular Java coding existed when it was started. And to illustrate that, I spent almost a year looking for a - in our minds - suitable alternative for the model 2 frameworks we were using before we found Wicket; Tapestry and JSF had been amongst the alternatives we looked at.
  28. Some times I really wonder, now a days do Java developers really code some real application or their main job is just to learn Yet Another Framework (YAF):-)
    Yes, the world is full of choices. All those cars. And news papers. And televisions. And houses. It just never ends. You could consider moving to North Korea though; you might find the lack of choice refreshing ;-)
  29. Well, I don't want to get into a framework vs framework discussion here; there's plenty to find already if you Google around. Wicket's number one goal is to provide a programming model that scales. This really sets Wicket apart from most other frameworks, which typically focus on short term gains (deliver results fast, even though that means you'll end up with code that is hard to maintain). I explain Wicket's goals and how I got on board in the first chapter of Wicket In Action, which you can download for free at http://www.manning.com/dashorst/
  30. Re: Article: Introducing Apache Wicket[ Go to top ]

    Can some one shed some light how wicket is different than apache Tapestry? Or some advantages of using it over Tapestry?

    Thanks,
    RJ
    With Tapestry, I find myself doing configuration half the time.
    If you love java programming and hate fighting with configuration, you should go with Wicket.
  31. Echo3[ Go to top ]

    If you love java programming and hate fighting with configuration, you should go with Wicket.
    If you really love java programming, you should consider Nextapp Echo3 framework.
  32. We are currently using Wicket on my current project, and I have to say I love it for a number of reasons, but primarily two: - All you code is Java code. You can actually use object orientation properly in anyway you normally would. A far cry from many other frameworks. - With a little thought, developers can be pretty much entirely insulated from html and javascript. As for the latter, in my project we have a bunch of abstract classes for the look-and-feel of most of the application as pages are mostly similar in terms of look and functionality. This has mean that in 4 months of development, most of our developers have never touched anything but pure Java code, all things html and look-and-feel related are entirely encapsulated. On a personal level, with a background in integration and very little web experience in recent years, this is great, because it actually brings back the joy of web development for me (something I never felt with Struts, and made me avoid web development at all cost for a number of years).
  33. something I never felt with Struts, and made me avoid web development at all cost for a number of years)
    Thinking of Struts makes me think of a Lewis Black quote. Something about spoons and pain.
  34. +1 I totally agree with you. Wicket promotes Object Orientation, programmers write only in java forget configuration files, it gives freedom to designers... nothing could be better i was studying Ruby on Rails before learning Wicket, but once i got the idea behind it i've dropped Ror, Gwt or any other framework... Wicket is really something, very elegant and nice to work with This is one of my project that i've built using wicket http://openjobs.com.br
  35. Nick, Thanks for a nice, compact article that will give more people who would like to form an opinion about Wicket the opportunity to get a hands-on feel for the latest release quickly and easily. Development teams with good java/OO developers we have introduced Wicket too, that managed to put aside a little time to have a play, have come back with very positive feedback and are either already using it now or are waiting for a new project to come along that they can build on Wicket. People who enjoy good java/OO development seem to really get it and enjoy it. We've also found that your blog entry at http://www.systemmobile.com/?p=259 , and the other Wicket material you've posted there is also very clear and helpful for people getting started. Regards - Cemal http://jWeekend.co.uk PS The London Wicket Users Group event is at Google, on the evening of Feb 6. We still have a few places. Register at http://jweekend.com/dev/LWUGReg if you would like to come along and learn more about Wicket from people who have been developing and/or using it in production commercial applications and academia.
  36. Cool framework[ Go to top ]

    It's the only Java (there is also Seaside in Smalltalk) framework, that: - TRUE object oriented. - Work with url/bookmark. - Full support for AJAX.
  37. Re: Cool framework[ Go to top ]

    It's the only Java (there is also Seaside in Smalltalk) framework, that:
    - TRUE object oriented.
    - Work with url/bookmark.
    - Full support for AJAX.
    Apart from GWT, maybe? Which is based on a very different approach, though (and could even be complementary to Wicket).
  38. Re: Cool framework[ Go to top ]

    Absolutely. I highly look forward to GWT integration someday. While I would not switch from Wicket for HTML over HTTP, there could easily be reasons to use GWT on highly interactive client-side pages.
  39. No[ Go to top ]

    Sure you can use Facelets and such with JSF. But because JSP was a requirement in the JSF design, it complicated the overall architecture. If JSF had started out fresh without all the baggage from JSP and Struts, you would probably have something very similar to Wicket.
    No! That's not right! What they called "Component" in JSF/Facelets is not really component. It's a mess of Java/XML and bunch of parameters between.
  40. [...] because JSP was a requirement in the JSF design, it complicated the overall architecture. If JSF had started out fresh without all the baggage from JSP and Struts, you would probably have something very similar to Wicket.
    That's exactly what I said on my blog. I truly believe that if JSF had been designed from scratch, forgeting everything about Struts and its architecture, it would be a great standard, but now we have to wait for JSF 2.0 or even worst, JSF 5.0! That's why (great) products like Seam must exists.
  41. I truly believe that if JSF had been designed from scratch, forgeting everything about Struts and its architecture, it would be a great standard, but now we have to wait for JSF 2.0 or even worst, JSF 5.0! That's why (great) products like Seam must exists.
    I never understood this JSF-Struts similarity. A part of existence of an xml file, can you outline some other common points? Seam is not born only to fill every JSF weakness. It is primarily thought to optimally integrate the web layer (JSF) with the business and persitent layer (EJB).
  42. Try creating a new component from scratch in JSF and in Wicket, and then try extending it by using plain OO (and no config file!), and you'll see how different wicket is from JSF. ;)
  43. Try creating a new component from scratch in JSF and in Wicket, and then try extending it by using plain OO (and no config file!), and you'll see how different wicket is from JSF. ;)
    With Facelets I can create components by composition, on the fly. For more complex components I have to write a component class + a simple entry in xml file. Anyway JSF2.0 will support annotations for this, and furthermore exists already a solution for annotations here
  44. The bottom line with JSF is that it's a framework that requires a whole slew of other frameworks to make it suck less (note that it still sucks...just less). Any framework that requires teams of people just to make it palettable is the sign you have something very wrong with your framework. Plus, I spend more time configuring XML in JSF than I actually do coding for Wicket (which requires ZERO XML configuration). Finally, it's a damn good thing that JSF has all those component libraries because it's a nightmare if you have to create your own (and, yes, I've actually done that). Oops, one more thing...JSF isn't OO at all. The framework is so bad that I'd rather do Struts.
  45. The bottom line with JSF is that it's a framework that requires a whole slew of other frameworks to make it suck less (note that it still sucks...just less). Seam only sucks less? JSF is a technology, not a product. He wants to be extended by other framework, and doens't pretend to be complete as it is. The results of this are framework like Seam: the most powerfull framework ever done.
    Plus, I spend more time configuring XML in JSF than I actually do coding for Wicket (which requires ZERO XML configuration).
    So, if a wicket project takes 1 month, the equivalent in JSF takes 1 month and half only for faces-config.xml? LOL. Again use Seam (no xml required), or Shale and you won't edit much XML.
    Finally, it's a damn good thing that JSF has all those component libraries because it's a nightmare if you have to create your own (and, yes, I've actually done that).
    I don't say that component creation is easy. But if there are many component libraries out there, it is mainly thanks to JSF extensibility. Another point: it is mainly a nightmare because you have to write also the TLD for JSP, a task that you don't have to to if you use Facelets.
    Oops, one more thing...JSF isn't OO at all. The framework is so bad that I'd rather do Struts.
    It applies a lot of OOP pattern. Look here
  46. Again use Seam (no xml required), or Shale and you won't edit much XML.
    IIRC you still need to define navigation.xml when using Seam/Facelets. The whole concept of navigation configuration is ghetto... an artifact of JSP/Servlet Model2 thinking that has bled its way into Struts, Webwork/Struts2, Spring MVC, and now JSF. After 10+ years of Servlet/JSP, what these frameworks are doing behind the scenes is essentially the same: a controller servlet shoves some beans into the HttpServletRequest or HttpSession and forwards the request to a view servlet for rendering. So much easier to do this in Wicket: if (!loggedIn) setResponsePage(LoginPage.class)
  47. So much easier to do this in Wicket:

    if (!loggedIn) setResponsePage(LoginPage.class)
    Even better use: /** * Redirects browser to an intermediate page such as a sign-in page. The * current request's url is saved for future use by method * continueToOriginalDestination(); Only use this method when you plan to * continue to the current url at some later time; otherwise just use * setResponsePage or - when you are in a constructor or checkAccessMethod, * call redirectTo. * * @param page * The sign in page * * @see Component#continueToOriginalDestination() */ public final void redirectToInterceptPage(final Page page)
  48. So much easier to do this in Wicket:

    if (!loggedIn) setResponsePage(LoginPage.class)
    Bah, JSF leaves the choice (one bean per page or multiple page for one bean, or many bean for one page). If you really need this you could proceed so: return loginBean.getPage(); what is the problem? class LoginBean implements Page { public String getPage() { return "/page.xhtml"; } } Will this method kill the project?

  49. So much easier to do this in Wicket:

    if (!loggedIn) setResponsePage(LoginPage.class)



    Bah, JSF leaves the choice (one bean per page or multiple page for one bean, or many bean for one page). If you really need this you could proceed so:


    return loginBean.getPage();


    what is the problem?


    class LoginBean implements Page {
    public String getPage() {
    return "/page.xhtml";
    }
    }


    Will this method kill the project? No- nothing kills - jsps didn't kill us and neither did struts-1 - we are all alive :) Even this - won't *kill* you when compared to this - add(new PersonDetailsPanel(new Person(), new Company()); and then I refactor the PersonDetailsPanel to this - class PersonDetailsPanel{ PersonDetailsPanel(Person person) } when I do something like that in a java project (not a webapp), a basic IDE complains rightaway about some compile time issues. Wicket developers took upon themselves to bring that to web development as well (in addition to other java benefits - OO et all). Actually at the end of the day, one framework prefers doing quite a few things using string-s while the other prefers java with all the static typing , refactoring support and the like. But at the end of the day neither kills - just that wicket-users probably feel that wicket has made their life a little better. I think that is probably the reason why anyone who has tried wicket has something like this to say for sure - "If you love java, you will definitely love wicket" and you can't blame them for that. I think you should read the *free* first chapter available for download here - http://manning.com/dashorst/ IMHO , I think all those that haven't looked at wicket should read that first chapter. It will hardly take 30 minutes to finish the chapter. Of course you have a right to disagree. It's a worthwhile read and its free!. and no I'm not affiliated to Manning and the authors aren't paying me for this plug :) thanks!
  50. No- nothing kills - jsps didn't kill us and neither did struts-1 - we are all alive :)
    You didn't get the point. I can refactor the method in a base class (I see that every Page class in wicket has already a super class), and return the page name based on the class name. This is not difficult. return "/page.xhtml" doens't require any xml, like in wicket. This is possible because you can extend the navigation handler very easily. This is why JSF extensibility is so important.

    Even this -






    won't *kill*
    uhm is this a facelets example? This is not the way in facelets...

  51. No- nothing kills - jsps didn't kill us and neither did struts-1 - we are all alive :)



    You didn't get the point.
    I can refactor the method in a base class (I see that every Page class in wicket has already a super class), and return the page name based on the class name. This is not difficult.

    return "/page.xhtml"

    doens't require any xml, like in wicket. This is possible because you can extend the navigation handler very easily.
    This is why JSF extensibility is so important.



    Even this -






    won't *kill*


    uhm is this a facelets example? This is not the way in facelets...
    Ok then tell us the right way. How do you pass parameter to a component in Facelets then? You saw the wicket code that i showed there .What w'd the equivalent thing in facelets look like?. Wicket allows you to build components through composition. I guess facelets allows you to do that as well. In the Wicket case the panel requires Person and Company pojo as its model (actually I don't have to say that - it is kind of explicit through the constructor) How does the client of a similar-looking facelets component know that the component requires a Person and Company pojo as the backing model? and of course my first question - how do you pass the parameter to the facelets component.
  52. "JSF is a technology, not a product. He wants to be extended by other framework, and doens't pretend to be complete as it is. The results of this are framework like Seam: the most powerfull framework ever done." 1) JSF is a spec with two implementations that I know of: Sun's and Apache's. The spec was designed with the intention that JSF be used to build drag & drop style web page builder IDEs. In spite of that intention, the vast majority of JSF projects are coded by hand. 2) You declare Seam the most power framework ever done. That's quite a boast. Prove it. IMHO, the shear fact it's based on JSF (which is crap technology) invalidates your statement. "So, if a wicket project takes 1 month, the equivalent in JSF takes 1 month and half only for faces-config.xml? LOL." 3) What makes you think that doing the same project in Wicket and JSF would take the same amount of time? I'd be done coding my Wicket project before you finished coding all your XML configuration and please don't mention Seam . Seam does not implement the JSF spec. 4) Building components is so easy in Wicket that every wicket project in existence does this pretty extensively. There's simply no pain involved. I've worked with both technologies on "real" projects that businesses have paid a lot of money to build and I can say unequivocally that Wicket is by far the superior product. I can't think of a single instance where I would choose JSF over Wicket. Believe me, when JSF came out I really wanted to like it because I was so tired of Struts but JSF ended up being a bigger burden than Struts ever was.
  53. With Facelets I can create components by composition, on the fly. For more complex components I have to write a component class + a simple entry in xml file.
    "a component class", quick to say, three words, but "hell is in the details"...
  54. I never understood this JSF-Struts similarity. A part of existence of an xml file, can you outline some other common points?
    From an architect's perspective, yes they are different. But the developer is who actually does the job. From a developer's perspective, Struts and JSF are the same. It's not just the xml file, it's the TagLibraries, JSP, JSF (xml pages), the managed bean and all that SOP (String Oriented Programming) to control the web application flow. return "success"; Really, is this what we want? :)
  55. It's not just the xml file, it's the TagLibraries, JSP, JSF (xml pages), the managed bean and all that SOP (String Oriented Programming) to control the web application flow.

    return "success";

    Really, is this what we want? :)
    -TagLibraries are related to JSP. -JSP, today, aren't really related to JSF, de facto: 99% of JSF developers use Facelets. -managed bean? They are normal bean after all. If you use Seam or Orchestra these beans can coincide with the service layer. This is a proof of the fact that JSF and managed beans are not 2 strong related concepts. You can avoid them, or not in case you like to leave to JSF their configuration and instantiation. -"return success": believe me, this is not a big problem :). You can always plug the navigation handler and use enumeration instead.
  56. -"return success": believe me, this is not a big problem :). You can always plug the navigation handler and use enumeration instead.
    Actually it is. For starters, it forces you into a page oriented approach, so you're out of luck if you want to create self contained components (which may after all have their own 'navigation').
  57. Thank you for a great framework[ Go to top ]

    As a casual user of Java I find Wicket the friendliest framework available. I don't have the time nor the ability to cram so much info in my head that other frameworks require. With Wicket, I was able to both learn the basics and build up a usable shopping cart in about 10 days, 2-3 hours a day. I am pleased with Wicket. What IDEA is for IDEs, Wicket is for web frameworks. Congratulations. Florin Gheorghies Atlanta, GA
  58. -"return success": believe me, this is not a big problem :). You can always plug the navigation handler and use enumeration instead.


    Actually it is. For starters, it forces you into a page oriented approach, so you're out of luck if you want to create self contained components (which may after all have their own 'navigation').
    I didn't understand. JSF doesn't force to a page oriented approach: a page con be managed by a single bean or my multiple beans, or a bean can serve many pages. Navigation isn't always page oriented: return ""; or return null; force JSF to stay on the current page.


  59. I didn't understand.
    JSF doesn't force to a page oriented approach: a page con be managed by a single bean or my multiple beans, or a bean can serve many pages.
    Navigation isn't always page oriented:

    return ""; or return null;

    force JSF to stay on the current page.
    Actually, the page and request-response type underlying protocol bleeds right through JSF - JSF does very little to encapsulate it's internal workings or the http protocol. The fact that you scope managed beans by "request", "session" etc says everything about how JSF just bleeds through abstractions and fails to add muhc value at all.
  60. The fact that you scope managed beans by "request", "session" etc says everything about how JSF just bleeds through abstractions and fails to add muhc value at all.
    The managed bean feature is quite low level and simple. I have already said that they are not a key point in JSF, and this means that other frameworks are responsible for a better management. Seam, for example, introduces further scope: view scope, conversation scope. These are perfect suited for web application and multi window application too. The same thing does Orchestra and Shale, both JSF extensions.
  61. Alberto, I have not used JSF yet, but I have to admit you are not defending it very well. The more I read of your posts the more I'm not looking forward to my first JSF project. The main thing I disagree with you on (without even having used JSF yet) is that: - Good technologies, or frameworks, don't require other technologies or frameworks to make them usable. Your defense of JSF seems to be to use Seam. I have heard a lot of great things about Seam, but that is not a compliment to JSF. - I also see the whole "return success" aspect of JSF to be limiting. - There are JSF alternatives to JSP, but the spec requires that JSP are supported, and hence most people are using JSP's for JSF development. I personally find JSP's to be a dark spot on JEE spec. I agree with other posters, that since JSF was required to support JSP that the potential of the spec was limited.
    I have already said that they are not a key point in JSF, and this means that other frameworks are responsible for a better management.
    Doesn't leave me very encouraged. I must also say that I'm not a wicket user, so I can't comment on wicket.
  62. I have heard a lot of great things about Seam, but that is not a compliment to JSF.
    If JSF was created to be a very complete framework as it is you could be right. But the truth is that it is mainly designed to be an extensible technolohgy, alowing many framework to be built upon JSF. This is the big misunderstanding about JSF, IMHO. You can't evaluate JSF without considering its echosystem, because a great echosystem is in its scope. Thus, saying that Seam is a great product over JSF doens't mean that JSF sucks because it need Seam to be very productive. It means instead that JSF permitted such extensions. And JSF reaches its scope.
    I also see the whole "return success" aspect of JSF to be limiting.
    I need more informations and examples about this. Really (not sarcastic). Let's see if the problem can be solved.
    There are JSF alternatives to JSP, but the spec requires that JSP are supported, and hence most people are using JSP's for JSF development.
    This is not true. Most people are using Facelets. Some other are using JSFTemplating, and some other are using Clay (from Shale). Only a beginner probably uses JSP.
    I personally find JSP's to be a dark spot on JEE spec. I agree with other posters, that since JSF was required to support JSP that the potential of the spec was limited.
    JSP are relegated into the view handler. If you replace it with a new one, as Facelets does, you have really no limits. And Facelets gives a proof of this. JSFTemplating another proof. Clay another, again.
  63. If JSF was created to be a very complete framework as it is you could be right. But the truth is that it is mainly designed to be an extensible technolohgy, alowing many framework to be built upon JSF
    Says who? JSF was intended to be a complete framework from the very first pass for all that I know. Reading the official documentation doesn't give me an other impression either. Of course it should be extendible, just like all the other frameworks are.
    This is the big misunderstanding about JSF, IMHO.

    You can't evaluate JSF without considering its echosystem, because a great echosystem is in its scope. Thus, saying that Seam is a great product over JSF doens't mean that JSF sucks because it need Seam to be very productive.
    What you see with all the extensions is that people thought, well, we'll have to live with this proposed standard... let's build something around it to make it workable. If JSF was a great framework by itself, people wouldn't find the need to so much, and these frameworks would be simple focussed additions that didn't change the programming model.
    I also see the whole "return success" aspect of JSF to be limiting.


    I need more informations and examples about this. Really (not sarcastic).
    Let's see if the problem can be solved.
    Did you read the link I posted earlier?
    Only a beginner probably uses JSP.
    I personally find JSP's to be a dark spot on JEE spec. I agree with other posters, that since JSF was required to support JSP that the potential of the spec was limited.


    JSP are relegated into the view handler. If you replace it with a new one, as Facelets does, you have really no limits.
    And Facelets gives a proof of this. JSFTemplating another proof. Clay another, again.
    These frameworks differ so much from each other that you might as well list them as separate frameworks. As it turned out, JSF achieved the opposite of what standards typically try to achieve: standardization. Built on some same foundations yeah, but components aren't even compatible often (at least, that's what I've been reading). I'm completely willing to believe that development with some of these frameworks is fine, but if you look at JSF's overall landscape... it's a mess.
  64. The fact that you scope managed beans by "request", "session" etc says everything about how JSF just bleeds through abstractions and fails to add muhc value at all.


    The managed bean feature is quite low level and simple. I have already said that they are not a key point in JSF, and this means that other frameworks are responsible for a better management.

    Seam, for example, introduces further scope: view scope, conversation scope.
    These are perfect suited for web application and multi window application too.

    The same thing does Orchestra and Shale, both JSF extensions.
    And in Wicket, the 'scope' of an object is it's reachability, just like 'regular' OO. Wicket doesn't need explicit scopes. If you want to create a conversation, you just pass in the state (i.e. the objects) from one page or component to the other. Page scope equals having a member on your page. Session scope a member on your session object. Etc.
  65. The managed bean feature is quite low level and simple. I have already said that they are not a key point in JSF, and this means that other frameworks are responsible for a better management.

    Seam, for example, introduces further scope: view scope, conversation scope.
    These are perfect suited for web application and multi window application too.

    The same thing does Orchestra and Shale, both JSF extensions.
    Even with extensions, why should we have a set number of given "scopes" to begin with? It is simply a case of abstraction bleed where the framework makes it painfully obvious that there is an underlying protocol (http) which is neither stateful, nor object oriented. Bad, bad, framework design. What's wrong with actually passing objects around in your application as you see fit for your actual application? You are after all using Java.. But that just seems like too "revolutionary" an idea for JSF..
  66. -"return success": believe me, this is not a big problem :). You can always plug the navigation handler and use enumeration instead.


    Actually it is. For starters, it forces you into a page oriented approach, so you're out of luck if you want to create self contained components (which may after all have their own 'navigation').


    I didn't understand.
    JSF doesn't force to a page oriented approach: a page con be managed by a single bean or my multiple beans, or a bean can serve many pages.
    Navigation isn't always page oriented:

    return ""; or return null;

    force JSF to stay on the current page.
    The fact that you call it page says enough. See also http://chillenious.wordpress.com/2006/07/16/on-page-navigation/
  67. I don't think JSF really forces you to a return "success". As already written in another post, you can achieve this quite easily in JSF: return loginBean.getPage(); ... class LoginBean extends Page { ... } class Page { public String getPage() { //this could returns "login.xhtml" for example //following some conventions return Utility.convertClassNameToView(); } } Then add a new navigation handler,and things like return "success" are no more in your project. Note also that now you don't need any xml for navigation rules. What do you think?
  68. I don't think JSF really forces you to a return "success".

    As already written in another post, you can achieve this quite easily in JSF:


    return loginBean.getPage();

    ...

    class LoginBean extends Page {
    ...
    }

    class Page {
    public String getPage() {
    //this could returns "login.xhtml" for example
    //following some conventions
    return Utility.convertClassNameToView();
    }
    }


    Then add a new navigation handler,and things like return "success" are no more in your project.
    Note also that now you don't need any xml for navigation rules.

    What do you think?
    I wrote what I think here: http://chillenious.wordpress.com/2006/07/16/on-page-navigation/. There I argue that besides page navigation, you should want the ability to implement more fine grained 'navigation'; i.e. by using component replacement, just like you would often do with desktop UI development. Even if you're not convinced by that, there is still the fact that the indirection in JSF's navigation model isn't adding anything compared by just doing it in Java. Well, it adds the ability to draw graphs... hurray. Though if you wanted, you can build this (externalized navigation) on top of Wicket. The indirection is not a big deal for a few pages, but to have to explicitly maintain a navigation graph for hundreds of options is horrible as I remember well from using Struts back in the days. More importantly, externalized navigation is limiting. Say you have a detail page that you only want to allow to be created with an initialized Address object (just an example). With Wicket, you code a page with a page constructor that takes one as an argument, and clients can then 'navigate' to that page by doing setResponsePage(new AddressDetailPage(anAddress)); I'm pretty sure that even if JSF provides a way to achieve something similar, it won't be straightforward Java coding like this. Which is exactly the point I and some others here are trying to get across. It's not just whether something is possible with framework X, but also how natural the code is to achieve things.
  69. you can work around any quirk in any framework. Or just use a decent one
  70. I don't think JSF really forces you to a return "success".

    As already written in another post, you can achieve this quite easily in JSF:


    return loginBean.getPage();

    ...

    class LoginBean extends Page {
    ...
    }

    class Page {
    public String getPage() {
    //this could returns "login.xhtml" for example
    //following some conventions
    return Utility.convertClassNameToView();
    }
    }


    Then add a new navigation handler,and things like return "success" are no more in your project.
    Note also that now you don't need any xml for navigation rules.

    What do you think?
    Still, you are returning a String. :) That's the problem: String Orientend Programming. When I worked with Struts a few years ago, most of my problems was to look at the log files and after some minutes realize that some of my developers (and myself) did small mistakes writing some "binding" between Java-JSP-XML. Really, this programming model sucks! It's just too many binding points! I don't know exactly how Facelets does this, but because the nature of JSF and its architecture, I doubt Seam or Facelets or anything related to JSF could work different. If you look at Wicket's binding model, you would be impressed. It's just one binding: between a component and a markup. That's it. And its navigation model is 100% OO. But, we could say that JSF looks more like to Java than Wicket: it's not 100% OO because it has primitive types. :)
  71. Still, you are returning a String. :)
    That's the problem: String Orientend Programming.
    This is the last answer. Maybe you didn't get the point: you don't have to specify any String. Developer should write this code: return loginBean.getPage(); where getPage doens't return any hard coded string (it is derived from the class name), and the developer doens't need to write any XML. So can tell us where is the problem about the return type here?
    When I worked with Struts a few years ago, most of my problems was to look at the log files and after some minutes realize that some of my developers (and myself) did small mistakes writing some "binding" between Java-JSP-XML.
    There is not XML and no binding. The uitlity class convert the class name into a valid page. Convention over configuration, like in Wicket.
    If you look at Wicket's binding model, you would be impressed. It's just one binding: between a component and a markup. That's it. And its navigation model is 100% OO.

    But, we could say that JSF looks more like to Java than Wicket: it's not 100% OO because it has primitive types. :)
    I am not much impressed (but Wicket seems very nice): User user = new User(); setResponsePage(new UserDetailPage(user)); VS User user = new User(); userBean.setUser(user); return userBean.getPage();

  72. User user = new User();
    userBean.setUser(user);
    return userBean.getPage();
    The problem with this code is that it throws away one of the few good things in JSF: emphasis on the separation of domain logic (managed beans) and UI (view). In this code the bean knows about the UI. Or in practical terms, it prevents the bean from being used by two different pages.
  73. It's also "indexable"[ Go to top ]

    About GWT. Sorry, i forget to mention one more feature of Wicket. It's also "indexable" by web search engines. But GWT isn't :(.
  74. Re: It's also "indexable"[ Go to top ]

    About GWT. Sorry, i forget to mention one more feature of Wicket. It's also "indexable" by web search engines.
    But GWT isn't :(.
    That's really about Wicket, isn't it? GWT has quite a few more things to mention about =)
  75. Re: It's also "indexable"[ Go to top ]

    About GWT. Sorry, i forget to mention one more feature of Wicket. It's also "indexable" by web search engines.
    But GWT isn't :(.
    I'm sorry but Wicket is not any more the only player on the "pure HTML templating and view logic in Java" space. Jose M. Arranz ItsNat, Natural AJAX
  76. Re: It's also "indexable"[ Go to top ]

    About GWT. Sorry, i forget to mention one more feature of Wicket. It's also "indexable" by web search engines.
    But GWT isn't :(.


    I'm sorry but Wicket is not any more the only player on the "pure HTML templating and view logic in Java" space.

    Jose M. Arranz
    ItsNat, Natural AJAX
    Wicket's sweet spot is that it provides a natural OO programming model. Many things, such as clean separation of logic (Java) and presentation (XHTML/ CSS) come from that. Wicket is also not an Ajax framework. While we worked hard on making Ajax an integral part - and the feature requests and patches to make this even smoother are stacking up for the next release - you can build traditional web apps with Wicket just the same. Unlike GWT and ItsNat. I like what I've seen from GWT btw. They strive for the same goals as Wicket does, even though it resulted in a very different framework. The main difference between the two - besides GWT being Ajax only - is that GWT works with layout managers whereas Wicket works with templates. As usual, there are pros and cons to both of them :-). Same story applies to Echo 2. I haven't heard of ItsNat before, but good luck with your framework.
  77. Re: It's also "indexable"[ Go to top ]

    I haven't heard of ItsNat before, but good luck with your framework.
    ItsNat can be used to develop applications with "classic navigation" too but is true is not the focus. Thanks, I cannot desire good luck to your child, Wicket, because it's already a success :) of course isn't the focus of the "big industry" but you know how this works...
  78. Re: It's also "indexable"[ Go to top ]

    About GWT. Sorry, i forget to mention one more feature of Wicket. It's also "indexable" by web search engines.
    But GWT isn't :(.
    That could be a good thing, depending on what you are trying to do. :)
  79. Re: It's also "indexable"[ Go to top ]

    About GWT. Sorry, i forget to mention one more feature of Wicket. It's also "indexable" by web search engines.
    But GWT isn't :(.

    That could be a good thing, depending on what you are trying to do. :)
    True. That's why you explicitly make something bookmarkable/ indexable with Wicket.
  80. Re: It's also "indexable"[ Go to top ]

    About GWT. Sorry, i forget to mention one more feature of Wicket. It's also "indexable" by web search engines.
    But GWT isn't :(.

    That could be a good thing, depending on what you are trying to do. :)


    True. That's why you explicitly make something bookmarkable/ indexable with Wicket.
    Nice.
  81. Is there anobody out there having both experience into Wicket and into JSF programmed as Swing ? I know some programmers are using JSF without JSP or facelets, assembling JSF components similarly to Swing or Wicket. So, I wonder how far are Wicket and JSF with such programming model. Any experience ? Other (inner) question: might it be possible to adapt JSF components to use them as Wicket components ? Thanks for any response. Dominique http://www.jroller.com/page/dmdevito
  82. why not webobjects?[ Go to top ]

    I think webobjects are still the best java framework
  83. Wicket Rocks![ Go to top ]

    I have always been a server developer and did my darnest to avoid the view layer of the web. Why? Because Struts/JSP and like technology ran contrary to everything I learned in CS. Last year, for cost reasons (I run my company), I had to scale down on the GUI developers and started doing some of it myself in Struts. Without hesitation I went to work looking for an alternative. After several trials with combos I landed on Wicket. I will avoid repeating what others have already stated, I will add the following: - Wicket work unit focus is very localized. You can easily work with two files for a component and go back and forth between them and get something done. - Wicket errors are very shallow and you can get to the bottom of the source very quickly. - Wicket html pages look so clean and easy to glance at and understand what's in them without a baggage of assumptions. - THIS IS A REPEAT: Yes, dropping declarative navigation is a good idea. In fairness, what I have struggled with dealing with Wicket is mostly related to: - Concrete understanding of the various flavours of Wicket Models (writting code instead of just reading helps with this one). -Page Caching models Thank you Wicket Guys and Gals Medhat!
  84. Re: Wicket Rocks![ Go to top ]

    "I have always been a server developer and did my darnest to avoid the view layer of the web." This about sums up why I started the project. To this day I have never written a JSP page, used Struts or looked very far into JSF. Each of these options just seemed like a sad waste of time to me for years, so I struggled along with Freemarker and Tea until it finally became clear nobody was going to solve this problem to my satisfaction. Thus Wicket. If you mean Page pooling, it's not a good idea in Wicket. If you mean caching rendering results for expensive-to-compute panels, it's pretty straightforward and 100% reusable to write a markup caching panel with StringResponse. Declarative declaration of navigation is a bad idea in most cases because it breaks encapsulation. Same goes for putting markup in another folder or hierarchy. In OO programming, you want to avoid bleeding implementation details. It will always come back to haunt you, even if you do not have the experience to recognize it. Jon
  85. Re: Wicket Rocks![ Go to top ]

    "Declarative declaration..." oops! LOL!
  86. Re: Wicket Rocks![ Go to top ]

    To this day I have never written a JSP page, used Struts or looked very far into JSF
    So you're saying, you started with a blank slate? ;-) - p
  87. Re: Wicket Rocks![ Go to top ]

    Yes. Tabula Rasa.
  88. Thanks[ Go to top ]

    Hi, Many thanks for this great article. I'm a long time JSF user, and I was curious about Wicket for some weeks now, but I was frustrated by not finding an up-to-date article explaining how to build a CRUD-like app in Wicket, and here it is ;-) I've been looking for something similar for a long time, but I couldn't and the majority of what I found was either outdated or just a cluttered demos/presentation of components, nothing which talks about a complete app as a whole. Thanks again, and yeah, I would definitely agree that Wicket rocks. By the way, I'm longing for closures support in Java as I guess they will alleviate us from the mess of inner/anonymous classes clutter which Wicket involves. Regards,
  89. Re: Thanks[ Go to top ]

    By the way, I'm longing for closures support in Java as I guess they will alleviate us from the mess of inner/anonymous classes clutter which Wicket involves.

    Regards,
    +1 Also see what Scala can do to make your code prettier here http://technically.us/code/x/the-awesomeness-of-scala-is-implicit/. I'm not all convinced about the operator overloading (which technically isn't operator overloading because Scala doesn't have operators), but I do like stuff like:
    new Label("cur_dt", () => new Date())
    a lot!
  90. Excellent![ Go to top ]

    Excellent Article! Please write more!