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