• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

[Wicket] Form Binding Overly Complex?

 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First let me say that I don't not like Wicket. And I dig the Wicket community a lot. It's full of really cool folks. I don't intend for this to turn into a framework war so this question is more for the sake of my own education.

I'm a big Stripes fan and its form binding is elegant and simple. I'm reading through Wicket In Action and I am reading about Models. Particularly Listing 5.6:



I'm really confused by the verbosity of binding form values to Java objects. Take, for example, the Stripes way...



Stripes handles binding properties as deep as they go automatically based on the name of the HTML input element. In this case it would have been...



Why is the binding process in Wicket left to the developer rather than the framework?
[ May 20, 2008: Message edited by: Gregg Bolinger ]
 
author
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:

Why is the binding process in Wicket left to the developer rather than the framework?

[ May 20, 2008: Message edited by: Gregg Bolinger ]



Well, that's really the big old declarative vs imperative programming question. Declarative programming, like your example, provides for shorter code in general, but only as long as your cases are within the boundaries of what the framework supports. And that's where the crux is. While Wicket is more verbose for simple use cases, it's flexibility is almost without limits.

For instance, see Al's tutorial on how to create generic bean editor. You can quite easily create your own DSL-like constructs on top of Wicket. Many competing frameworks however already made many of the choices for you, so you are more limited.

The example you gave can easily be written much shorter, but the point of it is to show you some of the constructs available in Wicket.
 
Eelco Hillenius
author
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An example of both more complex UI code and DSL like construct (the markup is one line: '<div wicket:id="nodesTree"></div>') is this tree I'm right now working on:



This component draws a tree (SiteNodeTreeNode elements), and one of the things you can see above is the LoadableDetachableModel which creates a string from two service calls. You get the current tree node passed in, and the model caches it's results for the duration of the request (which in this case doesn't really matter to be fair). Then, the tree table itself has an override onNodeLinkClicked, which instructs the Ajax engine to re-render two dependent components when a node is selected in the tree.

It's not the shortest code ever still, but doing similar things in competing frameworks is often very tedious and often requires hacks (don't get me started on how to implement something like this in Struts or one of it's clones).

In fact, if you browse through the tree class you can see a nice example (imho at least) of a component that is built up in a hierarchy of gradually more specific classes. If I needed the case where I'd have a tree and dependent components more often for instance, I would simply create a base class for it and instantiating it throughout my project would be straightforward and I'd avoid a lot of code duplication.

Cheers,

Eelco
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eelco Hillenius:
The example you gave can easily be written much shorter, but the point of it is to show you some of the constructs available in Wicket.



I'd be interested in seeing the shorter version.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eelco Hillenius:
An example of both more complex UI code and DSL like construct (the markup is one line: '<div wicket:id="nodesTree"></div>') is this tree I'm right now working on:



So what you are saying is there is a trade off that the simple things appear more verbose and complex but the more complex things get simpler? Your component makes some assumptions as well. But what it doesn't do is help me understand form binding in Wicket. Well, I understand what is happening but seriously, 9 times out of 10 I want to bind a value from a form into a property of an object. There is a bit of type converting but nothing about that process is ever that complicated, really.

Couldn't wicket have just as easily provided more standard "assumptions" but also provided the flexibility that you speak of?
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eelco Hillenius:
For instance, see Al's tutorial on how to create generic bean editor.



the URL to the .mov file is 404ing, just an FYI.
 
Eelco Hillenius
author
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:

Couldn't wicket have just as easily provided more standard "assumptions" but also provided the flexibility that you speak of?



We could, but we rather have people build such things themselves. Same goes for components. While Wicket ships with a large number of reusable components, we feel the best way to use Wicket is to create your own set tailored to your needs.

That said, there are several projects out there where people tried to take Wicket a step further. See for instance Wicket Web Beans, DataBinder and some wicket-stuff projects. And projects like Grails and Seam take advantage of Wicket's extensibility to integrate it.
[ May 21, 2008: Message edited by: Eelco Hillenius ]
 
Eelco Hillenius
author
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:


I'd be interested in seeing the shorter version.



 
Eelco Hillenius
author
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eelco Hillenius:


It can, but we rather have people built such things themselves. Same goes for components. While Wicket ships with a large number of reusable components, we feel the best way to use Wicket is to create your own set tailored to your needs.



A super simplistic example of a generic editor that generates a form and textfields for all string properties of a bean for instance could be written like (I didn't actually test it, but it'll give you an idea):


with markup




As you can see, it's pretty straightforward to create custom Wicket components that can save you a lot of work, avoid code duplication and ensure consistency in look and feel etc.

There are so many ways even something like a bean editor can be written though, that we feel it is better we keep on focussing on the building blocks and providing a framework that is easy to extend/ customize and let our users (or third party projects) do the rest.

[ May 20, 2008: Message edited by: Eelco Hillenius ]

[ May 20, 2008: Message edited by: Eelco Hillenius ]
[ May 20, 2008: Message edited by: Eelco Hillenius ]
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Eelco. It's going to take some time for me to digest this and come back with a response, if I have one. I really appreciate the level of detail in your replies.
 
author
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In your first post you are comparing an example trying to show how to do things that are not part of your stripes example. The intent of the example was not to write the shortest amount of code.

The book also has the shorter version, just using the CompoundPropertyModel.

In Wicket we try to steer away from as much magic as possible. For a lot of folks CompoundPropertyModel and PropertyModel are already magic. Autowiring data to fields is even more magic in my opinion and I really don't like that in a core framework. We have built Wicket to be a toolbox for being extensible. And the fact that someone built WicketWebBeans on top of Wicket proves that Wicket has a solid foundation. If you want to write less code, and don't care about magic WicketWebBeans is the way to go.

This is the code necessary using WicketWebBeans:

 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic