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]
