Eclipse Community Forums: Eclipse Platform » Try to understand SWT philosophy for extensibility.

Help

Home

Home » Eclipse Projects » Eclipse Platform » Try to understand SWT philosophy for extensibility.

Show: Today's Messages :: Show Polls :: Message Navigator

Try to understand SWT philosophy for extensibility. [message #327064]

Tue, 08 April 2008 09:55

David Pérez

Messages: 228
Registered: July 2009

Senior Member

Hi,

I'm quite new in the SWT/RCP world.

Sometimes the builtin classes don't fully meet my needs. One way of
solving this kind of problems is inheritance.

Example 1:
------------

Instead of this:

TableColumn column = new TableColumn(table, SWT.LEFT);
column.setText("Cabecera");
column.setWidth(150);

I like to write this (more compact):

new TableColumn(table, SWT.LEFT).sText("Cabecera").sWidth(150);

public class TableColumn extends org.eclipse.swt.widgets.TableColumn {
protected int index;

public TableColumn(Table parent, int style) {
super(parent, style);
index = parent.getColumnCount()-1;
}

public TableColumn sText(String string) {
super.setText(string);
return this;
}

public TableColumn sWidth(int width) {
super.setWidth(width);
return this;
}

protected void checkSubclass () {
}
}

The documentation says TableColumn cannot be derived.
So, I had to also override 'checkSubclass()'.

Example 2:
------------

SWT Table only supports ordering by one column. I want to implement
multicolumn sorting.

Problem: TableColumn#setSortDirection() isn't public. It could be
protected.
Solution (None of them I like):
1- Changing source code of my private copy of SWT
2- Using AspectJ or similar
3- Use reflection to invoke non-public methods.

It's a little hard to work with a framework not designed for extensibility.
I know it's a project used by many other ones, and the public API must be
very well delimited.

Any ideas?

Report message to a moderator

Re: Try to understand SWT philosophy for extensibility. [message #327065 is a reply to message #327064]

Tue, 08 April 2008 10:29

David Pérez

Messages: 228
Registered: July 2009

Senior Member

I forgot to mention that example 1 is perfectly working, even though
inheritance is forbidden.

David Perez wrote:

> Example 1:
> ------------

> Instead of this:

> TableColumn column = new TableColumn(table, SWT.LEFT);
> column.setText("Cabecera");
> column.setWidth(150);

> I like to write this (more compact):

> new TableColumn(table, SWT.LEFT).sText("Cabecera").sWidth(150);

> public class TableColumn extends org.eclipse.swt.widgets.TableColumn {
> protected int index;

> public TableColumn(Table parent, int style) {
> super(parent, style);
> index = parent.getColumnCount()-1;
> }

> public TableColumn sText(String string) {
> super.setText(string);
> return this;
> }

> public TableColumn sWidth(int width) {
> super.setWidth(width);
> return this;
> }

> protected void checkSubclass () {
> }
> }

Report message to a moderator

Re: Try to understand SWT philosophy for extensibility. [message #327066 is a reply to message #327065]

Tue, 08 April 2008 10:41

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Well instead of subclassing you could use a Builder-Pattern:

Builder.buildTableColumn(table,SWT.LEFT).setText("Cabecera").setWidth(150);

public class Builder {
public buildTableColumnn(Table table, int style) {
return new TableColumnBuilder(new TableColumn(table,SWT.LEFT));
}
}

public class TableColumnBuilder {
private TableColumn column;

public TableColumnBuilder(TableColumn column) {
this.column = column;
}

public TableColumnBuilder setText(String text) {
this.column.setText(text);
return this;
}

public TableColumnBuilder setWidth(int width) {
this.column.setWidth(width);
return this;
}
}

You already mentionned the reason SWT says you should not subclass it
because keeping an API contract up with subclassing is even harder than
without.

Tom

David Perez schrieb:
> I forgot to mention that example 1 is perfectly working, even though
> inheritance is forbidden.
>
> David Perez wrote:
>
>
>> Example 1:
>> ------------
>
>> Instead of this:
>
>> TableColumn column = new TableColumn(table, SWT.LEFT);
>> column.setText("Cabecera");
>> column.setWidth(150);
>
>> I like to write this (more compact):
>
>> new TableColumn(table, SWT.LEFT).sText("Cabecera").sWidth(150);
>
>> public class TableColumn extends org.eclipse.swt.widgets.TableColumn {
>> protected int index;
>
>> public TableColumn(Table parent, int style) {
>> super(parent, style);
>> index = parent.getColumnCount()-1;
>> }
>
>> public TableColumn sText(String string) {
>> super.setText(string);
>> return this;
>> }
>
>> public TableColumn sWidth(int width) {
>> super.setWidth(width);
>> return this;
>> }
>
>> protected void checkSubclass () {
>> }
>> }
>
>
>

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------

Report message to a moderator

Re: Try to understand SWT philosophy for extensibility. [message #327067 is a reply to message #327066]

Tue, 08 April 2008 11:38

David Pérez

Messages: 228
Registered: July 2009

Senior Member

Thanks Tom for your explanation.

Example 1 is a bad example, but shows that subclassing isn't such a bad
practice.

Luckily, the classes aren't declared final, so subclassing is possible
without patching SWT.

Tom Schindl wrote:

> Well instead of subclassing you could use a Builder-Pattern:

> Builder.buildTableColumn(table,SWT.LEFT).setText("Cabecera").setWidth(150);

> public class Builder {
> public buildTableColumnn(Table table, int style) {
> return new TableColumnBuilder(new TableColumn(table,SWT.LEFT));
> }
> }

> public class TableColumnBuilder {
> private TableColumn column;

> public TableColumnBuilder(TableColumn column) {
> this.column = column;
> }

> public TableColumnBuilder setText(String text) {
> this.column.setText(text);
> return this;
> }

> public TableColumnBuilder setWidth(int width) {
> this.column.setWidth(width);
> return this;
> }
> }

> You already mentionned the reason SWT says you should not subclass it
> because keeping an API contract up with subclassing is even harder than
> without.

Report message to a moderator

Previous Topic:	How to embed the tabbed property view into a dialog?
Next Topic:	how eclipse.exe call startup.jar

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun Sep 22 09:31:05 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter