2006/4/3, Igor Vaynberg <[EMAIL PROTECTED]>:
any container can implement the interface afaik.
-Igor
On 4/3/06, Arto Arffman <[EMAIL PROTECTED] > wrote:Heh, wicket is getting too big for me...Can I extend a Panel also?/arto
2006/4/3, Igor Vaynberg <[EMAIL PROTECTED]>:not sure your patch is necessary. you can probably do the same with:
DynamicMarkupContainer extends MarkupContainer implements IComponentResolver {
.......
-Igor
On 4/3/06, Arto Arffman <[EMAIL PROTECTED] > wrote:Hi,Probably this has been discussed before, but couldn't find those threads.The idea is that MarkupContainer could create components dynamically based on wicket:ids given in html-templates if there is no explicitly created component. This could be done by calling a method (for example getDynamicComponent(String id)) if there is no component found.This would make it possible to create pages and/or panels that do some magical things. For example you could make PojoPanel that takes an object in constructor. In getDynamicComponent() it would return a new label with PropertyModel that uses the pojo's property with same name as id. Same strategy could be applied to more advanced things like editors that use reflection to determine the type of the component.@Override
protected Component getDynamicComponent(String id) {
return new Label(id, new PropertyModel(pojo, id));
}
I'm not a big fan of "magical" stuff, except when prototyping. The beauty of this approach is that you can replace all the magic later on by creating "real" components in the constructor. It would be a great time saver when designing the first versions (is this what you want - approach).I liked this idea so much that I made a try out to see if this is possible at all. I've attached the patch that contains the needed change to MarkupContainer. Of course it may cause all kinds of trouble, but it gives a clue of what I'm talking about.So, shoot it down.../arto