Re: encapsulation, extension and transparent resolvers
On 5/12/08, Jan Kriesten [EMAIL PROTECTED] wrote: The 'We wont support this' dogma isn't really proper argumentation. Are you providing the 24x7 free support then? Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
hi martijn, The 'We wont support this' dogma isn't really proper argumentation. Are you providing the 24x7 free support then? that's actually not the point, is it? i'm trying to help out on the irc channel as well as good as i can. so you can't claim that all yourself. just get back to serious discussion and don't hide behind this statement you're repeating over and over. as i stated, i really appreciate your work - but that doesn't mean one isn't allowed to formulate (light) criticism. regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
On 5/12/08, Jan Kriesten [EMAIL PROTECTED] wrote: The 'We wont support this' dogma isn't really proper argumentation. Are you providing the 24x7 free support then? that's actually not the point, is it? i'm trying to help out on the irc channel as well as good as i can. so you can't claim that all yourself. I don't do that. I pose that it is very easy to say that feature X must be implemented when you don't have to do anything yourself in supporting feature X. just get back to serious discussion and don't hide behind this statement you're repeating over and over. It is a matter of fact: should we support this or not. Support takes time and effort. Failing to acknowledge that and telling us that valuing our own time and effort is not an argument is a serious disrespect IMO. as i stated, i really appreciate your work - but that doesn't mean one isn't allowed to formulate (light) criticism. Criticism is fine, but disregarding a valid argument because you don't have to maintain it yourself is not. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
hi martijn, I don't do that. I pose that it is very easy to say that feature X must be implemented when you don't have to do anything yourself in supporting feature X. i don't want a new feature. the point is wicket's implementation of transparent resolvers has it's troubles making it hard to use it to implement extension to (default) components (due to encapsulation). all i ask is to get a workaround until there might be a new implementation of how transparent resolvers work. It is a matter of fact: should we support this or not. as i said, it's not a question of to support it, it's a matter of 'we can't fix it atm, but there's a way we could fix a problem for now'... regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
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]
Re: encapsulation, extension and transparent resolvers
A whole story about bladiabla, but what is now the actual problem?? Why do you need transparant resolvers and why dont they work for you ? On 5/12/08, Jan Kriesten [EMAIL PROTECTED] wrote: hi martijn, I don't do that. I pose that it is very easy to say that feature X must be implemented when you don't have to do anything yourself in supporting feature X. i don't want a new feature. the point is wicket's implementation of transparent resolvers has it's troubles making it hard to use it to implement extension to (default) components (due to encapsulation). all i ask is to get a workaround until there might be a new implementation of how transparent resolvers work. It is a matter of fact: should we support this or not. as i said, it's not a question of to support it, it's a matter of 'we can't fix it atm, but there's a way we could fix a problem for now'... 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]
Re: encapsulation, extension and transparent resolvers
hi igor, you want something done that we dont consider a priority and is not a quickie for us to fix, provide a patch. hello? if you'd taken a look at the jira, you'd seen that there _is_ a patch. [1] my issues are surely not high priority for you - you're not affected by them, so i can understand. but since there _is_ a workaround which can be applied - why not doing so? i've taken a look at the datatable, sure it's not big. the point is, i can't just replace datatable but would have to go all the way down to the AbstractDataGridView. also - all components like navigation + toolbars would have to be implemented as well... i'm not hacking, i'm using what wicket has got. in this case wicket's 'has got' isn't working. i know about that, i can live with that - when i'm able to work around those issues. and i can't at the moment cause i can't replace MarkupFragmentFinder programatically. if i could do so i would happily replace that and all would be fine... best regards, --- jan. [1] https://issues.apache.org/jira/browse/WICKET-1560 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
hi johan, A whole story about bladiabla, but what is now the actual problem?? Why do you need transparant resolvers and why dont they work for you ? https://issues.apache.org/jira/browse/WICKET-1560 best regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
hi igor, so i am a little confused as to why we are talking about transparent resolvers, and why gerolf did not apply that code himself... i tried to verify whether or not is related to the transparent resolver - it seems at last it's connected to them cause i couldn't produce a case where it happens without them. (though i can't claim it can't happen) maybe gerolf didn't want to step into ground where others may have more insight - that's the reason i filed this to jira. personally i do not like to change code if it maybe helps, it helps, so it's not 'maybe' in this case. especially if it is markup parsing code which is a pretty fragile area in wicket. right, i very well understand - this has to be carefully reasoned. i didn't find any problems with this workaround with my code yet - a test on a second codebase would be helpful though. if there are no objections i will ask gerolf to apply this patch (and remove it again should there be evidence that it breaks anything on another project). hopefully there will be another way with 1.5 to cope with transparent resolvers so this only is a matter of time 'til wicket is more robust on those use cases. best regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
too bad you did not maintain the jira issue properly. maybe now you have a taste of what its like, but try it for hundreds of issues. -igor On Mon, May 12, 2008 at 10:26 AM, Jan Kriesten [EMAIL PROTECTED] wrote: hi igor, so i am a little confused as to why we are talking about transparent resolvers, and why gerolf did not apply that code himself... i tried to verify whether or not is related to the transparent resolver - it seems at last it's connected to them cause i couldn't produce a case where it happens without them. (though i can't claim it can't happen) maybe gerolf didn't want to step into ground where others may have more insight - that's the reason i filed this to jira. personally i do not like to change code if it maybe helps, it helps, so it's not 'maybe' in this case. especially if it is markup parsing code which is a pretty fragile area in wicket. right, i very well understand - this has to be carefully reasoned. i didn't find any problems with this workaround with my code yet - a test on a second codebase would be helpful though. if there are no objections i will ask gerolf to apply this patch (and remove it again should there be evidence that it breaks anything on another project). hopefully there will be another way with 1.5 to cope with transparent resolvers so this only is a matter of time 'til wicket is more robust on those use cases. 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]
Re: encapsulation, extension and transparent resolvers
On Mon, May 12, 2008 at 7:26 PM, Jan Kriesten [EMAIL PROTECTED] wrote: maybe gerolf didn't want to step into ground where others may have more insight - that's the reason i filed this to jira. correct. also, because of what igor said: especially if it is markup parsing code which is a pretty fragile area in wicket. i applied it o 1.4.x, since that's the version jan would like to see fixed. should 1.3.x and 1.4.x be in sync regarding this issue? Gerolf
Re: encapsulation, extension and transparent resolvers
Does it break api? Or is it dangerous on some level? Can it break running code? On 5/13/08, Gerolf Seitz [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 7:26 PM, Jan Kriesten [EMAIL PROTECTED] wrote: maybe gerolf didn't want to step into ground where others may have more insight - that's the reason i filed this to jira. correct. also, because of what igor said: especially if it is markup parsing code which is a pretty fragile area in wicket. i applied it o 1.4.x, since that's the version jan would like to see fixed. should 1.3.x and 1.4.x be in sync regarding this issue? Gerolf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
yeah, i feel that the original statement is most readily interpreted as some form of bullying being levied against a team of volunteers. i don't think that's too cool and the core team has every right to resist that sort of pressure, particularly since their mission is to ensure minimal, clean solutions to everyone's problems (for free no less). i doubt if the offense was thoughtfully intended, but i still think an apology would be a good step here. jWeekend wrote: Making such general and potentially misleading comments on a public forum is not always the easiest way to get a *specific* problem you are faced with get addressed. If you are lucky enough to spend time on the Wicket IRC, based on my experience to date, the good people there would address such issues for you (with sound, reasoned logic explaining why things are as they are, or by gratefully acknowledging that you have found a way to improve things if that is the case) before frustration reaches levels that generate such sweeping statements about Wicket in general. Anyway, I hope you get to a solution you are happy with; I find Johan's response below (bladiabla etc) typical of the core-developer's pragmatism and no-nonsense desire to get to the crux of the matter and help people using this excellent framework they have given us and that they continue to dedicate their time to improve it and support a healthy and growing user base. Regards - Cemal http://jWeekend.co.uk http://jWeekend.co.uk Jan Kriesten 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] -- View this message in context: http://www.nabble.com/encapsulation%2C-extension-and-transparent-resolvers-tp17183817p17199343.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
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. Sorry you're feeling frustrated. However, the we won't support this is directly related to our limited time. Even workarounds have to be evaluated, and evaluating patched typically takes (me at least) between an hour up to a whole evening. It won't be the first time a workaround opens up a can of worms no-one imagined before implementing it. In fact, as far as *I* am concerned, those resolvers are very workaround-ish, and opened up the door for more requests we didn't intend. In the end, we are the little dictators of our project, and sometimes (unfortunately for you in this case) that means that we just say no to stuff, even if it seems unreasonable. :-) In the end, if you really feel it is important, you can patch a project yourself - which once upon a time wasn't crazy at all -, and you can leave the JIRA issue open in case someone at some point gets inspiration to work on it. Cheers, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: encapsulation, extension and transparent resolvers
i was not deeply offended. just a bit annoyed, but i thought i'd jump in and explain that i understood why this thread went a bit awry. i also didn't expect any of this was intentional (on either side). in any case i appreciate your apology and expect whichever of us may have snapped at you probably feel the same. i certainly apologize if i offended as well. Jan Kriesten wrote: hi jonathan, i do also think there were also some over-sensitive reactions to the unfortunately worded start of this thread. mutual apologies would be even better. it definitly wasn't intended as a personal offence to any of the wicket team. please take my apologies if you should have been offended by my statements. as i already stated to igor on irc - your personal problems are always the most pressing, and not seeing the light at the end of the tunnel can be frustrating. i really like wicket and it's team - the support i get is unmatched to any other software i have used so far. please keep up the good work - again, my apoligies. best regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/encapsulation%2C-extension-and-transparent-resolvers-tp17183817p17201558.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
