Thanks Igor and I am curious. Why is it nasty in your opinion? Which parts? I
am open to trying other ways that I am not aware of. This is not how I
originally wanted to implement it but I have tried many ways so far
(different models on different components in the hierarchy,
nesting/inheriting
One thing that I'm wondering is why you declare your components as
member variables. It's not really wrong, but it's more code without
any advantage, and potentially scope creep (in that you might be
tempted to use the components directly rather then to work through
models.
Eelco
On 5/3/07, John
The drop down list does not directly relate to the form model (as the visible
value is a user readable summary not the data structure I need) and so I
need to keep a reference to something even if its a model or two. Take a
look at this version which still works with same quirks.. Any better?
Yeah, looks better to me. As a matter of good practice (imho), you
could probably make the form a static internal class and make the
members private instead of package private. Though that's just taste I
guess. :)
Eelco
On 5/3/07, John RDF [EMAIL PROTECTED] wrote:
The drop down list does not
that looks much much better.
you can still get rid of those two models for the dropdownlist with:
private AddressEntry quickAddress;
Private ListAddressEntry quickAddresses=new
ArrayListAddressEntry();
and then
add(new DropDownChoice(id, new PropertyModel(this, quickAddress), new
I am still having real trouble making truly reusable panels for domain
objects that work consistently without quirky behaviour.
I attach my code for an address panel. It contains a form as it has buttons
for looking up streets from the postcode. This panel needs to be embedded
with multiple
although that is some nasty code wrt to wicket, i dont see why anything
would go wrong. try and replicate it in a quickstart and someone will go
through it.
-igor
On 5/2/07, John RDF [EMAIL PROTECTED] wrote:
I am still having real trouble making truly reusable panels for domain
objects that
