[
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
>