when you construct a listview with a list in the constructor instead of imodel, the listview creates a simple Model implementation and sticks the list into it. this is really nothing more then a convinience constructor. the same code would look like this w/out it:
List list=getList();
new ListView("id", list);
or
new ListView("id", new Model((Serializable)list));
so now that we have the listview how can listitems retrieve the item of the list they are created to represent? for this listview assigns each created listitem with a model that wraps the item in the list the listitem container represents.
this is done in ListView.getListItemModel method which you can override to provide your own IModel implementation that should wrap the item sin the list.
so what this allows you to do is
pupulateItem(ListItem item) {
User=(User)item.getModelObject();
retrieve the item of the list this listitem represents w/out accessing the list directly. if you wrap listitem's model with a compound property model then its children can also access it easily.
now about the RadioGroup.
this component was born because RadioChoice was too inflexible since it took over the generation of markup. so you caouldnt use it in a listview or any other repeater.
the way RadioGroup/Radio work is that
the RadioGroup's model represents the store where you want the selected item to be put, while Radio's model represents the value itself you want to retrieve. When the form is submitted the RadioGroup's model/object/ is set to selected Radio's model/object/
so something like this:
class FormBean { String color; //setters, getters }
FormBean bean=new FormBean();
form.add(new RadioGroup("gorup", new PropertyModel(bean, "color")));
...
form.add(new Radio("radio1", new Model("green"));
form.add(new Radio("radio2", new Model("yellow"));
form.add(new Radio("radio3", new Model("red"));
so if you select radio2 then on form submit this code is going to run
RadioGroup.setModelObject(radio2.getModelObject());
so FormBean's color property will be set to string "yellow"
does this clear things up a bit?
-Igor
Igor's description of the ListView operation is very helpful.
What also confused me about the RadioGroupPage (of the component reference examples in the Wicket Library) was the use of models with each of the parts, the details of which are hidden from us in the examples by the use of text-saving alternate constructors. I'm guessing that it works something like as follows (confirmation or correction would be most welcome!):
When we create the ListView, we give it a java.util.List as a convenience via an alternate constructor, but this alternate constructor wraps the java.util.List in a wicket List that implements IModel. However, this IModel object is only used internally.
When the ListView creates the ListItem container component for each java.util.List element, the ListItem is built with its own IModel wrapping the individual java.util.List element.
The populateItem() method over-rides the ListView's abstract method in its concrete subclass, and is called to fill each ListItem with subcomponents, providing (among other things) an IModel for each element added to the ListItem. Typically, the subcomponent's model is based on a piece of the ListItem's model. For a simple label, for example, we can call getModelObject() on the ListItem to reach past the IModel wrapping, and then drill down to the relevant java.lang.String contained within. We can then allow the Label's convenience constructor to wrap the java.lang.String within an IModel. Alternately, we can construct a PropertyModel for the Label using the ListItem's IModel and an OGNL string.
Within a RadioGroup, the model for each Radio button can be anything that is distinguishable from the other Radio buttons' models. Rather than recording TRUE or FALSE for each Radio button as we would for Checkbox's, the framework simply sets the model of the overall RadioGroup to the selected Radio button's model. (If the RadioGroup is initialized to have no Radio button selected, we create it with an empty "default" Model, as this will differ from every Radio button's model.)
If we create a set of Radio buttons dynamically based via a ListView, the models for each ListItem will be distinguishable from one another -- with a 1-to-1 correspondence between ListItem's and Radio buttons. Therefore, the easiest thing to do is to re-use each ListItem's IModel as the IModel for its Radio button, as is done in the RadioGroupPage example.
Is this the intuition?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Igor Vaynberg
Sent: Monday, January 23, 2006 12:45 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] ListView tutorial?
radiogroup aside
lets take a simple example, we want to show a table of users:
<table>
<tr wicket:id="listview">
<td><span wicket:id="firstname"/></td><td><span wicket:id="lastname"/></td>
</tr>
</table>
what we want is everything within <tr>...</tr> to repeat once for every user. so we attach listview to the tr tag.
what listview does is make its immediate children believe that their markup is that of the listview itself. so each immediate child believes that it is attached to the <tr wicket:id="listview"> tag.
we need to represent these immediate listview children with a container component, because each of these children may contain multiple children of its own, in our case the firstname/lastname labels. this is what the listitem is, its a simple WebMarkupContainer created for you so you dont have to do it everytime youself.
so we will have a listitem container created for every list item in the list that feeds the lisview. but this is not enough. each of these listitems must contain the components that represent data within it (the firstname, lastname labels that we want to add).
this is where populateitem comes in, it is called once for every listitem created and allows you to add components to it.
so the listview render process looks like this:
before each render:
clear all children
for every list item in the list:
create a ListItem webmarkupcontainer
add created ListItem as a child
call populateItem with the created ListItem container to allow users to populate it
render:
render all immediate children with own markup
does this help or confuse you more?
-Igor
On 1/23/06, Frank Silbermann < [EMAIL PROTECTED]> wrote:
Has anyone written about the way ListView works in Wicket -- i.e. thehttp://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
roles played by ListView, ListItem and the models belonging to these
components?
I've looked at the JavaDoc in the hope of gaining some intuition as to
what is going on, but I'm having "a difficult time seeing the forest
because of all the trees."
For example, I'm looking at the Component Reference examples,
specifically the RadioGroupPage. The RadioGroup object is constructed
with "new Model()" -- which leads me to ask myself "What kind of a silly
model is that?
Looking at the API documentation for RadioGroup, is says that the
group's model is "set to the model of the selected Radio component." So
I'm guessing that "new Model()" is just a filler to tell the RadioGroup
NOT to search for a ComponentModel further up the hierarchy -- this
time, the model comes from down lower in the hierarch. (If that's true,
perhaps this usage of a trivial model ought to be described somewhere in
the RadioGroup JavaDoc. Or is it a more general pattern followed by a
variety of selection components? Does the JavaDoc for the most general
abstract selection component explain this usage?)
So I look further down for the Radio objects themselves, and see that
they are created within the populateItem() method of an anonymous
subclass of ListView. Perhaps the relationship between RadioGroup and
Radio would be more easily understood via a simpler (though less
practical) example in which the set of Radio components were hardcoded
-- my vague understanding of working with Listview is getting in the
way.
As it stands, we give each Radio component the same model as one of the
ListItem components of the ListView. I presume the ListItem is built
from one of the items of the java.util.List from which the ListView was
contructed -- but how???
I suppose my next step is to look at the Wicket implementation of
ListView and ListItem to figure out what is going on.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
