Wicket from the point of view of a PHP developer

July 14, 2010 – 4:55 pm Tags: ,

Not long ago, I had to learn some Wicket. What is that? In this case it has nothing to do with cricket – The Wicket I’m talking about is a Java web application framework.

I’ve mostly used PHP and Python to do server-side web application sort of programming. Compared to what I’m used to, Wicket is way different.

Read on to find out about a different way to develop web applications.

My starting point

My starting point with Wicket was basically zero, at least Java-wise: I had never used any Java web app framework, so I didn’t really know what to expect.

Since as I said I’ve mostly used PHP and Python, I assumed the program flow would be something like in them:

  • Bootstrap
  • Routing etc. handled by framework, goes to a controller
  • Controller checks things like whether this is a POST or a GET, maybe decides to load data from models
  • View is rendered. PHP or a template language is used to print values from controller in the view

Of course, this was a completely wrong assumption.

Form submit: PHP vs. Wicket

Wicket in my experience has much more in common with traditional desktop application frameworks than with web stuff. Whether this is a pro or a con, I can’t say at this point.

Consider a very typical case of handling a form. What I had done before it was something like this:

  • Is this POST? If so, save stuff
  • Display form, with values from POST if there was a validation error

In Wicket, it works something like this:

  • Display form

Of course, there is a bit more to it than just that.

First, we would create the HTML markup. In PHP, you typically would just put a bunch of echo statements here to display values. Wicket however does things completely differently: You add special attributes to the tags – in the case of a form, we would add wicket ID attributes to the form element and any fields and buttons we might have.

Next, we tell Wicket what components our page has. The reason we put special ID attributes into the markup is so that Wicket knows what elements to associate with which components. So we tell Wicket that we want a form component, input components for input fields, and a button for the submit button. We can also add validators to each component. Also needed is a model, which for sake of simplicity you can assume is a bunch of key-value pairs automatically serialized to some storage (You can actually have something like this pretty easily).

In PHP we would typically tell the view object what values to assign to variables that we echo in the form. We might also test if the method is POST and perform validation and model stuff there.

In Wicket we don’t need to give the form an action and we don’t need to check whether the form was submitted or anything – Wicket does all this for us. The model can even persist things automatically without us having to lift a finger.

So if you compare this explanation (which is not very in depth), it is a lot like a desktop application in Wicket. We don’t tell it anything about the web stuff that happens around it – we just tell it that this is how our document looks and this is how our document behaves. In Windows Forms, you tell the same things. In PHP you need to take care of the logic of the web too, such as handling POST or determining the URL where the form needs to be submitted for it to work.

Conclusion

Wicket is a lot like desktop app development, since you work with components – in desktop apps, you work with controls. Desktop developers don’t need to worry about where stuff goes when the page changes, saving the state, because there are no page changes. Wicket developers don’t need to worry about that either, because Wicket persists things – in a somewhat similar fashion to PHP’s session storage, but automatically and much more extensively.

I was working with Wicket in a portlet environment, so I probably didn’t see all of basic Wicket stuff. Also bear in mind that I only have little experience working with Wicket, so there probably is more than just this.

One case where Wicket’s automatic state persistence and other features might be useful is web applications where you perform actions with multiple steps. Other than this, it does feel somewhat heavy, and occasionally repetitive for the markup and component parts.

Nevertheless, it is an interesting way to do things and if you have the chance, I’d recommend giving it a shot.

Share this:

RSS feed Subscribe to my RSS feed

About the author

Jani is a 15 year veteran of the software industry. He's currently available for consulting

  1. 8 Responses to “Wicket from the point of view of a PHP developer”

  2. In PHP, if you have used Prado or YiiPHP, it is very similar, event driven frameworks.

    tri

    By tribui on Jul 15, 2010

  3. It’s easy to do hard things in wicket but it’s boring to do things that’s easy in regualart php MVC f-work.

    80% code we write is easy – use php – it rocks!

    By Aybat on Jul 15, 2010

  4. Wicket uses HTML for static elements of a page, and as the components’ layout manager. Aside from that, the designers’ intent was indeed to make it more like desktop programming.

    Having to deal with Post and Get and request parameters explicitly is sort of like desktop programming where your code explicitly pushes and pops things off of the Windows message queue. I don’t know why so many web developers put up with it.

    By fsilber on Jul 15, 2010

  5. The way Wicket stores page and component state makes it hard to scale: session. As a result, you end up with a lot of things to store in the memory

    I don’t think Wicket way is good. It is just too verbose. Most of the web pages can be very stateless. I don’t know any case in the web development that needs keep page states other than multiple page forms

    By pcdinh on Jul 15, 2010

  6. Pcdinh;

    Wicket supports stateless pages too.

    By Josh on Aug 17, 2010

  7. It depends whether you’re building a website versus a web-deployed application. Wicket is for building web-deployed applications.

    By fsilber on Aug 17, 2010

  8. I agree with fsilber. Wicket is for applications…not basic web sites. I am experienced with PHP and Java and started using Wicket fairly recently. Wicket is a totally different paradigm in web app development from the common version of MVC found in most PHP frameworks. Without a shadow of a doubt I believe its the better way to develop. I cringe now having to work in my old PHP code bases and planned to convert everything to Wicket. BUT now with the mess going on with Oracle and Java I don’t think I’ll be continuing on with Java much further. So I started looking into the feasibility of building a Wicket like framework for PHP. I have not checked out YiiPHP and no Prado is not acceptable. Prado is a copy of .Net web forms and takes along with it the numerous shortcomings. Web forms are no where close to Wicket.

    By Phil on Oct 27, 2010

  9. I believe that Wicket could have been yet nicer to use, had it been designed around C# or Scala. (Since Wicket does not make use of the Windowing toolkits, and theoretically shouldn’t even require J2EE, I wonder whether there could exist a Java-to-C# automatic translator which would generate an implementation of Wicket in C# on Mono.)

    By fsilber on Oct 27, 2010

Post a Comment

You can use some HTML (a, em, strong, etc.). If you want to post code, use <pre lang="PHP">code here</pre> (you can replace PHP with the language you are posting)