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 dimensions
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 deli
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
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
> 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 dimensions of components (the fac
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
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 interf
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 movin
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 Wind
> 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 bas
...
> this into consideration with the next major API
... revision (1.5)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 y
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 classe
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
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
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 forwa
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
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
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 su
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
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 (L
...)
-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"
> poli
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 Gene
> 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 us
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
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 PROTECT
008 11:09 AM
To: users@wicket.apache.org
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) assumptio
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 (withou
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
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 12,
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 Vaynb
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
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:
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
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
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
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 subclassi
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 12-Ju
You could reduce the verbosity by combining all your dynamic content
(anything you would normally add when subclassing a component) into a
separate class. For example:
class Images
{
Callable isVisible()
{
...
}
Callable getItemsPerPage()
{
...
}
}
main()
{
DataView image
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 compositio
40 matches
Mail list logo
