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.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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-tp17183817p17199433.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]
