RE: [platform-swt-dev] From Swing to SWT

[Scott Stanchfield <scott@xxxxxxxxxxxx>]

> [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of Brad O'Hearne
> > -- all the business logic belongs outside the UI
>
> Just a note -- from a textbook standpoint, yes, this is the case.

Them's fightin' words... <g>

Anyone who's met me should know that I don't believe in "textbook"
concepts...

> 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).

That depends...

I feel *very strongly* that validation should be done either only in the
business logic, *or* it must be redone in the business logic.

Why?

In a GUI app, it's not as big a deal, but as you try to start making
business logic more independent of UI, it makes a huge difference.

Think about web apps. If you validate in your HTML (using Javascript,
for example), *you cannot depend on that validation*! Why? Someone could
modify the HTML before they submit the form you sent them.

Because of this, you absolutely must validate in the business logic
(after the page request has been sent to the server). The results of
this validation are "feedback" to the UI layer.

Now it's perfectly fine to do some pre-validation in the form (so they
don't have to round-trip everytime), but the "real" validation must be
done in the BL.

So... in order to create a really flexible app, the BL must do
validation regardless if the UI does validation.

The trick is to separate the concept of validation from user feedback.
Feedback is merely spitting something out on the screen. The UI could,
for example, listen to a property in the BL called "valid" and display
status appropriately. Another BL property could describe why validation
is a problem, mapping the invalid properties to text describing why.

The UI listens to the model for changes in validity, and updates itself
accordingly. Validation in the BL can be performed on property update or
when the UI says "go".

Taking this approach, the UI stays very simple -- everything is "listen
and update".

> 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 designed properly (meaning the way I describe above), you get both
effects.

> 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).

I agree totally (except I'm excited about the builder I'm creating ;)

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

I still maintain that's the wrong approach. Building a GUI builder for
SWT is no more difficult than building one for AWT/Swing. It just
requires *not* thinking "JavaBeans"...

-- Scott