Wicket Graduates from Apache Incubation

Discussions

News: Wicket Graduates from Apache Incubation

  1. Wicket Graduates from Apache Incubation (44 messages)

    It's official. Wicket has formally graduated from incubation at Apache. Congratulations to all the devs and the mentors at Apache. See the official announcements here and here. A lot of hard work went into this process and all the devs and mentors deserve a few minutes to rest and enjoy this success. But not too long. We're all waiting for 1.3.0-beta2. Not familiar with Wicket and the kinds of things that it can do for you? Check out our video Tech Brief, a quick introduction to Wicket for those who aren't familiar with it.

    Threaded Messages (44)

  2. I have never really looked at Wicket because I'm not usually worried about web apps but I am working on cleaning up a struts app at the moment and I'm not especially impressed with it. I'm seeing a lot of praise for Wicket and I looked a little bit at the approach and got some warm fuzzy feelings. Does anyone have anything negative to say about Wicket? Haters, give it your best shot.
  3. the only complaint i have is that the project's site and documentation isn't very coherent, it takes a bit of digging to find examples sometimes. the book(s) that are available or in the tube (pro wicket and wicket in action) should help a lot to get people going tho. technically it is excellent, but there is a steep curve because of the documentation. It isn't that hard to use in practice once to start to think in wicket terms.
  4. That would be my only complaint too. It doesn't lack online documentation, it's just too scattered (wiki, javadocs, forum), and sometimes I spend more time than I think I should just to find an answer to a simple problem. A user's guide, updated for each release, would help very much. Even wicket team would benefit, as they would have to spend less time answering to simple questions on the forum (which by the way is one of the best around). Congrats to wicket team!
  5. Great! Congratulations to all the Wicket team... Wicket has been one of my most exciting discoveries in the last years. At first it was really hard to understand (I come from the Struts 1.x world...) but now I *really* like it. Thanks for your extremely good work. Regards, Daniel. P.S.- When will we have that "Wicket in Action"? pleaaase... ;-)
  6. Wicket in Action[ Go to top ]

    Thanks for all the nice comments, made me blush! But it is the community as a whole that deserves the credit: as you can read in these comments the Wicket community is great, and joining Apache will help it grow and be sustainable. Becoming a part of the Apache community is something special. I have never given it much thought, until I was at the last ApacheCon in Amsterdam and met with all the Apache folks. It was great and I felt right at home. The Apache community aspect is greatly underestimated and undervalued if you come from outside, at least it was in my personal perspective. And it is not only a bonus for Wicket that we joined Apache. In my opinion it is also a great moment for the ASF: the Apache community gains an extremely active, friendly and vibrant community, and one outstanding web application development framework.
    When will we have that "Wicket in Action"? pleaaase... ;-)
    We are working on the book, and if you never have written one, you will not know how hard it is to write and finish it (if you ever contemplate writing a book, contact me). That said, we are in the final stages before we can start the Manning Early Access Program (MEAP) and will be delivering the first chapters in a matter of weeks (for a particular value of week). Keep an eye out for the book on my and Eelco's blogs (mentioned in the opening post). We both will be announcing the availability as soon as it happens.
  7. Hands on experience[ Go to top ]

    I have a young company (2 years old) with 15 clients and 20 projects. Most of them in Java, some in .Net and PHP. Since Q3 2006 Wicket is the chosen web framework for our Java applications. Its component oriented architecture really makes a difference. It has a much cheaper learning curve compared with other technologies (as it only has html + Java). I already have 2 projects in production and 4 more to go. Congratulations to all the team and many thanks to the community. I am sure that Wicket will be the standard in a few months. Juan Ignacio.
  8. I have a young company (2 years old) with 15 clients and 20 projects. Most of them in Java, some in .Net and PHP.

    Since Q3 2006 Wicket is the chosen web framework for our Java applications. Its component oriented architecture really makes a difference. It has a much cheaper learning curve compared with other technologies (as it only has html + Java).

    I already have 2 projects in production and 4 more to go.
    It's great to hear Wicket works well for many people. Join 'the community' and we'll only make it better :)
  9. Wicket book[ Go to top ]

    if u r looking for a book for wicket,try pro wicket by APress,i got a copy,it 's good,go down directly to the point,and teach you how to build a real application not just a bunch of screens said that, i'm also looking forward to read the wicket in action book,but i hope to see some best patterns of using the framework,and focus on the ajax aspects,and the spring/guice integration
  10. Here are the things I had trouble with when I started working with Wicket. 1. Wicket uses Models to hold or locate domain objects. The easiest thing to implement is a model that holds a domain object, but this potentially ends up using up more session memory than is desirable. So you have to understand how the DetachableModel looks up domain objects. This is the classic trade-off between memory & i/o and is (now that I understand it) well-implemented. None the less, it is probably the steepest part of the learning curve. 2. I can't think of anything just now. The help on the mailing list is unparalleled and the exceptions that Wicket throws are insanely useful.
  11. Cons on Wicket[ Go to top ]

    First of all Wicket Congratulation to Wicket Team! Wicket's idea of java web development is excellent, but 1 thing I dont like about it is that .html and .java will reside on same directory/folder; however if they will provide option to separate these files I would say wicket will be the next Struts in java web development.
  12. HTML and Java files[ Go to top ]

    I dont like about it is that .html and .java will reside on same directory/folder; however if they will provide option to separate these files I would say wicket will be the next Struts in java web development.
    You mean something like 'controlling where html files are loaded from'? The fact that the html and the java files are in the same package has several advantages:
    • packaging: create a jar and you can use it directly without having to install separate files
    • refactoring: having a 1-1 relationship between your Page class file and the markup file is *really* easy (you know what to find where) and allows refactoring tools (such as Wicket Bench) to pick up your resource bundles (Page_fr.properties, Page_nl.properties), html files (Page_fr.html, Page_nl.html) and your class name when you rename the class or move it to another package.
    • it is unsettling at first, but once you have worked with it for a couple of weeks, you don't want it any other way (coming from my own experience).
  13. Cons on Wicket[ Go to top ]

    First of all Congratulation to Wicket Team! Wicket's idea of java web development is excellent, but 1 thing I dont like about it is that .html and .java will reside on same directory/folder; however if they will provide option to separate these files I would say wicket will be the next Struts in java web development.
  14. Haters, give it your best shot.
    Wow, no complaints about Wicket! What other frameworks (like Spring, Hibernate ....) do we need to use with Wicket to build a web application with features like authorization, authentication, database access, transactions, ajax support ....?
  15. What other frameworks (like Spring, Hibernate ....) do we need to use with Wicket to build a web application with features like authorization, authentication, database access, transactions, ajax support ....?
    In principle none: Wicket only depends on the servlet specification (2.3), and slf4j for its logging. If you are using Spring then take a look at the Wicket Spring integration. We will also ship a Guice integration with 1.3. If you want to use Hibernate directly without Spring, take a look at databinder created and maintained by Nathan Hamblen. If you want to use some other persistence framework, nothing prevents you from directly using it (see the Wicket Phonebook example project for integration examples using Spring, iBatis, Hibernate and Shades). For authentication/authorization the same applies: integrating with any authorization technology can be as simple as implementing IAuthorizationStrategy. You could use our auth-roles project as a template for this type of development. People also have mentioned using Acegi with Wicket and more. Ajax is built in (and rated A for cross browser support): you don't have to write a single line of JavaScript to perform partial page updates and use Ajax in your application. Examples of our Ajax support are available from our Wicket Examples site. If you want to use Ajax frameworks such as Y!UI, Dojo and Scriptaculous we have supporting projects that enable them (to be found on wicketstuff.org).
  16. Only some faint criticism. Very impressive. I look forward to trying it out.
  17. Congrats![ Go to top ]

    Thanks to the most excellent Wicket team for all their hard work And especially their help (and patience) on the mailing list. Yes, don't enjoy the moment for too long - as a Wicket user for the last 6 months, I am eagerly waiting for 1.3.0 final as well :) Peter http://jtrac.info
  18. CONGRATULATIONS[ Go to top ]

    wicket is really the best web framework in existence,for all and any language not only java,it is very component and OO oriented,its model and binding is a charming implementation of good architecture and elegent design ajax support is very natural,it's not just an awfull plug wicket really go straight to the point i recommend it to anyone who have the choice of his project's framework looking forward to wicket1.3
  19. Better than Rails?[ Go to top ]

    wicket is really the best web framework in existence,for all and any language not only java
    Is this the end of Rails???
  20. Re: Better than Rails?[ Go to top ]

    wicket is really the best web framework in existence,for all and any language not only java
    Is this the end of Rails???
    Given that some wicket commiters have already shown interest in Scala language, that wouldn't be too surprising... ;)
  21. Scala is the new Java[ Go to top ]

    Why, yes we are interested in Scala
  22. Re: Scala is the new Java[ Go to top ]

    Scala is the new Java.
    After some digging, I believe it is true. Get ready for the next gold rush!
  23. Congratulations! This is great news. Wicket is a wonderful tool - truly productive and flexible tool in the bloated arena of wanna-be monsters and the success is well-deserved. Good job, guys!
  24. Congratulations~[ Go to top ]

    Great! Congratulations to all the Wicket team!
  25. Congratulations! Very nice work, Wicket team! Can't wait for the 1.3.0 release and Wicket In Action book (like everyone else) it will be sweet...
  26. Congratulations![ Go to top ]

    You are doing a great job! I dont` think the learning curve to be too challenging, especially having a Pro Wicket book. The only thing I would like to have in wicket - is more components (splitters, drag & drop...)
  27. Greetings, I've read a lot of praise to Wicket framework but unfortunately have not had a chance to look at it. So please forgive me if my question is too naive. For our new project we recently selected GWT as the main web framework for our application. Can someone who has an experience with both frameworks give a brief comparison of GWT vs Wicket?
  28. Can someone who has an experience with both frameworks give a brief comparison of GWT vs Wicket? on the programming level ,they are at the same level of abstraction,in both frameworks you describe what components you are dealing with in pure java and, in the markup you put an id ti identify where this component appear on the page,both support custom components through composite panels, wicket support markup inheritence from its parent page the rest u probably know,wicket compiled to bytecode executed on the server and GWT compiled to JS executed on the client browser you may ask,can i use wicket instead of GWT,can i get the same level of ajax?!! ok,first of all,i admit that GWT is good framework and its approach is unique second,it depends on you and your team,if you like GWT ,use it,if u know it already and have short schedule for ur project ,use what you know third,the wicket side,YES wicket can ajaxify your page at any level you need, from a single line or single ting component to several hundreds of components on the page(if you have them) just attach them to Object called AjaxTarget which passed to you when events like link click happens,then all these components will be updated,really simple and NATURAL best of all,u can use any existing ajax lib,by attaching it to your custom panel markup and go,its wicket philosophy to use your unmodefied markup,no lifecycle interference or so
  29. Compared these two frameworks just yesterday:) I have been searching for a framework to make new version of an intranet application that is part of a large CORBA-based software project. The old version is Struts-based and I`m having so much pain making UI components and filling all of those config xml-s that it makes me decided for complete rewriting. There is also a point that no one in our project knows Struts tags and has time to study it and that I have no WYSIWYG tools for it. So I compared five (in fact more) frameworks: JSF, Tapestry, Echo, GWT and Wicket. JSF is just another xml-configured-custom-tags-monster from McClanahan. Event-driven, huge support (Sun, Oracle,...), but I have had enough of Struts. Tapestry is great framework with great ideas but it would be hard to learn for developers in our project. And configuration XMLs again. Echo impressed me with the set of included components and that it would be easy for our Swing developers. But as we would not pay for Echo Studio, developing without visual designer is a challenge. GWT has a different approach to AJAX, making a heavy use of client browser and minimizing number and size of HTTP requests. I would choose it for rich internet applications (may be). But I don't need this for high bandwidth intranet. I`d rather prefer a lightweight javascript on the client side. So (for now) I chose Wicket. It impresses me with its simplicity and ability to create reusable panels without any xml-s.
  30. Can someone who has an experience with both frameworks give a brief comparison of GWT vs Wicket?
    You actually should be able to use them together without problems, and we might even look at some real integration sometime if that makes sense. I consider Wicket and GWT to be like brothers. They are different but both take simply Java programming as the starting point. Differences are plenty though, and it is probably the best to play around with both yourself to get a real good idea. The main differences that strike me: * GWT uses layout managers, Wicket HTML templates. There's something to say for both. * GWT probably scales cheaper as it keeps state on the client rather than the server. The price for that is that you won't automatically enjoy benefits of locality if you work with a complex domain model and multiple components working on that in the same page and that GWT supports only a limited subset of Java for it's client components. * Wicket is a broad solution for your whole web site, whereas GWT produces kind of applets. This is why it is great that people can use the two technologies together if they wish. * GWT has a nice GUI builder. With Wicket, you (or your designer) use standard HTML editors. Again, something to say for both.
  31. Can someone who has an experience with both frameworks give a brief comparison of GWT vs Wicket?


    You actually should be able to use them together without problems, and we might even look at some real integration sometime if that makes sense.

    I consider Wicket and GWT to be like brothers. They are different but both take simply Java programming as the starting point.

    Differences are plenty though, and it is probably the best to play around with both yourself to get a real good idea. The main differences that strike me:
    * GWT uses layout managers, Wicket HTML templates. There's something to say for both.
    * GWT probably scales cheaper as it keeps state on the client rather than the server. The price for that is that you won't automatically enjoy benefits of locality if you work with a complex domain model and multiple components working on that in the same page and that GWT supports only a limited subset of Java for it's client components.
    * Wicket is a broad solution for your whole web site, whereas GWT produces kind of applets. This is why it is great that people can use the two technologies together if they wish.
    * GWT has a nice GUI builder. With Wicket, you (or your designer) use standard HTML editors. Again, something to say for both.
    * GWT is Ajax all the way, while Wicket supports a mixed or non-Ajax development model. * Though I consider Wicket's Ajax support very good, GWT's is probably even better. One concrete thing is that GWT provides robust Ajax back button support, which is something to be improved still in Wicket.
  32. This is a false dichotomy. Why do you need to choose one or the other? Wicket is server side and GWT is client-side. The two could work quite nicely together, giving you the strengths of each. In fact, there is a project going on now to integrate the two. It's just getting started, but you could always contribute.
  33. Yes, I assume it is possible to use GWT and Wicket together.
    As well as GWT with Struts 2 or GWT with JSF and so on. But does it make much sense to integrate several technologies where you can just do everything you need with only one? This can actually complicate maintenance and require you not only to learn both technologies but also resolve possible integration issues. Surely this is not always the case but still there is a high chance such complication can happen. As I know GWT does not require any server-side complement a.k.a. MVC like framework or anything like this (correct me if I am wrong). So I assume it should be simpler to go just with one web framework instead of using a bunch of them together.
  34. Yes, I assume it is possible to use GWT and Wicket together.
    As well as GWT with Struts 2 or GWT with JSF and so on.
    But does it make much sense to integrate several technologies where you can just do everything you need with only one? This can actually complicate maintenance and require you not only to learn both technologies but also resolve possible integration issues. Surely this is not always the case but still there is a high chance such complication can happen.
    As I know GWT does not require any server-side complement a.k.a. MVC like framework or anything like this (correct me if I am wrong). So I assume it should be simpler to go just with one web framework instead of using a bunch of them together.
    That's true. You could learn both though. They both have their strengths and weaknesses. And while I'm not arguing that you should start developing projects with both frameworks at the same time, it is good to know that you can reuse GWT components in other frameworks. I have no idea how often that makes sense, but since I'm working on a project that uses both Wicket and Flex - and that works fine - I can imagine it could work out for people. All I'm saying is that you don't have to close the door completely for either if you choose one.
  35. Hi, When can we expect (roughly) the JDK 1.5 version to be fully released and available? thanks
  36. Hi,

    When can we expect (roughly) the JDK 1.5 version to be fully released and available?

    thanks
    Well I will try to look beyond the lack of an answer (Is this the level of support a user can expect from the wicket community/forum??) From the wicket website:
    Basically a large part of the answer is: when the majority of our customers can run their web applications on Java 5. As IBM WebSphere is one of the leading application servers, having Java 5 support for WebSphere application server is one condition. Furthermore, upgrading to Java 5 will break a lot of stuff, so this will be scheduled for a major release. At the moment this is scheduled for Wicket 2. We would like to give other functional requirements a higher priority, like AJAX and Portlet support, as those will help all users of Wicket. So first Wicket 1.1 and 1.2 will see the light of day, after that we will see what needs to be done
    Still have no idea as to when there will be a Wicket Java 5 release. For me anyway, the project is worthless until I have some information on a timetable for this.
  37. When can we expect (roughly) the JDK 1.5 version to be fully released and available?


    Well I will try to look beyond the lack of an answer (Is this the level of support a user can expect from the wicket community/forum??)
    This is not the Wicket community nor a Wicket forum. This is TheServerSide community, and therefore probably not the best way to find this type of answers. A simple google query with the following (not uncommon) keywords: wicket roadmap gives you a link to my blog with a roadmap document. We intend to release a Java 5 based version with generics support after 1.3 is released. The FAQ you quoted was an old one, it will be removed when we move all our stuff over to Apache. Historically this was a FAQ when Java 5 was still Java 1.5, and the J2EE stack happilly utilized Java 1.4. IIRC, this was about the time of the Wicket 1.1 release. Fortunately the times have changed, and we have more people deploying on Java 5. Also we have a feature complete and finished product in our 1.3 release. We expect to have an alpha release of the new Java 5 Wicket version shortly after one of the first maintenance releases of 1.3 (1.3.1 or 1.3.2, depending on the speed and need of maintenance fixes).
    Still have no idea as to when there will be a Wicket Java 5 release.

    For me anyway, the project is worthless until I have some information on a timetable for this.
    I am not sure why it is completely worthless when a framework it isn't Java 5 based? Spring surely doesn't require Java 5, does that make it completely worthless?
  38. When can we expect (roughly) the JDK 1.5 version to be fully released and available?


    Well I will try to look beyond the lack of an answer (Is this the level of support a user can expect from the wicket community/forum??)


    This is not the Wicket community nor a Wicket forum. This is TheServerSide community, and therefore probably not the best way to find this type of answers.

    A simple google query with the following (not uncommon) keywords: wicket roadmap gives you a link to my blog with a roadmap document. We intend to release a Java 5 based version with generics support after 1.3 is released.

    The FAQ you quoted was an old one, it will be removed when we move all our stuff over to Apache. Historically this was a FAQ when Java 5 was still Java 1.5, and the J2EE stack happilly utilized Java 1.4. IIRC, this was about the time of the Wicket 1.1 release.

    Fortunately the times have changed, and we have more people deploying on Java 5. Also we have a feature complete and finished product in our 1.3 release.

    We expect to have an alpha release of the new Java 5 Wicket version shortly after one of the first maintenance releases of 1.3 (1.3.1 or 1.3.2, depending on the speed and need of maintenance fixes).

    Still have no idea as to when there will be a Wicket Java 5 release.

    For me anyway, the project is worthless until I have some information on a timetable for this.


    I am not sure why it is completely worthless when a framework it isn't Java 5 based? Spring surely doesn't require Java 5, does that make it completely worthless?
    I am still none the wiser as the bank which I work for does not allow access to flickr pages (where your roadmap is). I never said Wicket was 'completely worthless'. It obviously isn't. It is however of no interest to me at this point unless we can code using generics etc, using Java 5 as development/build/deployment, or at least know roughly at what point in the future we will be able to, using a stable release of the framework. Is there likely to be fully fledged Java 5 release of the Wicket framework by 2008?
  39. Java 5 support inside Wicket[ Go to top ]

    Java 5 support is slated for fall this year. We expect the Java 5 version to follow quickly after 1.3 is final because we made a promise to our users regarding that. In our experimental branch we already have quite some experience with Java 5 and generics so that will be pretty quick. The original plan was to release the JDK 1.5 version one or two weeks after 1.3 final. But given the lack of time to actually work on the codebase (graduation, writing a book, customer projects, etc) gives me the impression that late fall is more likely than one month after 1.3. Now if we can constrain ourselves not to add more features.... :-)
  40. Java 5 support is slated for fall this year. We expect the Java 5 version to follow quickly after 1.3 is final because we made a promise to our users regarding that. In our experimental branch we already have quite some experience with Java 5 and generics so that will be pretty quick.

    The original plan was to release the JDK 1.5 version one or two weeks after 1.3 final. But given the lack of time to actually work on the codebase (graduation, writing a book, customer projects, etc) gives me the impression that late fall is more likely than one month after 1.3.

    Now if we can constrain ourselves not to add more features.... :-)
    OK thanks. Look forward to it.
  41. Re: Java 5 support inside Wicket[ Go to top ]

    code flunki, you do realise that you can build Wicket apps right now using Java 5 (or 6 for that matter), right? It's just that Wicket itself isn't built with Java 5. I'm working on a wicket 1.2.6 app built on Java 6 and it's not a problem. The only thing is that generics aren't built into the wicket APIs yet. It's hardly a problem.
  42. Support for Java 5[ Go to top ]

    I am not sure why it is completely worthless when a framework it isn't Java 5 based? Spring surely doesn't require Java 5, does that make it completely worthless?
    I hope that Spring users on Java 5 can live with the fact that Spring, even version 2.1, still supports JDK 1.4 :-) Seriously, Spring has been supporting specific Java 5 features since Spring 1.2 already, and introduced full-fledged Java 5 support in Spring 2.0. While the Spring 2.x core is still JDK 1.4 compatible, we autodetect Java 5 and leverage all sorts of Java 5 features at runtime - including support for generics in application classes (e.g. typed collections) and various annotation options. This remains the case for Spring 2.1, with even more annotation options available as well as Java 6 features being supported - while still supporting JDK 1.4 as well. So it is possible to support Java 5 to a large extent while remaining compatible with JDK 1.4 - in the same product branch. This at least works for non-intrusive frameworks such as dependency injection containers and AOP frameworks. It is harder to achieve - or even impossible to do properly - for frameworks with lots of pre-built base classes. I suppose UI frameworks fall into that latter category, although it might still be worth a try to introduce some Java 5 support in the JDK 1.4 based product line already. Actually, Spring has even been supporting JDK 1.3 up until Spring 2.0, alongside full-fledged Java 5 support. We raised the minimum JDK level for Spring 2.1, mainly because of Java 6 being explicitly supported now (we generally support the past three generations of the JDK) but of course also because of Sun having officially EOL-ed JDK 1.3 in the meantime. As a further factor, IBM has EOL-ed WebSphere 5.0, its last JDK 1.3 based version; WebSphere 5.1 and 6.0 are already built on JDK 1.4 (hurray!). Juergen
  43. Opinion of wicket[ Go to top ]

    Congratulations to the wicket team! I have been working with wicket for a couple of months and believe it is a well thought out framework. However, it does create some programming frustrations. I am required to build a very complex table in my application which looks different based on permissions etc and has many nested components and fancy formatting. Mimicing something like this using wicket objects is not easy. It would have been a lot faster (but uglier and hard to understand) using JSP. It would be great if wicket would come with a html to objects tool (like the xml translation tools) which would create the java objects with the proper formatting and then the developers could provide the data using a model because if the html already provides the look and feel (Most of the time developers are given html generated by html designers )then why should developers have to slave to replicate it using objects? I don't know if I would choose wicket for every project but I do believe it has a promising future and that it's ideas are well worth exploring.
  44. Re: Opinion of wicket[ Go to top ]

    Congratulations to the wicket team! I have been working with wicket for a couple of months and believe it is a well thought out framework. However, it does create some programming frustrations.
    I am required to build a very complex table in my application which looks different based on permissions etc and has many nested components and fancy formatting. Mimicing something like this using wicket objects is not easy. It would have been a lot faster (but uglier and hard to understand) using JSP. It would be great if wicket would come with a html to objects tool (like the xml translation tools) which would create the java objects with the proper formatting and then the developers could provide the data using a model because if the html already provides the look and feel (Most of the time developers are given html generated by html designers )then why should developers have to slave to replicate it using objects? I don't know if I would choose wicket for every project but I do believe it has a promising future and that it's ideas are well worth exploring.
    Wicket isn't always easier than other frameworks. And I think much of that has to do with the fact that OO programming isn't always easier than scripting in JSP. I can pretty much guarantee you though, that your Wicket code will be much easier to maintain and refactor once you build it. I think the trick with Wicket often is to create custom components for what you want, and pick a base component that doesn't already do to much. I sometimes see questions on the mailing lists that point to users trying to bend existing components to their needs to much, while going from scratch (or at least from a good base class) might actually be easier.
  45. For those of you who come across this thread: Wicket In Action is now available through Manning's Early Access Program.