Home » Eclipse Projects » Standard Widget Toolkit (SWT) » [RANT] SWT Table API is pure CRAP
[RANT] SWT Table API is pure CRAP [message #442582] |
Wed, 08 September 2004 23:30 |
Jacek Messages: 9 Registered: July 2009 |
Junior Member |
|
|
As an SWT newbie I've been struggling with this damn Table, TableViewer,
TableContentProvider, ICellModifier and god knows what else is
needed...unreal the amount of code one has to write to do stupid editing
on 2 text columns. And it still doesn't work and I have no idea why.
SWT guys, take an idea from .Net. Here's a code snippet from working
with a 3rd party grid I use at work:
ultraGrid1.DataSource = <my collection of objects>;
(this statement alone creates all the columns, binds the properties of
the object to them, etc...I'd need to create columns in the table, a
spearate TableViewer, TableContentProvider and TableLabelProvider in SWT
just to do this).
ultraGrid1.Columns["my first column"].ReadOnly = false;
//this makes it editable, would need to implement all of ICellModifier
//in SWT just to do this
2 lines of code! For crying out loud I'm up to 100-200 lines of code in
SWT to do the same thing! I can't believe the JFace wrappers for a table
are such CRAP, a total exercise in lost productivity. I want to do Java
for my open-source project, but at this rate the productivity I have at
work with .Net controls is so light years ahead of SWT that I am really
starting to wonder whether I did the right choice.
The whole JFace editable/sortable table thing needs to be redone from
scratch to make the API managable for mere mortals, it's an utter pain.
Not to mention god forbid you change the column order (quite a common
requirement), all the hard-coded column indices in all the viewers,
icellmodifiers, labelproviders, etc. would bomb in 2 seconds flat.
Very dissapointed with this part of SWT so far.
Jacek
P.S. I won't even compare this to my old PowerBuilder years...SWT is not
even in the same universe in terms of productivity. Fix the damn API
so finally there is fighting change against Windows.Forms!
|
|
| |
Re: [RANT] SWT Table API is pure CRAP [message #442643 is a reply to message #442642] |
Thu, 09 September 2004 18:20 |
Jacek Messages: 9 Registered: July 2009 |
Junior Member |
|
|
I know, but it's just incredibly frustrating when I see I could get
something done in .Net in 10 minutes and with SWT I've spent 2
days...and still no end in sight.
The whole table / tableviewer / icellmodifier approach screems for some
radical simplification...don't you find it incredibly verbose for the
task at hand?
At this point in time as a regular developer I wouldn't mind some less
efficient code in return for being able to accomplish a simple task in
less time. After all, I am donating my personal time as well for my
project and having to write 100+ lines of code EVERY TIME I need to
show an editable table is really a pain in the neck and not a great use
of the aforementioned personal time.
In the end productivity IMHO is a lot more important than shaving off
a few milliseconds in some function.
Jacek
Vic Hanson wrote:
> I don't usually respond to [RANT]s. However I wanted to point out to you
> the obvious. SWT is developed by only a few people, versus Microsoft
> Studio .NET has several hundred developers (my cousin is one of them).
> Your typical one line of code does it all from Microsoft gives you no
> control of how your object is created, and from experience the
> underlying code is an abolute nightmare (MFC? Hello?).
>
> Your [RANT] is a valid one from a production point of view, however, I
> would point out that this is not Microsoft C++/C#/J++ .NET. The SWT
> developers and supporters here have worked very hard to give us a solid
> foundation to build upon, most donating their personal time in the true
> OpenSource fashion. SWT is about native platform widgets, and provides a
> solid foundation for building the production libraries that you speak
> of. You can obviously see the pains Microsoft went through to give you
> those "one liners" that do it all. My question to you is, how do you
> know they did it efficiently?
>
> Vic Hanson
>
> P.S. I hate to state the obvious, but if you stated your problem more
> like a question than a complaint then you will find more people willing
> to help you resolve your issue.
>
> Jacek wrote:
>
>> [RANT]
>
>
|
|
| | | | |
Re: [RANT] SWT Table API is pure CRAP [message #442673 is a reply to message #442582] |
Fri, 10 September 2004 16:31 |
Nick Edgar Messages: 439 Registered: July 2009 |
Senior Member |
|
|
Note that TableViewer and friends are part of JFace, not SWT.
But I would agree with you that TableViewers have much room for improvement.
In particular, we're missing a good abstraction for a column, and the mixing
of property names and integer indices is just broken.
So I'm not going to disagree with your rant. I just hope you feel better
after letting off steam <g>.
This is an area we need to improve on for 3.1. In particular, I think there
will be a large audience of people wanting to do "bread and butter" database
apps using the Eclipse Rich Client Platform, and we should make the simple
cases easy and the hard cases possible (sorry for the cliche, but it's
true).
The databinding support in frameworks like WinForms, JDNC, and David Orme's
Essential Data, does seem to be simpler to use than what JFace viewers
currently provide. In particular, JFace doesn't have a good story for
binding to forms.
Can anybody provide feedback on how well these frameworks work in real apps?
Although they appear to be easy to get started with, do they scale to
industrial strength apps, and provide the flexibility needed for customizing
the presentation, validation, sorting, etc? Do they make assumptions about
your model -- must your model implement special interfaces, or can you hook
up a pre-existing model?
Hey Dave, want to contribute ED to Eclipse?
Nick
"Jacek" <zaraza_NOSPAM@corridorofcells.com> wrote in message
news:cho4du$46p$1@eclipse.org...
> As an SWT newbie I've been struggling with this damn Table, TableViewer,
> TableContentProvider, ICellModifier and god knows what else is
> needed...unreal the amount of code one has to write to do stupid editing
> on 2 text columns. And it still doesn't work and I have no idea why.
>
> SWT guys, take an idea from .Net. Here's a code snippet from working
> with a 3rd party grid I use at work:
>
> ultraGrid1.DataSource = <my collection of objects>;
>
> (this statement alone creates all the columns, binds the properties of
> the object to them, etc...I'd need to create columns in the table, a
> spearate TableViewer, TableContentProvider and TableLabelProvider in SWT
> just to do this).
>
> ultraGrid1.Columns["my first column"].ReadOnly = false;
>
> //this makes it editable, would need to implement all of ICellModifier
> //in SWT just to do this
>
>
>
> 2 lines of code! For crying out loud I'm up to 100-200 lines of code in
> SWT to do the same thing! I can't believe the JFace wrappers for a table
> are such CRAP, a total exercise in lost productivity. I want to do Java
> for my open-source project, but at this rate the productivity I have at
> work with .Net controls is so light years ahead of SWT that I am really
> starting to wonder whether I did the right choice.
>
> The whole JFace editable/sortable table thing needs to be redone from
> scratch to make the API managable for mere mortals, it's an utter pain.
>
> Not to mention god forbid you change the column order (quite a common
> requirement), all the hard-coded column indices in all the viewers,
> icellmodifiers, labelproviders, etc. would bomb in 2 seconds flat.
>
> Very dissapointed with this part of SWT so far.
>
> Jacek
>
> P.S. I won't even compare this to my old PowerBuilder years...SWT is not
> even in the same universe in terms of productivity. Fix the damn API
> so finally there is fighting change against Windows.Forms!
|
|
| |
Re: [RANT] SWT Table API is pure CRAP [message #442678 is a reply to message #442676] |
Fri, 10 September 2004 20:40 |
Nick Edgar Messages: 439 Registered: July 2009 |
Senior Member |
|
|
Or would you prefer JNTable?
If the existing Swing controls are so great, why is Amy Fowler doing JDNC
("More For Less" <g>)?
Have you (or anyone else reading this) looked at JDNC?
https://jdnc.dev.java.net/documentation/index.html
https://jdnc.dev.java.net/documentation/overview.html
They add a few layers of cake on top of Swing. Some extracts from the
overview:
Swing Extensions
The Swing Extensions package includes extensions to the Swing API for the
common features required by JDNC. These APIs have been designed to be
congruous with Swing and can be used in any Swing application, but the
components are lower-level than the components in the JDNC API layer.
JDNC API
The JDNC API layer contains the high level UI components which wrap the
Swing Extensions layer to make common use cases easier to construct. These
components are intended to follow the JavaBeans patterns whenever possible,
so they should be usable within existing tools, such as NetBeans. These
components will provide attractive default visuals, usability features, and
data-binding out of the box so that a developers can get professional
results quickly.
JDNC Markup Language
And last but not least we arrive at the highest level - the level which
initially motivated this project - the JDNC markup language. The JDNC markup
language provides an XML syntax for configuring rich, data-centric,
enterprise clients that can be easily deployed either as a Java WebStart
application, or as an Applet within a browser.
---
Note that the controls in the JDNC API layer consist of wrappers implemented
in terms of the earlier Swing components like JTable, but they are
themselves Swing controls. So it's another layer of cake, but baked from
the same dough.
Their argument seems to be that controls like JTable are too complex for
common use cases, so they add JDNC wrappers with (hopefully) simplified API,
and then allow those to be configured via XML. Just wondering if the JDNC
API is a useful abstraction, or if it just gets in the way.
How leaky an abstraction is it?
(c.f. http://www.joelonsoftware.com/articles/LeakyAbstractions.htm l)
Nick
"Jacek" <zaraza_NOSPAM@corridorofcells.com> wrote in message
news:chsnqo$dso$1@eclipse.org...
> Nick Edgar wrote:
> > Note that TableViewer and friends are part of JFace, not SWT.
> > But I would agree with you that TableViewers have much room for
improvement.
> > In particular, we're missing a good abstraction for a column, and the
mixing
> > of property names and integer indices is just broken.
> > So I'm not going to disagree with your rant. I just hope you feel
better
> > after letting off steam <g>.
>
> A port of Swing's JTable to SWT would be pretty great, together with all
> of its custom cell renderers, etc. Even in .Net no one uses the base
> DataGrid control, but buys more functional 3rd party ones, like the
> Infragistics UltraGrid we are using.
>
> Cheers,
> Jacek
|
|
| | | | |
Re: [RANT] SWT Table API is pure CRAP [message #442697 is a reply to message #442686] |
Sat, 11 September 2004 21:27 |
Eclipse User |
|
|
|
Originally posted by: ro.usenet.spam
https://bugs.eclipse.org/bugs/show_bug.cgi?id=4566
After 3 years of being a bug/request it was declared 'impossible', though I
wonder how wxWidgets/qt does it?
It is a horrible limitation of SWT.
"Chris Merrill" <chris@nospam.net> wrote in message
news:chtq3n$pd5$1@eclipse.org...
> Jacek wrote:
> > As an SWT newbie I've been struggling with this damn Table, TableViewer,
> > TableContentProvider, ICellModifier and god knows what else is
>
> I do have to agree with you in one way - the Table/TableViewer is rather
> primitive compared to the Swing JTable. For instance, I'd like to provide
> cells with a custom image background. Specifically, something like a
> colored bar drawn behind a numeric value to give a better visual cue of
> the meaning/scale of the number. In Swing this is pretty trivial - just
> implement a CellRenderer. AFAICT, this is impossible in SWT. Many of
> the requests I see for Table, Tree and TreeTable enhancement could be
> addressed by allowing custom cell/node renderers. But we're somewhat
> limited by the abilities of the native widgets. I guess it's a
> tradeoff...nothing is perfect.
>
>
> --
> ************************************
> Chris Merrill
> st.ng4@christophermerrillZZZ.net
> (remove the ZZZ to contact me)
> ************************************
>
|
|
|
Re: [RANT] SWT Table API is pure CRAP [message #442706 is a reply to message #442686] |
Sun, 12 September 2004 15:05 |
Jacek Messages: 9 Registered: July 2009 |
Junior Member |
|
|
Well, in .Net most of the more advanced 3rd party table/grid controls
are all implemented as custom-drawn controls (just like Swing) that do not
rely on native widgets (except for the in-cell editors of course).
That's what gives them all the flexibility.
But the part I like most is that you just feed it with a collection of
objects and using reflection it builds all the columns, binds them
automatically to each property of the object, implements default
editors, etc...you get to focus on business logic instead of writing
mundane table viewers, label providers, etc.
Also, it allows for built-in column sorting, column moving (! - no
control in SWT allows this AFAIK), even column filtering (by showing
a drop-down list of unique values in the column header)...sooner or
later SWT will probably need a custom-drawn table control as well,
there is only that much that can be done relying on purely native widgets.
Cheers,
Jacek
Chris Merrill wrote:
> Jacek wrote:
>
>> As an SWT newbie I've been struggling with this damn Table,
>> TableViewer, TableContentProvider, ICellModifier and god knows what
>> else is
>
>
> I do have to agree with you in one way - the Table/TableViewer is rather
> primitive compared to the Swing JTable. For instance, I'd like to provide
> cells with a custom image background. Specifically, something like a
> colored bar drawn behind a numeric value to give a better visual cue of
> the meaning/scale of the number. In Swing this is pretty trivial - just
> implement a CellRenderer. AFAICT, this is impossible in SWT. Many of
> the requests I see for Table, Tree and TreeTable enhancement could be
> addressed by allowing custom cell/node renderers. But we're somewhat
> limited by the abilities of the native widgets. I guess it's a
> tradeoff...nothing is perfect.
>
>
|
|
|
Re: [RANT] SWT Table API is pure CRAP [message #442795 is a reply to message #442706] |
Mon, 13 September 2004 15:00 |
Eclipse User |
|
|
|
Originally posted by: micasim.gmx.de
KTable http://www.kupzog.de/fkmk_uk/Programming/Downloads/downloads .html
might be more the table You want...
Michael
On Sun, 12 Sep 2004 11:05:04 -0400, Jacek
<zaraza_NOSPAM@corridorofcells.com> wrote:
> Well, in .Net most of the more advanced 3rd party table/grid controls
> are all implemented as custom-drawn controls (just like Swing) that do
> not
> rely on native widgets (except for the in-cell editors of course).
> That's what gives them all the flexibility.
>
> But the part I like most is that you just feed it with a collection of
> objects and using reflection it builds all the columns, binds them
> automatically to each property of the object, implements default
> editors, etc...you get to focus on business logic instead of writing
> mundane table viewers, label providers, etc.
>
> Also, it allows for built-in column sorting, column moving (! - no
> control in SWT allows this AFAIK), even column filtering (by showing
> a drop-down list of unique values in the column header)...sooner or
> later SWT will probably need a custom-drawn table control as well,
> there is only that much that can be done relying on purely native
> widgets.
>
> Cheers,
> Jacek
|
|
| |
Re: [RANT] SWT Table API is pure CRAP [message #442989 is a reply to message #442646] |
Wed, 15 September 2004 17:02 |
David J. Orme Messages: 291 Registered: July 2009 |
Senior Member |
|
|
Jacek wrote:
> I just noticed that their VirtualTable only works with SWT 2.1, not 3.0
> (they're working on it). At least it gives me some hope for the future.
I just got back from vacation today. :-) Sorry for the delay in
replying here.
I'm going to give you an early unofficial scoop here:
Essential Data's Eclipse 3.0 support is now stable, but not quite
complete (more about this below). We're right now in the middle of
refactoring the project to make it more approachable. For the impatient
who are willing to deal with work-in-progress, check out:
http://essentialdata.sourceforge.net/cgi-bin/home
(This URL is previously unpublished. You won't find it linked-to yet
from our home page at swtworkbench.com, although that will change in the
next few business days.)
You don't want to use VirtualTable. Eclipse 3.0's changes to SWT
totally broke it and we rewrote it from the ground-up; VirtualTable is
still there, but deprecated.
MROTable is the replacement, works well across all platforms on which
it's been tested (Windows/Linux), and is as stable as any beta-quality
code ever was and more stable than most. All features of MROTable are
done now except for Essential Data's automatic support for master/detail
relationships... (implementing IMaster/IDetail)
MROTable (and all of Essential Data) uses a very similar design
philosophy to what you said you wanted, although its design wasn't based
on .net... It's still a bit lower-level though. You have to define
your own column layout, but then the controls are automatically
hooked-up to the data in your collection, etc. But you also get more
flexibility. For example, with MROTable, it's easy to define a layout
where each "object/record" occupies two physical rows, similar to the
way some checkbook registers work.
Once Eclipse 3.0 support is complete, we'll be writing more proper
documentation. In the meantime, there's the mailing lists and Essential
Budget (http://essentialbudget.sourceforge.net/cgi-bin/home), our
open-source personal finance manager written using ED.
This is also a previously-unpublished URL. (Both of these web sites got
set up at 1:30 AM the night before I went on vacation... ;-)
Best Regards,
Dave Orme
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
|
FW: Re: [RANT] SWT Table API is pure CRAP [message #442998 is a reply to message #442673] |
Wed, 15 September 2004 19:56 |
David J. Orme Messages: 291 Registered: July 2009 |
Senior Member |
|
|
This really gets down to the nitty-gritty of what Eclipse is / should be:
Nick Edgar wrote:
> This is an area we need to improve on for 3.1. In particular, I think there
> will be a large audience of people wanting to do "bread and butter" database
> apps using the Eclipse Rich Client Platform, and we should make the simple
> cases easy and the hard cases possible (sorry for the cliche, but it's
> true).
>
> <snip/>
> Hey Dave, want to contribute ED to Eclipse?
1) Essential Data is *already* fully open-source and it lets any RCP
application do what you describe today.
Therefore we think that there's no need for Essential Data to be
included in Eclipse. Just link to ED from the Eclipse web site so that
people will find it, and your problem is solved. :-)
2) Eclipse is fundamentally about having a pool of commercially-funded,
standardized, royalty-free technology that any company or
individual--large or small--can draw from.
But for the health of this pool and the ecosystem that drinks from it,
it's important that the large companies don't poison the pool--that they
don't use the pool as a predatory means to kill off the smaller
companies for their own (temporary) benefit.
3) This isn't about making more open-source software--Essential Data is
*already* open-source. It's about big companies wanting to profit from
over two years' investment by a small company without paying them a dime
for it.
But I feel it would be a grave mistake for Eclipse to drive away the
small companies. *Nobody* around here is as big as *Redmond*...
The open-source community and the other small companies in Eclipse.org
will be watching to see how this is handled...
Regards,
Dave
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
|
Re: [RANT] SWT Table API is pure CRAP [message #443010 is a reply to message #442989] |
Thu, 16 September 2004 04:41 |
Eclipse User |
|
|
|
Originally posted by: null.spam.usenet
Why a virtual Table and not a Tree that could also work as a Table (tree with
no leafs) for total flexibility and control?
Something advanced like this virtual would be great for swt:
http://www.soft-gems.net/VirtualTreeview/VT.php
"David Orme" <daveo@asc-iseries.com> wrote in message
news:ci9sbf$hue$1@eclipse.org...
>
> You don't want to use VirtualTable. Eclipse 3.0's changes to SWT
> totally broke it and we rewrote it from the ground-up; VirtualTable is
> still there, but deprecated.
>
> MROTable is the replacement, works well across all platforms on which
> it's been tested (Windows/Linux), and is as stable as any beta-quality
> code ever was and more stable than most. All features of MROTable are
> done now except for Essential Data's automatic support for master/detail
> relationships... (implementing IMaster/IDetail)
|
|
| |
Re: [RANT] SWT Table API is pure CRAP [message #443056 is a reply to message #442989] |
Fri, 17 September 2004 22:24 |
Steve Northover Messages: 1636 Registered: July 2009 |
Senior Member |
|
|
> You don't want to use VirtualTable. Eclipse 3.0's changes to SWT
> totally broke it and we rewrote it from the ground-up; VirtualTable is
> still there, but deprecated.
Did you enter bug reports for the stuff we broke?
"David Orme" <daveo@asc-iseries.com> wrote in message
news:ci9sbf$hue$1@eclipse.org...
> Jacek wrote:
> > I just noticed that their VirtualTable only works with SWT 2.1, not 3.0
> > (they're working on it). At least it gives me some hope for the future.
>
> I just got back from vacation today. :-) Sorry for the delay in
> replying here.
>
> I'm going to give you an early unofficial scoop here:
>
> Essential Data's Eclipse 3.0 support is now stable, but not quite
> complete (more about this below). We're right now in the middle of
> refactoring the project to make it more approachable. For the impatient
> who are willing to deal with work-in-progress, check out:
>
> http://essentialdata.sourceforge.net/cgi-bin/home
>
> (This URL is previously unpublished. You won't find it linked-to yet
> from our home page at swtworkbench.com, although that will change in the
> next few business days.)
>
> You don't want to use VirtualTable. Eclipse 3.0's changes to SWT
> totally broke it and we rewrote it from the ground-up; VirtualTable is
> still there, but deprecated.
>
> MROTable is the replacement, works well across all platforms on which
> it's been tested (Windows/Linux), and is as stable as any beta-quality
> code ever was and more stable than most. All features of MROTable are
> done now except for Essential Data's automatic support for master/detail
> relationships... (implementing IMaster/IDetail)
>
> MROTable (and all of Essential Data) uses a very similar design
> philosophy to what you said you wanted, although its design wasn't based
> on .net... It's still a bit lower-level though. You have to define
> your own column layout, but then the controls are automatically
> hooked-up to the data in your collection, etc. But you also get more
> flexibility. For example, with MROTable, it's easy to define a layout
> where each "object/record" occupies two physical rows, similar to the
> way some checkbook registers work.
>
> Once Eclipse 3.0 support is complete, we'll be writing more proper
> documentation. In the meantime, there's the mailing lists and Essential
> Budget (http://essentialbudget.sourceforge.net/cgi-bin/home), our
> open-source personal finance manager written using ED.
>
> This is also a previously-unpublished URL. (Both of these web sites got
> set up at 1:30 AM the night before I went on vacation... ;-)
>
>
> Best Regards,
>
> Dave Orme
> --
> Dave Orme
> Eclipse Visual Editor Project Lead
> Advanced Systems Concepts' Chief Architect
> http://www.swtworkbench.com http://essentialdata.sf.net
|
|
| |
Goto Forum:
Current Time: Thu Sep 19 18:27:23 GMT 2024
Powered by FUDForum. Page generated in 0.06479 seconds
|