Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Extending SWT Components
| Extending SWT Components [message #448029] |
Mon, 27 December 2004 12:07  |
Eclipse User |
|
|
|
Originally posted by: maganz.zonnet.nl
Hi all,
Recently I began development of a Rich Client using SWT and JFace. The
problem is that I'd like to implement an interface with the SWT components I
use to establish compatibility with a backend framework. The API says that
subclassing a component should only be done within the SWT implementation or
it's not intended at all. My question is, what does this mean? And why
shouldn't I extend the components? Is it because of future changes in the
SWT library? What would be the best thing to do then? I've thought of
encapsulating a component object (for example Button) in a new class which
implements the previous mentioned interface, allthough subclassing is
prefered.
So, what are the do's or/and don'ts of extending SWT components?
Thanks,
Mario
|
|
|
| Re: Extending SWT Components [message #448033 is a reply to message #448029] |
Mon, 27 December 2004 22:08  |
 Daniel Spiewak
Messages: 263
Registered: July 2009 |
Senior Member |
|
|
Alright, it can be done. That's step one. The widgets (other than
Composite and Canvas) aren't intended to be extended because they are
themselves platform specific. Unlike Swing and AWT, which mirrors to a
uniform native API which does all the work, SWT calls native methods
which mirror directly to the graphics API in C that it is built on for
that platform. (these calls are found in class
org.eclipse.swt.internal.OS) Also, event handling is handled within
classes. This is different for each platform as well. But the real
kicker is the fact that even calling Button#setText(String) touches off
a whole plethora of calls to the native subsystem. Very platform
specific calls. Thus, if you extend class Button and override the
method Button#setText(String), you would override this functionality and
break the implementation. Your only hope lies in calling super.<<method
name>>(<<method params>>) at the beginning of every method. Then you
can stick your code inside. And, as a rule of thumb, only override
public methods. (actually, I don't even think there are protected
methods or fields in any of the widgets, save one). You will have to
override the protected method boolean checkSubclass() and return true.
This is how SWT checks to make sure that nothing unauthorized has
subclassed any internal class. Well, may fortune favor the foolish.
Have fun.
Daniel
Mario Ganzeboom wrote:
>Hi all,
>
>Recently I began development of a Rich Client using SWT and JFace. The
>problem is that I'd like to implement an interface with the SWT components I
>use to establish compatibility with a backend framework. The API says that
>subclassing a component should only be done within the SWT implementation or
>it's not intended at all. My question is, what does this mean? And why
>shouldn't I extend the components? Is it because of future changes in the
>SWT library? What would be the best thing to do then? I've thought of
>encapsulating a component object (for example Button) in a new class which
>implements the previous mentioned interface, allthough subclassing is
>prefered.
>So, what are the do's or/and don'ts of extending SWT components?
>
>Thanks,
>Mario
>
>
>
>
|
|
| |
| Re: Extending SWT Components [message #448052 is a reply to message #448029] |
Wed, 29 December 2004 13:03 |
| Eclipse User |
|
|
|
Originally posted by: maganz.zonnet.nl
Hi again,
I've read your answers Daniel and Liam, thanks for responding. Daniel it
seems that you strongly discourage inheritance with SWT components ;). But
at least now I know why overriding methods in these widgets is not a good
idea. The thing is I won't be overriding methods in the widget classes
whatsoever. I'm going to extend the widgets and implement my own
administrational methods through interfaces, which are going to use the
'native' methods. The 'native' methods themselves are not to be touched.
According to your answer nothing stands in the way of extending the widgets
when not touching these 'native' methods. Is this assumption correct?
Liam, you talked about Daniel prefering composition above inheritance.
That's one of my options I explained in my first message. Probably I misused
the term encapsulation for this. When using composition you have two object
instances (one of interface implementing class and one of Button for
example) and access from outside to the Button object has to be performed
through a method call returning the Button object. No direct access to the
widget methods is possible. Direct access would be easier for the
users/developers working with the future components, because the most of
them are no Java guru's and I'd like to keep it as simple as possible. You
also have a close 1 level object which methods could be called straight away
without having to plough through several levels to get to the main object.
When using inheritance, 'advanced features' of the widgets are also easy to
access. They aren't 'protected' in any kind, leaving the SWT interface
intact.
Then again I might be pulling at the wrong end. What could be said for pro
composition?
Many thanks!
Mario
"Mario Ganzeboom" <maganz@zonnet.nl> schreef in bericht
news:cqotuj$mqu$1@www.eclipse.org...
> Hi all,
>
> Recently I began development of a Rich Client using SWT and JFace. The
> problem is that I'd like to implement an interface with the SWT components
I
> use to establish compatibility with a backend framework. The API says that
> subclassing a component should only be done within the SWT implementation
or
> it's not intended at all. My question is, what does this mean? And why
> shouldn't I extend the components? Is it because of future changes in the
> SWT library? What would be the best thing to do then? I've thought of
> encapsulating a component object (for example Button) in a new class which
> implements the previous mentioned interface, allthough subclassing is
> prefered.
> So, what are the do's or/and don'ts of extending SWT components?
>
> Thanks,
> Mario
>
>
|
|
|
| Re: Extending SWT Components [message #448057 is a reply to message #448052] |
Wed, 29 December 2004 21:53 |
Liam Morley
Messages: 47
Registered: July 2009 |
Member |
|
|
I don't see how the components would be any easier to access through
inheritance seeing as how Daniel mentioned most of the internals are
private, not protected. You would have no direct access. So I'm not sure
what real advantage you'd have if any to extending it, you'd still have
to access it through its public interface.
I believe the article you read was "Writing Your Own Widget", at
http://www.eclipse.org/articles/Article-Writing%20Your%20Own %20Widget/Writing%20Your%20Own%20Widget.htm
Halfway down is a section entitled "Subclassing Widgets Directly", which
lists a number of reasons why you should avoid subclassing SWT widgets
at all costs. Any of my arguments would probably stem from the generic
javaworld article, and a few of the other issues sited... I'm just not
sure you would have any real benefite from subclassing in this condition.
Mario Ganzeboom wrote:
> Hi again,
>
> I've read your answers Daniel and Liam, thanks for responding. Daniel it
> seems that you strongly discourage inheritance with SWT components ;). But
> at least now I know why overriding methods in these widgets is not a good
> idea. The thing is I won't be overriding methods in the widget classes
> whatsoever. I'm going to extend the widgets and implement my own
> administrational methods through interfaces, which are going to use the
> 'native' methods. The 'native' methods themselves are not to be touched.
> According to your answer nothing stands in the way of extending the widgets
> when not touching these 'native' methods. Is this assumption correct?
>
> Liam, you talked about Daniel prefering composition above inheritance.
> That's one of my options I explained in my first message. Probably I misused
> the term encapsulation for this. When using composition you have two object
> instances (one of interface implementing class and one of Button for
> example) and access from outside to the Button object has to be performed
> through a method call returning the Button object. No direct access to the
> widget methods is possible. Direct access would be easier for the
> users/developers working with the future components, because the most of
> them are no Java guru's and I'd like to keep it as simple as possible. You
> also have a close 1 level object which methods could be called straight away
> without having to plough through several levels to get to the main object.
> When using inheritance, 'advanced features' of the widgets are also easy to
> access. They aren't 'protected' in any kind, leaving the SWT interface
> intact.
>
> Then again I might be pulling at the wrong end. What could be said for pro
> composition?
>
> Many thanks!
> Mario
>
> "Mario Ganzeboom" <maganz@zonnet.nl> schreef in bericht
> news:cqotuj$mqu$1@www.eclipse.org...
>
>>Hi all,
>>
>>Recently I began development of a Rich Client using SWT and JFace. The
>>problem is that I'd like to implement an interface with the SWT components
>
> I
>
>>use to establish compatibility with a backend framework. The API says that
>>subclassing a component should only be done within the SWT implementation
>
> or
>
>>it's not intended at all. My question is, what does this mean? And why
>>shouldn't I extend the components? Is it because of future changes in the
>>SWT library? What would be the best thing to do then? I've thought of
>>encapsulating a component object (for example Button) in a new class which
>>implements the previous mentioned interface, allthough subclassing is
>>prefered.
>>So, what are the do's or/and don'ts of extending SWT components?
>>
>>Thanks,
>>Mario
>>
>>
>
>
>
--
Liam Morley
Computer Science Undergraduate
Worcester Polytechnic Institute
|
|
|
| Re: Extending SWT Components [message #448059 is a reply to message #448052] |
Wed, 29 December 2004 23:58 |
Daniel Spiewak
Messages: 263
Registered: July 2009 |
Senior Member |
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="serif">The answer to your question is, yes: there really
isn't anything to stop you from subclassing as long as you avoid
touching the 'native' methods. When you say 'native', I'm assuming
that you are in reference to the actual methods such as
Button#setText(String) which are platform specific.<br>
<br>
However, that said, I have to say that I am strongly in favor of
composition. If you are worried about access to the actual Widget
being controlled, then expose it using another method or make it
public. You could also simply mirror every method in the widget peer.
However, this obviously poses problems, especially when you start to
try to deal with the List widget, which contains <i>dozens</i></font>
of methods. (I believe the exact number is somewhere around thirty)
Not exactly hard, conceptual programming, but definitely grunt work.
Anyway, I hope you have what you were looking for. Happy coding...<br>
<br>
Daniel<br>
<br>
Mario Ganzeboom wrote:
<blockquote cite="midcqu9v9$32g$1@www.eclipse.org" type="cite">
<pre wrap="">Hi again,
I've read your answers Daniel and Liam, thanks for responding. Daniel it
seems that you strongly discourage inheritance with SWT components ;). But
at least now I know why overriding methods in these widgets is not a good
idea. The thing is I won't be overriding methods in the widget classes
whatsoever. I'm going to extend the widgets and implement my own
administrational methods through interfaces, which are going to use the
'native' methods. The 'native' methods themselves are not to be touched.
According to your answer nothing stands in the way of extending the widgets
when not touching these 'native' methods. Is this assumption correct?
Liam, you talked about Daniel prefering composition above inheritance.
That's one of my options I explained in my first message. Probably I misused
the term encapsulation for this. When using composition you have two object
instances (one of interface implementing class and one of Button for
example) and access from outside to the Button object has to be performed
through a method call returning the Button object. No direct access to the
widget methods is possible. Direct access would be easier for the
users/developers working with the future components, because the most of
them are no Java guru's and I'd like to keep it as simple as possible. You
also have a close 1 level object which methods could be called straight away
without having to plough through several levels to get to the main object.
When using inheritance, 'advanced features' of the widgets are also easy to
access. They aren't 'protected' in any kind, leaving the SWT interface
intact.
Then again I might be pulling at the wrong end. What could be said for pro
composition?
Many thanks!
Mario
"Mario Ganzeboom" <a class="moz-txt-link-rfc2396E" href="mailto:maganz@zonnet.nl"><maganz@zonnet.nl></a> schreef in bericht
<a class="moz-txt-link-freetext" href="news:cqotuj$mqu$1@www.eclipse.org">news:cqotuj$mqu$1@www.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
Recently I began development of a Rich Client using SWT and JFace. The
problem is that I'd like to implement an interface with the SWT components
</pre>
</blockquote>
<pre wrap=""><!---->I
</pre>
<blockquote type="cite">
<pre wrap="">use to establish compatibility with a backend framework. The API says that
subclassing a component should only be done within the SWT implementation
</pre>
</blockquote>
<pre wrap=""><!---->or
</pre>
<blockquote type="cite">
<pre wrap="">it's not intended at all. My question is, what does this mean? And why
shouldn't I extend the components? Is it because of future changes in the
SWT library? What would be the best thing to do then? I've thought of
encapsulating a component object (for example Button) in a new class which
implements the previous mentioned interface, allthough subclassing is
prefered.
So, what are the do's or/and don'ts of extending SWT components?
Thanks,
Mario
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
|
|
|
| Re: Extending SWT Components [message #448092 is a reply to message #448057] |
Fri, 31 December 2004 08:22 |
| Eclipse User |
|
|
|
Originally posted by: maganz.zonnet.nl
Thanks for showing me the article "Writing Your Own Widget". I hadn't read
it yet, including the referenced java world article. Now I have a few
guidelines on when to use inheritance and when to use composition. Allthough
I thought using inheritance would be better in my case I'm going to use
composition. My aim was to decrease the load that has to be processed as
much as possible, but that aim isn't really necessary. You see, the rich
client will be connected through a framework to an application server.
Currently a web browser connected to a web server (which delegates requests
to the application server) is used only. With that setup, performance is
very important. A rich client however resides on the client machine and
could pack quite a punch if I may put it that way. Performance doesn't have
to be at the top of the priority list. Which leaves room for a sturdy and
solid design without having certain 'hacks' to increase performance.
Many thanks for the feedback Liam and Daniel!
Mario
"Liam Morley" <lmorley@wpi.edu> schreef in bericht
news:cqv90c$1ss$1@www.eclipse.org...
> I don't see how the components would be any easier to access through
> inheritance seeing as how Daniel mentioned most of the internals are
> private, not protected. You would have no direct access. So I'm not sure
> what real advantage you'd have if any to extending it, you'd still have
> to access it through its public interface.
>
> I believe the article you read was "Writing Your Own Widget", at
>
http://www.eclipse.org/articles/Article-Writing%20Your%20Own %20Widget/Writing%20Your%20Own%20Widget.htm
> Halfway down is a section entitled "Subclassing Widgets Directly", which
> lists a number of reasons why you should avoid subclassing SWT widgets
> at all costs. Any of my arguments would probably stem from the generic
> javaworld article, and a few of the other issues sited... I'm just not
> sure you would have any real benefite from subclassing in this condition.
>
>
> Mario Ganzeboom wrote:
> > Hi again,
> >
> > I've read your answers Daniel and Liam, thanks for responding. Daniel it
> > seems that you strongly discourage inheritance with SWT components ;).
But
> > at least now I know why overriding methods in these widgets is not a
good
> > idea. The thing is I won't be overriding methods in the widget classes
> > whatsoever. I'm going to extend the widgets and implement my own
> > administrational methods through interfaces, which are going to use the
> > 'native' methods. The 'native' methods themselves are not to be touched.
> > According to your answer nothing stands in the way of extending the
widgets
> > when not touching these 'native' methods. Is this assumption correct?
> >
> > Liam, you talked about Daniel prefering composition above inheritance.
> > That's one of my options I explained in my first message. Probably I
misused
> > the term encapsulation for this. When using composition you have two
object
> > instances (one of interface implementing class and one of Button for
> > example) and access from outside to the Button object has to be
performed
> > through a method call returning the Button object. No direct access to
the
> > widget methods is possible. Direct access would be easier for the
> > users/developers working with the future components, because the most of
> > them are no Java guru's and I'd like to keep it as simple as possible.
You
> > also have a close 1 level object which methods could be called straight
away
> > without having to plough through several levels to get to the main
object.
> > When using inheritance, 'advanced features' of the widgets are also easy
to
> > access. They aren't 'protected' in any kind, leaving the SWT interface
> > intact.
> >
> > Then again I might be pulling at the wrong end. What could be said for
pro
> > composition?
> >
> > Many thanks!
> > Mario
> >
> > "Mario Ganzeboom" <maganz@zonnet.nl> schreef in bericht
> > news:cqotuj$mqu$1@www.eclipse.org...
> >
> >>Hi all,
> >>
> >>Recently I began development of a Rich Client using SWT and JFace. The
> >>problem is that I'd like to implement an interface with the SWT
components
> >
> > I
> >
> >>use to establish compatibility with a backend framework. The API says
that
> >>subclassing a component should only be done within the SWT
implementation
> >
> > or
> >
> >>it's not intended at all. My question is, what does this mean? And why
> >>shouldn't I extend the components? Is it because of future changes in
the
> >>SWT library? What would be the best thing to do then? I've thought of
> >>encapsulating a component object (for example Button) in a new class
which
> >>implements the previous mentioned interface, allthough subclassing is
> >>prefered.
> >>So, what are the do's or/and don'ts of extending SWT components?
> >>
> >>Thanks,
> >>Mario
> >>
> >>
> >
> >
> >
>
>
> --
> Liam Morley
> Computer Science Undergraduate
> Worcester Polytechnic Institute
|
|
|
Goto Forum:
Current Time: Fri Apr 26 12:50:03 GMT 2024
Powered by FUDForum. Page generated in 0.03780 seconds |
] 
Search
Help
Register
Login
Home
