20 messages in org.apache.wicket.usersRe: encapsulation, extension and tran...| From | Sent On | Attachments |
|---|---|---|
| Jan Kriesten | May 12, 2008 2:08 am | |
| Martijn Dashorst | May 12, 2008 4:07 am | |
| Jan Kriesten | May 12, 2008 5:28 am | |
| Martijn Dashorst | May 12, 2008 5:34 am | |
| Jan Kriesten | May 12, 2008 5:39 am | |
| Igor Vaynberg | May 12, 2008 8:25 am | |
| Johan Compagner | May 12, 2008 8:34 am | |
| Jan Kriesten | May 12, 2008 9:14 am | |
| Jan Kriesten | May 12, 2008 9:17 am | |
| Igor Vaynberg | May 12, 2008 10:12 am | |
| Jan Kriesten | May 12, 2008 10:25 am | |
| Igor Vaynberg | May 12, 2008 10:31 am | |
| Gerolf Seitz | May 12, 2008 3:00 pm | |
| Johan Compagner | May 12, 2008 3:19 pm | |
| jWeekend | May 12, 2008 4:59 pm | |
| Jonathan Locke | May 12, 2008 6:24 pm | |
| Jonathan Locke | May 12, 2008 6:36 pm | |
| Eelco Hillenius | May 12, 2008 6:51 pm | |
| Jan Kriesten | May 12, 2008 9:44 pm | |
| Jonathan Locke | May 12, 2008 10:52 pm |
| Subject: | Re: encapsulation, extension and transparent resolvers | |
|---|---|---|
| From: | Jonathan Locke (jona...@gmail.com) | |
| Date: | May 12, 2008 6:36:13 pm | |
| List: | org.apache.wicket.users | |
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.
Jonathan Locke wrote:
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.
--
View this message in context:
http://www.nabble.com/encapsulation%2C-extension-and-transparent-resolvers-tp17183817p17199433.html
Sent from the Wicket - User mailing list archive at Nabble.com.