Discussions

News: Apache Wicket 1.4 takes type safety to the next level

  1. The Apache Wicket project is proud to announce the release of Apache Wicket 1.4 and Apache Wicket 1.3.7. Apache Wicket is an open source, component oriented Java web application framework. With overwhelming support from the user community, the release of Wicket 1.4 marks a departure from the past where we leave Java 1.4 behind and we require Java 5 as the minimum JDK version. By moving to Java 5 as the required minimum platform, we were able to utilize Java 5 idioms and increase the type safety of our APIs. Using Java generics you can now write typesafe web applications and create typesafe, self documenting, reusable custom components. Download Apache Wicket 1.4 You can download the release here: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0 Or use this in your Maven pom’s to upgrade to the new version: org.apache.wicket wicket 1.4.0 You will need to upgrade all modules (i.e. wicket, wicket-extensions) to their 1.4 counterparts. It is not possible to mix Wicket 1.3 libraries with 1.4 libraries due to API changes. Most notable changes From all the changes that went into this release, the following are the most important ones:
    • Generified IModel interface and implementations increases type safety in your Wicket applications
    • Component#getModel() and Component#setModel() have been renamed to getDefaultModel() and setDefaultModel() to better support generified models
    • The Spring modules have been merged (wicket-spring-annot is now obsolete, all you need is wicket-spring)
    • Many API’s have been altered to better work with Java 5’s idioms
    • Wicket jars are now packaged with metadata that makes them OSGI bundles
    Apart from these changes, the release is mostly compatible with Wicket 1.3 and upgrading shouldn’t take too long. Early adopters report about a days work to upgrade medium to large applications to Wicket 1.4. Read the migration guide to learn more about the changes in our APIs. To learn more about all the improvements and new features that went into this release, check the solved issue list in our JIRA instance. Increased type safety Moving towards Java 5 has given us the opportunity to utilize generics and clarify our API’s. For example, take a look at DropDownChoice—one of the components with the most questions on our list prior to 1.4. A DropDownChoice component is a form component that displays a list of available choices in a drop down box, and allows one selection to be made. DropDownChoice components are typically used to display a list of countries, nationalities, credit card processors, etc. The signature of a constructor for the DropDownChoice component in Wicket 1.3 was: public class DropDownChoice extends ... public DropDownChoice(String id, IModel model, IModel choices) } As you can see, this constructor doesn’t give much insight into what goes where (other than the names of the parameters). The first parameter is the component identifier, the second parameter is the model that contains the selection, and the third parameter is a model that contains the list of choices from which the user can select one. You’ll have to read the JavaDoc to assign the right IModel values to the right parameters. Now take a look at the same constructor, but now in Wicket 1.4. The signature for our generified constructor looks like the following example. public DropDownChoice extends ... public DropDownChoice(String id, IModel model, IModel<!--? extends List<? extends T-->> choices) } Here we communicate that the first IModel parameter is a T, which is the single value that will be provided when the DropDownChoice selects one value. The second parameter provides a List of objects that extend T, the choices from which to select one value. This was not apparent in the Wicket 1.3 API, and the type safety brought by generics make this much more clear, albeit much more verbose. Removal of default model from component In Wicket 1.3 each component had by default a model: a Label had a model, a Link and even WebMarkupContainer had a model property (all because they extend Component which has a model property). When we generified IModel, this had averse effects on Component: suddenly *all* components had to be generified and had to take the type parameter of the model that was associated with it. But that poses problems for components that either do not use a model or use two different model types: which one should be in the lead? We chose to generify only the components that clearly benefited from the extra type information, leading to clean code like this: ListView peopleListView = new ListView("people", people) { protected void populateItem(ListItem item) { item.add(new Link("editPerson", item.getModel()){ public void onClick() { Person p = getModelObject(); setResponsePage(new EditPersonPage(p)); } }); } }; Support - End of life for Wicket 1.3.x Wicket 1.3.7 has been release simultaneously. Wicket 1.3.7 will be the last feature release for the 1.3.x branch. Going forward, only security fixes will be released in the 1.3.x branch - meaning that 1.3.7 may be the last release in this branch. All users are encouraged to upgrade to 1.4.0 as soon as possible. As work begins on 1.5 in the near future, we will be supporting 1.4.x and 1.5.x. As always, the user lists are very active, and if you need help upgrading or just want to discuss this release, send an email to the users list. More information about the community and mailing lists can be found at http://wicket.apache.org/community.html

    Threaded Messages (17)

  2. Great news and kudos to wicket team! I'd like to take the opportunity and emphasize the goodness of this new model model interface and the use of generics. For example it is really great to have compile time check on DropDownChoice. It was somewhat funny when Eclipse suggested to change the order of models I've passed to it :) Istvan http://oktech.hu/blog/
  3. Wicket Mini ?[ Go to top ]

    Thanks for the good job done so far Wicket team. I can't begin to explain how much this web framework has been a godsend for me, and others I know using it. I hope this trend of good quality design decisions and sound judgement on feature inclusions continues in the Wicket development team. Martijn, can you or someone on the Wicket development team say if there are any future plans to adapt the Wicket framework to function in other UI contexts, such as VXML for IVR systems, or WML? I ask this because I see where a significant Internet user base is or has gone mobile via usage of portable mobile devices for Internet access, and access to IVR services.
  4. Re: Wicket Mini ?[ Go to top ]

    There are currently no plans to support these technologies in the core Wicket library. As far as I know some users have written component sets for VXML and WML, but were not able to share them with the community. The good thing is that writing these components is no different then writing HTML components ,so it should be relatively simple.
  5. Re: Wicket Mini ?[ Go to top ]

    There are currently no plans to support these technologies in the core Wicket library. As far as I know some users have written component sets for VXML and WML, but were not able to share them with the community. The good thing is that writing these components is no different then writing HTML components ,so it should be relatively simple.
    Not to support those other markup types in the Wicket core is understandable, and I have seen snippets of information on the web and in the Wicket Java docs about how support of these other markup types via Wicket could be accomplished. I'm just thinking as you said Igor, that if it should be relatively simple to support the other UI markup types, then one or two guys from the core Wicket team could just easily whip out a nice extensions package for that, or a more comprehensive blueprint/guide/article for the developers not so familiar with the Wicket underbelly more than just being mere power users of the Wicket APIs. I really think this should be given serious thought by Team Wicket, as the rise of the mobile devices becomes more evident everyday. It would be a shame for a good piece of tech like Wicket to not take these happenings into account. It would be, I think, a natural design decision to at least look at supporting a few of these popular, standards based UI markup languages, and then provide and easy extension path to others that may have an XML base, rather than leaving developers to hack about the framework to get this type of support. I'm anticipating that Team Wicket may make room for such a consideration, or at least having a couple of chapters in the Wicket in Action 2 book that talks about supporting other UI markups in Wicket. Kudos again to Team Wicket.
  6. Re: Wicket Mini ?[ Go to top ]

    Do you really need WML? WML is dead, isn't it? Can you show a real world example (may be related with VXML)? Congratulations to the Wicket team.
  7. Re: Wicket Mini ?[ Go to top ]

    Without a personal stake or interest into such a protocol, I think maintaining it would be a drag for the framework, therefore I don't foresee us doing anything to implement VXML, XUL or WML rendering. If someone wants to pick that up, we are keen to facilitate such an endeavor, and possible in the future adopt the code. But none of the core committers is working on products that utilize VXML, XUL or WML. Chances are slim that we'll be including that as a core feature. Nobody (or maybe 1 or two folks) has shown interest in these additional renderings for the last 4 years, so donating significant time to < 0.1% of our user base when there is enough to improve for the other 99.9% seems not a wise decision.
  8. Re: Wicket Mini ?[ Go to top ]

    I agree with you about VML but not about XUL, I think XUL mixed with AJAX is a really powerful and clean web development platform for applications which don't have the requisite of multiple browser support (XUL only works in Gecko browsers).
  9. Re: Wicket Mini ?[ Go to top ]

    Gentlemen, I fear that we are missing an obvious pattern here as far as Wicket UI development is concerned. It's not a matter of is WML dead?, or nobody, or no significant group of persons have asked for VXML, WML, or *ML support. As far as I am concerned, people were asking the same thing about JavaScript and html over the last decade, and look where we are now - JavaScript and XHTML now are bigger and in demand more now than ever, thanks to the Ajax UI development concept and CSSx. The point is that they are all XML based markup languages with similar UI development rendering patterns. Namely: 1) Use a scripting language to generate and output XML UI Markup over http. 2) Add seamless post-back processing of embedded input values within the XML UI pages. 3) Add JavaScript(or <script="xxx">) or UI tag event handling support. 4) Add Ajax support for more efficient UI XML tag updates. Now, I may be oversimplifying Wickets handling of the above steps, but it seems to me that we should not necessarily have to tie Wicket to XHTML as it's only rendered UI markup. If we can create a Java memory model of XHTML in server-side memory, what's the issue with representing the other XML UI cousins in a Java memory model as well? I mean, they all come from XML as a base. Now, I understand what Martijn is saying about no one asked for feature X or Y, plus the core Team is busy working on other pressing matters, as that speaks to a time and resource constraints issue for a volunteer group of open-source developers. What I'm concerned about is that we may be stunting the potential power of Wicket by using these resource and time constraints issues as inhibitors to exploiting the true power of Wicket, and hence unnecessarily and artificially binding Wicket to one XML UI variant, which to me, when I look at the bigger picture (i.e. XML based, declarative UI development processing on the server-side), doesn't seem natural. Again, I may be over simplifying the Wicket framework capabilities here as I'm not looking at the code-base. I just use the APIs like the next web application developer does. But can someone point out where I'm wrong with the assumptions made thus far in regards to having Wicket upgraded to naturally process other XML based UI markups, having a similar http request/response processing cycle as for XHTML based documents. I contend that this upgrade can probably be achieved through some sort of extensible, XML UI processing extensions package. Why care or argue if it's VXML, WML, or XUL? They all look and behave similarly, so exploit that in the Wicket framework. Team Wicket rules!
  10. Re: Wicket Mini ?[ Go to top ]

    Wicket already supports all this: A) Wicket is not tied to html, it can process any xml variant. There is no html-specific logic anywhere outside of html packages. B) Wicket aims to provide making custom components trivial, thus it is already trivial to create your own suites of components for *ML as long as it is a variant of xml. C) Wicket already has an abstracted request processing layer. It does not have to run as a servlet or even inside a servlet container. I remember someone implementing a Wicket server on top of Apache Mina. Anything else I am missing? Just because we do not aim to provide *ML support out of the box does not mean we did not plan for it in the core features of the framework.
  11. Re: Wicket Mini ?[ Go to top ]

    Wicket already supports all this:

    This is great news man. Like I said earlier, you guys build it, and we just use it.
    A) Wicket is not tied to html, it can process any xml variant. There is no html-specific logic anywhere outside of html packages.

    This too is great news, even though I don't recall seeing this mentioned in the great Wicket in Action book I bought.
    B) Wicket aims to provide making custom components trivial, thus it is already trivial to create your own suites of components for *ML as long as it is a variant of xml.

    Now this one I knew about already. I've been having loads of fun doing it for a project I'm currently working on, and this was mentioned in the Wicket in Action book too - but specifically for XHTML components. However, I didn't know about being able to do this for other *ML variants.
    C) Wicket already has an abstracted request processing layer. It does not have to run as a servlet or even inside a servlet container. I remember someone implementing a Wicket server on top of Apache Mina.

    I know about the abstracted request processing layer. This too was in Wicket in Action.
    Anything else I am missing? Just because we do not aim to provide *ML support out of the box does not mean we did not plan for it in the core features of the framework.
    Well, I guess the only thing I would say missing is that you guys could make this information more public. Meaning, as you said earlier, "Wicket already supports all this." If it does support all of what I was speculating it didn't, then aim to get rid of the speculation by at least looking to get an article or two out there showing us Wicket in Action readers how to do so without having to go muddle around the code base and Wicket Java docs. That way, the < 99% percent of us who do need support for other *MLs won't get nervous that if we do get a hack working, a new Wicket design decision for processing *ML won't radically affect anything that was done by some group to get support for processing other *MLs apart from XHTML processing. Bottom line is that you guys really know the capabilities of the framework because you guys currently build it and maintain it. The rest of us are just end users of the framework. Also, I am a VXML developer and I know others who are too. The Voice XML market is a billion dollar one. The reason why the Wicket team might not be getting requests to support other *MLs out of the box, is because it may seem that information coming out about Wicket is that the primary purpose of Wicket is for making processing and serving XHTML on the server-side easy. And I must say, it does so quite nicely as it was built to do, and hence, because of the XHTML focus, developers just speculate/assume that Wicket is just for XHTML and not other *MLs, so they don't bother asking for those feature updates from the Wicket team. So in closing, give us the nervous ones your blessings by confirming in scripture that yes, it is ok to use Wicket for processing, VXML, WML, or *ML, and here are the recommended best practices for doing so. E.g. Article 1. Start out by subclassing the Wicket Page class or WebPage class for other *ML container pages, then... Wicket rocks!
  12. Re: Wicket Mini ?[ Go to top ]

    That way, the < 99% percent of us who do need support for other *MLs won't get nervous that if we do get a hack working, a new Wicket design decision for processing *ML won't radically affect anything that was done by some group to get support for processing other *MLs apart from XHTML processing.
    You mean < 1%? :) The point I was trying to make is that there is no "hack" needed for this, all these things are supported out of the box. Have a look at the javadoc of getMarkupType() method: http://tinyurl.com/m778mb. It even specificically mentions VXML. That is from Wicket 1.2.1 released 2006-07-24. No one on the core team has any knowledge of WML or VXML, nor are interested in investing what will undoubtedly be a non-trivial amount of time into learning the tech. You, and other users of Wicket, are of course more then welcome to write up an article on our WIKI or contribute a component suite since you already have the knowledge of both technologies - we will be happy to answer any implementation questions you will have.
  13. Re: Wicket Mini ?[ Go to top ]

    That way, the < 99% percent of us who do need support for other *MLs won't get nervous that if we do get a hack working, a new Wicket design decision for processing *ML won't radically affect anything that was done by some group to get support for processing other *MLs apart from XHTML processing.


    You mean < 1%? :) The point I was trying to make is that there is no "hack" needed for this, all these things are supported out of the box.

    Have a look at the javadoc of getMarkupType() method:
    http://tinyurl.com/m778mb. It even specificically mentions VXML. That is from Wicket 1.2.1 released 2006-07-24.

    No one on the core team has any knowledge of WML or VXML, nor are interested in investing what will undoubtedly be a non-trivial amount of time into learning the tech. You, and other users of Wicket, are of course more then welcome to write up an article on our WIKI or contribute a component suite since you already have the knowledge of both technologies - we will be happy to answer any implementation questions you will have.
    What the heck? I'll give Wicket for VXML a shot, and if it works out ok for the project I'm working on now, I'll do a public write-up. A component suite for VXML may follow. Kinda getting tired of doing VXML with JSPs anyways.
  14. Re: Wicket Mini ?[ Go to top ]

    Thats the spirit!
  15. Re: Wicket Mini ?[ Go to top ]

    If memory serves me well, I think Jonathan Locke intended to use Wicket for voicexml. In 2004 the package names were com.voicetribe.wicket :-) Life happened, and therefore VXML+Wicket didn't.
  16. Re: Wicket Mini ?[ Go to top ]

    Yeah, VXML was a target. And I've already done WML (sorry, proprietary code) and another proprietary markup language (with minor changes to the core that never made it into core Wicket), so it's very possible.
  17. Re: Wicket Mini ?[ Go to top ]

    I really think this should be given serious thought by Team Wicket, as the rise of the mobile devices becomes more evident everyday.
    Most current and future devices are capable of rendering plain HTML perfectly fine. IMO there's no need to go the WML route, but I'm not involved in the mobile space, so I might be mistaken. AFAIK WML is dead, long live HTML.
  18. Is Lift the next level?[ Go to top ]

    Martijn, what do you think of Lift? They have copied some ideas from Wicket.