Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [platform-swt-dev] From Swing to SWT

> -- all the business logic belongs outside the UI

Just a note -- from a textbook standpoint, yes, this is the case.  But
depending on how you are defining the term "business logic" it isn't
this simple.  What about things like field-level validation?  That is
essentially "business-logic" too (it is enforcing data-integrity).  Sure
its trivial, but stuff like this across a large form make it
time-consuming and a huge pain in the butt to create -- visual builders
*greatly* simplify adding / editing these types (a la Visual Studio).
You can't really push this stuff into the middle tier, or else you now
have traded field-level validation for form-level validation, which is
no more functional than a web page.  If you even attempted field-level
validation through the middle-tier, you are going to crush the network
with traffic, and your app will not scale.

I'm with Lane here, I think the lack of solid GUI builders for Java is
the glaring competitive weakness vs. MS, hence my excitement over SWT
and Eclipse (and Conga).  And following, I really think it would behoove
the SWT dev effort to consider making needed changes to allow more
effective GUI building.  One more thing, is that I am not really too
concerned about accomodating AWT and SWT either.  Focus on SWT.

BradO

> -----Original Message-----
> From: platform-swt-dev-admin@xxxxxxxxxxx 
> [mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of 
> Scott Stanchfield
> Sent: Friday, January 17, 2003 6:20 AM
> To: platform-swt-dev@xxxxxxxxxxx
> Subject: RE: [platform-swt-dev] From Swing to SWT
> 
> 
> The real solution is that we're all smart folks, and learning 
> a separate UI toolkit really isn't a big deal. Creating 
> adapters will only lead to minimized utilitization of the 
> target toolkit features -- the end UI can't be as effective 
> as if it were just programmed usin the target toolkit.
> 
> The right way to do things (IMHO) is:
> 
> 1) refactor your app (if necessary) so that the UI is "thin" 
> -- all the business logic belongs outside the UI
> 
> 2) learn SWT (more below)
> 
> 3) Create a completely new UI in SWT that uses the same 
> business logic. If you use the same design/layout of the old 
> UI, this should be very straightforward/quick.
> 
> I can hear the screams already, but think about it. How long 
> does it take to program a UI? The design/layout is really the 
> hard part. Once you learn a UI toolkit, programming UIs is 
> really pretty trivial.
> 
> On learning SWT (when one knows Swing)
> The missing piece here is a guide mapping "if you did X in 
> Swing, you do Y in SWT". I'd like to write such a thing, but 
> I don't have the time... Of course, once my UI builder is 
> done, that'll ease things a bit, as the builder can worry 
> about how to create the objects (constructors with args or 
> not), not the programmer.
> 
> -- Scott
> 
> ==============================================================
> Scott Stanchfield    scott@xxxxxxxxxxxx    http://javadude.com
> 
> Lead author of "Effective VisualAge for Java, Version 3"
>                                       http://javadude.com/evaj
> 
> VisualAge for Java Tips and Tricks     http://javadude.com/vaj
> Visit for Java Enlightenment!             http://www.jguru.com
> ==============================================================
> 
> > -----Original Message-----
> > From: platform-swt-dev-admin@xxxxxxxxxxx
> > [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of 
> Brad O'Hearne
> > Sent: Thursday, January 16, 2003 11:01 AM
> > To: platform-swt-dev@xxxxxxxxxxx
> > Subject: RE: [platform-swt-dev] From Swing to SWT
> >
> >
> > Lane,
> >
> > I am sure you have already considered this (and hence the 
> "hard to do" 
> > conclusion), but it seems that the answer for both Swing 
> and SWT is an 
> > abstraction layer that wraps around both Swing and SWT.  
> For example, 
> > the problem with having no default constructors in SWT 
> could possibly 
> > be handled by a custom factory class.  The builder invokes 
> the factory 
> > class without parameters, and the factory class creates the actual 
> > widget, using whichever constructor is appropriate.  This 
> effectively 
> > gives a parameterless interface to the builder, while allowing the 
> > existing parameterized constructors to be used.  Likewise, it seems 
> > like get/set property methods could also be a class wrapper 
> around the 
> > actual widget.  This is all probably a pain, yes, and alleviated by 
> > simply changing the design of the widgets themselves, but it is a 
> > possible answer.  I guess a nice side benefit is that your builder 
> > would be completely agnostic to the underlying widget 
> implementation 
> > -- the interface is the same for AWT, Swing, SWT, or whatever new 
> > implementation might come along.  Because the interface is 
> a wrapper 
> > around the widget library, there also is a separation 
> between widget 
> > implementation and builder needs, which for maintenance of 
> the widget 
> > library is probably a nice division of labor.  A simple set 
> of classes 
> > that demonstrate this follow:
> >
> > e.g.
> >
> > public class BuilderWidget {
> >
> >   public BuilderWidget(o.e..swt.Widget w) {
> >     this.widget = w
> >   }
> >
> >   private o.e..swt.Widget widget;
> >
> >   public void setProperty(Object val) {
> >   ...
> >   }
> >
> >   public void getProperty(String name) {
> >   ...
> >   }
> >
> > }
> >
> > public interface BuilderWidgetFactory {
> >
> >   public BuilderWidget create(String widgetType);
> >
> > }
> >
> > public class SWTBuilderWidgetFactory implements 
> BuilderWidgetFactory {
> >
> >   public BuilderWidget create(String widgetType) {
> >   ...
> >     //create the new SWT widget w
> >     return new BuilderWidget(w);
> >   }
> >
> > }
> >
> > Have you done something like this already?  Just an idea...
> >
> > BradO
> >
> >
> > > -----Original Message-----
> > > From: platform-swt-dev-admin@xxxxxxxxxxx
> > > [mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of Lane 
> > > Sharman
> > > Sent: Wednesday, January 15, 2003 7:25 PM
> > > To: platform-swt-dev@xxxxxxxxxxx
> > > Subject: Re: [platform-swt-dev] From Swing to SWT
> > >
> > >
> > > Michael,
> > >
> > > I have been studying this problem for a while and do not see any 
> > > clean solution. The problem is that neither j.a.Component & 
> > > Container, nor o.e..swt.Widget and its descendants 
> implement a meta 
> > > data interface which makes inspection of properties of a widget 
> > > possible. Thus a conversion tool or a Builder are hard to do for 
> > > both Swing and SWT!
> > >
> > > I have written a short expose on the subject of property and meta 
> > > data in a GUI and there is a JSR on this very topic.
> > >
> > > http://opendoors.com/conga/2.2/docs/property/siframes.html
> > > is a little presentation I wrote on the importance of the 
> property 
> > > exchange pattern which allows two objects that have no prior 
> > > knowledge of one another to establish a protocol (aka 
> Interface) to 
> > > exchange structured information. This is your case. You need a 
> > > translator that has a protocol map that can look at the dynamic 
> > > state of your Swing app
> > > (not the static code) and then use that property information
> > > to map to a
> > > corresponding SWT tool.
> > >
> > > I really wish I could tweak the base class of the SWT to 
> make it a 
> > > little more GUI builder friendly along the lines of what 
> I work with 
> > > in Conga.
> > >
> > > Everytime I study the base class of SWT, I become more 
> frustrated. 
> > > For example, it is very important that every widget have a local,
> > > relative
> > > name. There is no setName(), getName(). There is no
> > > setProperties(ProperyList), getProperties(PropertyList). Sigghhh.
> > >
> > > -lane
> > >
> > > Michael Privat wrote:
> > >
> > > >Hi all,
> > > >
> > > >I would be very interested to hear some opinions regarding a
> > > process to
> > > >convert a swing based application to a SWT based application. I 
> > > >know there is some effort to create a standard SWT_AWT and vice 
> > > >versa container to allow mixing the two toolkits but I am 
> > > >interested in knowing if there are any patterns one might try to 
> > > >follow when converting to minimize the effort.
> > > >
> > > >Cheers
> > > >Michael
> > > >
> > > >
> > > >
> > >
> > > --
> > > Lane Sharman
> > > http://opendoors.com Conga, GoodTimes and Application Hosting 
> > > Services http://opendoors.com/lane.pdf BIO
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > platform-swt-dev mailing list
> > > platform-swt-dev@xxxxxxxxxxx 
> > > http://dev.eclipse.org/mailman/listinfo/platfo> rm-swt-dev
> > >
> >
> >
> > _______________________________________________
> > platform-swt-dev mailing list
> > platform-swt-dev@xxxxxxxxxxx 
> > http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
> >
> 
> 
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx 
> http://dev.eclipse.org/mailman/listinfo/platfo> rm-swt-dev
> 




Back to the top