You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Jan Kriesten <ja...@renitence.de> on 2008/05/12 11:08:41 UTC
encapsulation, extension and transparent resolvers
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Jan Kriesten <ja...@renitence.de>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Johan Compagner <jc...@gmail.com>.
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 <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Jan Kriesten <ja...@renitence.de>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Martijn Dashorst <ma...@gmail.com>.
On 5/12/08, Jan Kriesten <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Jan Kriesten <ja...@renitence.de>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Martijn Dashorst <ma...@gmail.com>.
On 5/12/08, Jan Kriesten <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Johan Compagner <jc...@gmail.com>.
Does it break api?
Or is it dangerous on some level? Can it break running code?
On 5/13/08, Gerolf Seitz <ge...@gmail.com> wrote:
> On Mon, May 12, 2008 at 7:26 PM, Jan Kriesten <ja...@renitence.de>
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Gerolf Seitz <ge...@gmail.com>.
On Mon, May 12, 2008 at 7:26 PM, Jan Kriesten <ja...@renitence.de>
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
Posted by Jan Kriesten <ja...@renitence.de>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Igor Vaynberg <ig...@gmail.com>.
ive seen the issue, and your comment on it:
"Jan Kriesten - 23/Apr/08 01:21 AM Just realized: Maybe it doesn't has
to do anything with transparent resolvers at all but only with nested
repeaters and adding cells from the innermost."
so i am a little confused as to why we are talking about transparent
resolvers, and why gerolf did not apply that code himself...
personally i do not like to change code if it "maybe" helps,
especially if it is markup parsing code which is a pretty fragile area
in wicket.
-igor
On Mon, May 12, 2008 at 9:14 AM, Jan Kriesten <ja...@renitence.de> wrote:
>
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Jan Kriesten <ja...@renitence.de>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ja...@renitence.de> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Jonathan Locke <jo...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Jan Kriesten <ja...@renitence.de>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Jonathan Locke <jo...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by Jonathan Locke <jo...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: encapsulation, extension and transparent resolvers
Posted by jWeekend <jw...@cabouge.com>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org