Or with qi4j (http://qi4j.org)
Martijn
On Sat, Jun 14, 2008 at 5:37 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
It's good to know that when you reach the same conclusion it is a deliberate
one.
BTW, interfaces are useful for this, but not a necessity. Or am I the only
one thinking that
Hmm... (As an aside, I wonder if they mean pray in the jungle or prey in
the jungle? :-))
/Gwyn
On Sat, Jun 14, 2008 at 8:23 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
Or with qi4j (http://qi4j.org)
Martijn
On Sat, Jun 14, 2008 at 5:37 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
Ah, you beat me to that. I should've read the thread entirely before
posting :)
Martijn Dashorst wrote:
Or with qi4j (http://qi4j.org)
Martijn
On Sat, Jun 14, 2008 at 5:37 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
It's good to know that when you reach the same conclusion it is a
Eelco Hillenius wrote:
It's good to know that when you reach the same conclusion it is a deliberate
one.
BTW, interfaces are useful for this, but not a necessity. Or am I the only
one thinking that
No, I agree with you mostly. However, I was trying (back then) to
define separate
I am not aware of a distinction between software decorator and ui
decorator. But seeing as wicket is a ui framework, I'll go with ui
decorator. Border looks somewhat like a decorator, but since it does not
wrap another component, it is not. Also Border needs different markup
than the component
On Fri, Jun 13, 2008 at 2:44 PM, Matthijs Wensveen [EMAIL PROTECTED] wrote:
By the way, the article I supplied and the article on wikipedia do just the
same thing. If you look at VerticalScrollBarDecorator.draw you'll see that
it delegates the method to the wrapped Window.
decorator classes in
On Thu, Jun 12, 2008 at 2:06 PM, Matthijs Wensveen [EMAIL PROTECTED] wrote:
Some useful design patterns like Decorator don't work with final methods.
Wicket components sometimes have overridable factory methods for child
components. The decorator pattern could be very useful here, because you'd
...
this into consideration with the next major API
... revision (1.5)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
True, it's been weighing the disadvantages vs the advantages, and so
far, ensuring that we wouldn't paint ourselves in the corner too
quickly won over flexibility.
To make this 'painless' though, we'd probably need a whole bunch of
interfaces. We've looked into moving to a more interface based
Igor Vaynberg wrote:
On Fri, Jun 13, 2008 at 2:44 PM, Matthijs Wensveen [EMAIL PROTECTED] wrote:
By the way, the article I supplied and the article on wikipedia do just the
same thing. If you look at VerticalScrollBarDecorator.draw you'll see that
it delegates the method to the wrapped
Eelco Hillenius wrote:
True, it's been weighing the disadvantages vs the advantages, and so
far, ensuring that we wouldn't paint ourselves in the corner too
quickly won over flexibility.
To make this 'painless' though, we'd probably need a whole bunch of
interfaces. We've looked into
On Fri, Jun 13, 2008 at 7:02 PM, Matthijs Wensveen [EMAIL PROTECTED] wrote:
It's good to know that when you reach the same conclusion it is a deliberate
one.
BTW, interfaces are useful for this, but not a necessity. Or am I the only
one thinking that (I seem to be... hmm...). More interfaces
LOL.
-igor
On 6/13/08, James Carman [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 7:02 PM, Matthijs Wensveen [EMAIL PROTECTED]
wrote:
It's good to know that when you reach the same conclusion it is a
deliberate
one.
BTW, interfaces are useful for this, but not a necessity. Or am I the
Apart from the fact that this would be even more verbose than current
generics approach this would probably also radically increase
component memory footprint.
-Matej
On Thu, Jun 12, 2008 at 7:03 AM, cowwoc [EMAIL PROTECTED] wrote:
Have you considered moving from subclassing to composition in
on removing the finals
The final members are the worst thing I've had to deal with in Wicket
so far.
Although I understand that there may be a reason for them, they are
more a hinderance than anything else and seem to be trying to protect
users from themselves.
- Brill Pappin
On
Brill,
This is actually an API best practice. Classes fall into two categories:
ones designed for subclassing, and ones designed to be final. The same goes
for methods. Swing is full of examples of what goes wrong when people
override methods in classes that haven't been designed with
I understand the reasoning, however I think best practice can be
debated.
To use your example Swing allows the user to override quite a bit, and
it doesn't make any (or very few) assumptions on what should and
should not be done.
I don't like API's that assume I'm an idiot and prevent me
On Thu, Jun 12, 2008 at 11:08 AM, Brill Pappin [EMAIL PROTECTED] wrote:
I understand the reasoning, however I think best practice can be debated.
To use your example Swing allows the user to override quite a bit, and it
doesn't make any (or very few) assumptions on what should and should not be
Without the use of final wicket would not have made it this far.
Martijn
On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED] wrote:
I understand the reasoning, however I think best practice can be debated.
To use your example Swing allows the user to override quite a bit, and it
indeed. i wouldnt mind if final was the default in java :)
-igor
On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
Without the use of final wicket would not have made it this far.
Martijn
On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED] wrote:
I
You mean like C++?
On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
indeed. i wouldnt mind if final was the default in java :)
-igor
On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
Without the use of final wicket would not have made it
i mean generally, for methods, fields, and func args :) most of this
stuff can stay final, but people dont bother doing it because its
extra typing.
-igor
On Thu, Jun 12, 2008 at 8:38 AM, James Carman
[EMAIL PROTECTED] wrote:
You mean like C++?
On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg
That's funny. By default I make every local variable final if I can.
I guess it's just out of habit. I usually do the same for method
parameters, too (I'm less diligent about that one). For methods, I
usually just leave them be until I know for sure that I need them to
be final.
On Thu, Jun
to be overridden. So either deprecate and start over
or risk breaking client code and have your users hate you for it :)
-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 12, 2008 11:09 AM
To: users@wicket.apache.org
Subject: Re: Making Component easier to Generify
I
Actually, it's the other way around. Authors make methods final not because
*you* might make a mistake but rather because *they* might. Using final
methods simplifies their design a lot because they don't have to do all the
work you mentioned. Secondly, it leaves the API open to extension
Subject: Re: Making Component easier to Generify
I understand the reasoning, however I think best practice can be
debated.
To use your example Swing allows the user to override quite a bit, and
it doesn't make any (or very few) assumptions on what should and
should not be done.
I don't like API's
Very thoughtful and some good points, I don't entirely disagree with
that.
- Brill
On 12-Jun-08, at 11:54 AM, cowwoc wrote:
[...]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
If you override a method and your implementation violates the Liskov
Substitution Principle, then it's your fault! :)
On Thu, Jun 12, 2008 at 11:54 AM, cowwoc [EMAIL PROTECTED] wrote:
Actually, it's the other way around. Authors make methods final not because
*you* might make a mistake but
However, I am *in no way asking* the developers to reverse the final
policy.
We actually relaxed that way more as we felt more confident about
Wicket's API and as motivated requests came in. Personally, I think
using final or not should be a deliberate choice (not automatic). If
you never use
everything to be overridden. So either deprecate and start over
or risk breaking client code and have your users hate you for it :)
-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 12, 2008 11:09 AM
To: users@wicket.apache.org
Subject: Re: Making Component
...)
-Original Message-
From: Eelco Hillenius [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 12, 2008 12:51 PM
To: users@wicket.apache.org
Subject: Re: Making Component easier to Generify
However, I am *in no way asking* the developers to reverse the final
policy.
We actually relaxed
Some useful design patterns like Decorator don't work with final
methods. Wicket components sometimes have overridable factory methods
for child components. The decorator pattern could be very useful here,
because you'd be able to decorate the original component with some extra
functionality
decorators only work with interfaces, component class is not. This is
part of the reason why we have behaviors
-igor
On 6/12/08, Matthijs Wensveen [EMAIL PROTECTED] wrote:
Some useful design patterns like Decorator don't work with final
methods. Wicket components sometimes have overridable
Why would the decorator design pattern only work with interfaces? Maybe
we're talking about two different this here? (I'm talking about this
one: http://en.wikipedia.org/wiki/Decorator_pattern)
I can see why behaviors were introduced. A simple example: a factory
method creates a link. In my
look at the java example. notice Window is an interface.
eg you cant do: add(new DecoratedComponent(someOtherComponent));
-igor
On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen [EMAIL PROTECTED] wrote:
Why would the decorator design pattern only work with interfaces? Maybe
we're talking
Igor Vaynberg wrote:
look at the java example. notice Window is an interface.
Yeah, but that's just because it's good practice to use the interface
when there is one. Notice that the actually decorated class is a new
SimpleWindow() in DecoratedWindowTest. Window might as well have been an
right. so when you would do it with a class you will actually have to
rewire all the methods to forward to the delegate instead of calling
super. that is pure insanity and does not make any sense when methods
hold logic. that is why it works with an interface, no logic for you
to override and
looked over the article. what they do is a ui decorator, it is not the
software decorator pattern. there is no method delegation to the child
component. what they create is a composite, you can do the same thing
in wicket with a Border.
-igor
On Thu, Jun 12, 2008 at 9:55 PM, Igor Vaynberg [EMAIL
Have you considered moving from subclassing to composition in Wicket using
CallableT?
Currently it is quite common for developers to subclass a component in order
to override isVisible() and other properties. I am proposing that instead
the component classes become final and properties may only
39 matches
Mail list logo
