a simple fact of the matter here is that datatable was not designed to show two rows per item, it is designed to show tabular data where each item is represented by a single row and a set of columns. you are trying to hack it to show two rows per item by using transparent resolvers - which were not meant to be used that way. so why should we "support" this?
furthermore, starting from scratch is not a big deal. its now like you are writing the whole thing from scratch. DataTable itself is a pretty small class ( ~300 lines with our whitespace friendly formatter ). The nice thing about Wicket is that when you rewrite DataTable you get to reuse everything that it itself builds ont, that is why the original is a small class. we can even further factor out things like toolbar container/management out of it if you would bother to create an rfe. finally, supporting this usecase is not high on our priority list. we are madly trying to finish 1.4 so we can move on to 1.5 where we can start breaking api and possibly even getting rid of the transparentresolver completely and replace it with something that works better. so i dont see why you are making such a stink about this. we've got very limited resources that we are working with here. you want something done that we dont consider a priority and is not a quickie for us to fix, provide a patch. -igor On Mon, May 12, 2008 at 2:08 AM, Jan Kriesten <[EMAIL PROTECTED]> wrote: > > 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. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
