[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-swt-dev] From Swing to SWT
|
Typo in my message
> One more thing, is that I am not really too
> concerned about accomodating AWT and SWT either.
Should read
> One more thing, is that I am not really too
> concerned about accomodating AWT and Swing either.
> -----Original Message-----
> From: platform-swt-dev-admin@xxxxxxxxxxx
> [mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of Brad O'Hearne
> Sent: Friday, January 17, 2003 7:59 AM
> To: platform-swt-dev@xxxxxxxxxxx
> Subject: 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
> >
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
