[Wicket-user] Wicket design questions

[Aaron Hiniker]

I am just curious,

Why was it chosen to pass the ID to the constructor of a component vs the add() method of the container??

ie: 

// doesn't this make the MyComponent code less-cohesive to the heirarchy?
container.add( myComponentID, new MyComponent( new MyModel() ) ); 

This seems cleaner to me as the component should not need to be aware of how it's being wired to the heirarchy, and passing the id to the constructor now requires us to construct all of our components with an ID, when the ID is only used (from the end-user's point-of-view) in referencing the component within the heirarchy. Having to implement default constructors to satisfy the ID gets tedious.. and then when you start to nest components together, you end up hitting walls (well, I have since I'm new to Wicket):



//*** component A ***//

wicket:panel
 span wicket:id=listOfB
 Here is a ComponentB: span wicket:id=componentB/br/
 /span
/wicket:panel


ComponentA extends Panel
{
 public ComponentA( String id, List ComponentB  list )
 {
	super( id );
	add( new ListView( listOfB, list ) )
	{
 	public void populateItem( ListItem item )
		{
			item.add( (Component)item.getModelObject() );
		}
	}
 ... 
 }
}



//*** component B ***//

wicket:panel
	This is a component!
/wicket:panel

ComponentB extends Panel
{
 public ComponentB( String id )
 {
 super( id );
 }
}


Now, to wire it all together: we would do:


// MyPage //

ComponentB[] components = new ComponentB[] { new ComponentB( componentB ), new ComponentB( componentB ) };
ComponentA compA = new ComponentA( componentA, Arrays.toList( components ) );
add( compA );





As you can see, if build your components in this manner (passing components to another component), you must make sure you get the ID name correct, when really ComponentB should be wired into the heirarchy by ComponentA. 
You *could* hardcode super( componentB ) into ComponentB's constructor, but now if you want to use ComponentB somewhere else, you are forced to use componentB in your markup.

Using a different technique, we could do this:





//*** component A ***//

wicket:panel
 span wicket:id=listOfB
 Here is a ComponentB: span wicket:id=componentB/
 /span
/wicket:panel


ComponentA extends Panel
{
 public ComponentA( List ComponentB  list )
 {
	add( listOfB, new ListView( list ) )
	{
 	public void populateItem( ListItem item )
		{
			item.add( componentB, (Component)item.getModelObject() );
		}
	}
 ... 
 }
}




//*** component B ***//

wicket:panel
	This is a component!
/wicket:panel

ComponentB extends Panel
{
 // we don't need to call the default constructor anymore!! (unless we want to pass IModel)
}


Now, to wire it all together: we would do:


//*** MyPage //

ComponentB[] components = new ComponentB[] { new ComponentB(), new ComponentB() };
ComponentA compA = new ComponentA( Arrays.toList( components ) );
add( componentA, compA );



So am I even approaching this problem correctly? Is there good reason to construct components with an ID rather than specify the ID in container.add() ??

Re: [Wicket-user] Wicket design questions

[Igor Vaynberg]

you are not approaching the problem properly, at least not from compositing perspective. you would not create arrays of components to populate the listview, you would forward the listview's abstract callback to the panel, after all what if the listview is pageable?
abstract ComponentA extends Panel{ public ComponentA( String id ) {	super( id );	add( new ListView( listOfB, list ) )	{
 	public void populateItem( ListItem item )		{			populateMyItem(item, componentB);		}	} ...  }
protected abstract populateMyItem(ListItem item, String componentId);}ComponentA a=new ComponentA(a) {
 populateMyItem(ListItem item, String componentId) { add(new ComponentB(componentId));
 }};
add(a);in 1.3 we will remove the add() call and require the parent in the constructor next to id instead - might seem even more inconvinient from your pov. this will give us a lot more features such as:
components will have access to their attributes/markup in the constructorline precise errors for hierarchy inconsistencies at component creation time instead of render timeand a lot more, there was a long discussion on this or the devel list a while back if you want to dig around.
-Igor