Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Wicket: Page Parameters
At 8:23 PM on Jan 25, 2006, R.J. Lorimer wrote:
Fresh Jobs for Developers Post a job opportunity
It's been a while since my last Wicket post, and I've been receiving quite a bit of positive feedback regarding the previous posts - so let's continue today with an extension on the idea of bookmarkable page links.
First, some corrections. My last post had a couple typos - I've corrected those, and updated the post (thanks to Jonathan Locke of the Wicket team). Second, I promised to update the home-page with the latest links, but somehow failed to manage doing that. It is done so now.
If you haven't already, please read the existing articles - the previous history is listed here - as pointed out in other posts, I plan to keep the first article updated with the complete article list, so check there:
Last time, I discussed the concept of a bookmarkable page link. This was a special component in Wicket that behaved without state - it constructed a specialized URL for Wicket to consume, and didn't rely on any server-side components to handle the event. The strength of the bookmarkable link is that it allows a page to behave statelessly, much like the 'easy path' found in most MVC frameworks. Let's expand on that a bit with the concept of page parameters.
The Wicket class
wicket.PageParameterseffectively represents a set of key-value pairs that you would want to pass to a particular page (I know, hard to tell by the name, isn't it ;)), and is pretty much analogous to request parameters in the servlet world. The API of the PageParameters class is fairly rich, with value conversion built-in for the most common types, but for the most part you can think of it as a hashmap.Creating a page that accepts page parameters is remarkably easy - just create a constructor with a single
PageParametersargument. Let's extend our running example with this usage pattern:package com.javalobby.tnt.wicket.aloha; import wicket.PageParameters; import wicket.markup.html.WebPage; import wicket.markup.html.basic.Label; public class Page2 extends WebPage { public Page2(PageParameters parameters) throws Exception { add(new Label("pageTitle", "Welcome to Page 2")); long productId = parameters.getLong("productId"); System.out.println("Product Id: " + productId); add(new Label("pageParam", String.valueOf(productId))); } }As you can see from this example, I'm expecting a 'long' value to be passed in with the key 'productId'. If the value passed in can't be converted to a 'long', a checked exception of type
wicket.util.string.StringValueConversionExceptionis thrown by thePageParametersclass - you'll notice that I've augmented the constructor to also throw 'Exception'. In many cases you would probably want to handle this more appropriately, such as reporting the invalid product ID in some fashion to the user. That's outside the scope of this tip however.Now, we need to make sure that we update our page markup to do something with this new label object. Here's the new markup:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:wicket="http://wicket.sourceforge.net/" xml:lang="en" lang="en"> <head> <title>Page 2</title> </head> <body> <h1 wicket:id="pageTitle"></h1> <h2>Product Id: <span wicket:id="pageParam"></span></h2> </body> </html>Lastly, we'll want to take advantage of our new parameter in our linking page. Now, if you'll remember initially, we used the
BookmarkablePageLinkcomponent to link to our page. If we were still using this technique, the format to provide a page parameter would look something like this:new BookmarkablePageLink("page2Link", Page2.class, new PageParameters("productId=1694969292874602935"));However, we're not using this bookmarkable link component explicitly any more, we're using the special <wicket:link> tag. How do we supply page parameters if we are using this markup tool? It's as straightforward as you would guess - the parameters are put in with the html naming convention. Here is the markup for our
AlohaPage.htmlwith this new format implemented:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:wicket="http://wicket.sourceforge.net/" xml:lang="en" lang="en"> <head> <title wicket:id="pageTitle">[Page Title]</title> </head> <body onload="fromAlohaPage();"> <h1>This is the BEGINNING of the Aloha Page</h1> <a href="#" wicket:id="dateLink">Click me!</a> <!-- Supply a product ID --> <wicket:link><a href="Page2.html?productId=1694969292874602935">Go to Page 2</a></wicket:link> <div wicket:id="personPanel"></div> <h1>This is the END of the Aloha Page</h1> </body> </html>Wicket has a robust parsing system in place for handling this type of linking.
One final note - if the values in the page parameters are inherently dynamic, it's best to use a
BookmarkablePageLinkdirectly, as that allows you to use Java code to set up these page parameters.Here's the final appearance of this new page 2 when triggered by the link on the 'home page':
Thanks for reading YAWA (yet another Wicket article) - I hope you find this informative. As usual, any feedback, comments, questions, and other errata is certainly welcome!
Until next time,
R.J. Lorimer
Contributing Editor -rj -at- javalobby.orgAuthor -http://www.coffee-bytes.comSoftware Consultant -http://www.numbersix.com10 replies so far (
Post your own)
Re: Wicket: Page Parameters
Should not the line in page2look like
Re: Wicket: Page Parameters
No:<h2>Product Id: <span wicket:id="pageParam"></span></h2>
has this as Java code:
add(new Label("pageParam", String.valueOf(productId)));The span is attached to the pageParam label component.
Or R.J. just adjusted the article, of course
Martijn
Re: Wicket: Page Parameters
A note to the article: you can't use the PageParameters for types other than simple types such as Strings and Integers. It is intended for HTTP transport capable types only.The bookmarkable links and PageParameters are used for things that need to be bookmarkable. It is best not to build your whole application around them, otherwise you'll loose the inherent nature of Wicket: working in a true object oriented nature.
R.J. hasn't reached the ListView component in his excellent tutorials yet, but here's a short example on how you would work without the PageParameters and navigate to another page with the Product object itself:
add(new ListView("listview", products) { protected void populateItem(ListItem item) { item.add(new Link("link") { protected void onClick() { Product p = (Product)getParent().getModelObject(); setResponsePage(new Page2(p)); } } } }In the
onClickhandler of theLinkcomponent, I retrieve the model object from its parent component: theListItem. The product is then passed on to the constructor ofPage2The Page2 webpage needs to have a constructor taking a Product directly:public class Page2 extends WebPage { public Page2(Product p) { // work with the product } }Probably this reply is too short to be a tutorial in itself. So before you go and construct your whole application using PageParameters solely, please wait a little or try working with
PageLinkcomponents.BookmarkableLinkshave very good uses, but they also expose details to your clients and may introduce security problems.For instance, the product id can be tampered with. There is nobody preventing the user to type in the bookmarkable URL and adjust the productId parameter. In itself this is probably not problematic, but when the parameter concerns a contract number in a shared application (ASP) it willl be a security risk.
Using the serverside state management of Wicket you can create more secure applications by not exposing such parameters and still provide a useful web application. Of course, you will loose the bookmarkability of such a product page.
Re: Wicket: Page Parameters
Martin,Thanks for clarifying. I actually purposefully intended to keep them separate just to keep the name collisions to a minimum, specifically so it was clear that the ID was being used in the markup.
Thanks again,
R.J.
Re: Wicket: Page Parameters
Very good points, yes.It should be made clear that page parameters are no more secure than request parameters, and they are also not really any more powerful than request parameters; after all, in the HTTP protocol case, that is how they are transported back and forth
Developers should be concerned what they use page parameters for; hopefully for those of you who are coming from a J2EE (servlet/struts/etc.) based background are already familiar with the limitations, restrictions and security concerns there-in.
Values that would have a negative impact when tampered with (such as product id) should be judiciously verified on the server side - whether that means by checking security permissions, or whatever else - it is publicly available to corrupt.
I would like to amend however, that while a POST style transaction is more opaque, it can still fairly easily be manipulated/tampered-with given enough knowledge or the appropriate tools.
That is why checking the validity of a value being passed in with a disconnected client/server mechanism (such as page parameters) is vitally important.
Thanks again Martijn - always a pleasure,
Re: Wicket: Page Parameters
> It should be made clear that page parameters are no> more secure than request parameters
Duh, they are request parameters.
I guess, explaining this kind of things is the price to pay for providing framework that has some level of abstraction from HTTP. I just noticed a question in JSF mailing list, "How to obtain a backing bean?" After being advised to pull it directly from session the next question followed: "How do I do that?".
Re: Wicket: Page Parameters
> I guess, explaining this kind of things is the price> to pay for providing framework that has some level of
> abstraction from HTTP.
No, we have to 'pay that price' because there haven't been good abstractions from the HTTP protocol. The request parameters are inherently unsafe. This is an aspect many developers ignore or are unaware of.
How many emergency fixes have to be rolled out because the wrong people can get at the wrong data? Because frameworks like Wicket, Tapestry and JSF provide the right abstractions, the security question is much more prominent: do I use a request parameter or do I use a encapsulated approach?
These frameworks aren't a safeguard against malice nor plain stupidity, but they provide better means to increase the inherent security of web applications.
Re: Wicket: Page Parameters
> The request parameters are inherently unsafe.If you stick them directly into SQL statement, for example, then yes. But the same is true for desktop apps.
> Because frameworks like Wicket, Tapestry and JSF
> provide the right abstractions, the security question
> is much more prominent: do I use a request parameter
> or do I use a encapsulated approach?
>
> These frameworks aren't a safeguard against malice
> nor plain stupidity, but they provide better means to
> increase the inherent security of web applications.
Martijn, you know that I like Wicket, but I just don't see how using the same cleartext HTTP parameters can be safer in one framework or another. It all depends on how you handle the parameters and whether you use them directly in your backend or database. Proper parameter handling can be implemented in any framework, even with plain servlets.
Re: Wicket: Page Parameters
> Martijn, you know that I like Wicket, but I just> don't see how using the same cleartext HTTP
> parameters can be safer in one framework or another.
Using the clear text parameters in a Wicket, Tapestry or JSF context is just as unsafe as it is in WebWork, Struts or roll your own JSP's. I don't contest that.
What I'm trying to get across is that a framework such as Wicket, Tapestry or JSF makes it much easier, and less error prone to keep such information internal to your application, and not expose it to the user. Thus inherently making a safer application.
Wicket makes it very easy to go the safe route and thus provides a better, conscious decision to the developer: should I go the easy route, safe route to hiding the object parameters from my users (which does add to the session size), or go the other easy route, through exposing the request parameter to the user and having to make sure the parameter isn't tampered with (using some sort of authorization).
Both choices are also possible with the so called 'non-component oriented' frameworks, but take a lot more work and one of the choices isn't an obvious one.
> Proper parameter handling can be
> implemented in any framework, even with plain
> servlets.
No argument here.
Re: Wicket: Page Parameters
Another great article, but could we expect anything less from you? I really enjoy the series and I'll be first in line to buy the book.