Hi,

I'm getting a bit frustrated concerning wicket's encapsulation + extensibility, especially when it comes to transparent resolvers.

There are a couple of nice features which are dependend on other Components. Just extending/customizing them is nearly impossible when it comes to unthought usecases.

Such usecases - when described - are turned down by statements 'You are using it in an improper way, rethink your data access model.' or 'When it comes to transparent resolvers, you are on your own - implement it from scratch without them'.

In the latter, 'implement it from scratch' has significant tradeoffs: My case is implementing a DataTable with some add-on features which need make use of an transparent resolver. The encapsulation of the contained DataGridView with DataTable leaves me no option (except doing it from scratch). If I would implement a DataTable myself, I'd have to create all Components expecting a DataTable as parameter again: That just contradics Wicket's reusable components approach.

As responsive + well supported as Wicket is (I really like that a lot - and am thankful for the work the dev team is doing) - if unthought usecases occur the team is frequently denying that such usecases are valid and wouldn't bring Wicket a step further.

I know transparent resolvers are currently a major issue and can't be really handled in a proper way due to the hierarchy concept. But if things can be fixed with a workaround (until a new transparent resolver model is established) and which has no impact on the overall functionality - why can't that make it into wicket? The 'We wont support this' dogma isn't really proper argumentation.

Best regards, --- Jan.