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

["Christian Gruber" <cgruber@xxxxxxxxxxx>]

Scott wrote:
> [snip]
> It was at that point that I realized I wasn't doing enough reading ;)

Heh... 

> I think the Controller is really the trick. It's the part in MVC that
> people tend to think is just the event handlers. I hope to set up and
> publish a thin framework for what I'm thinking of soon. I think it
could
> really demonstrate that we really can get high reuse/maintainability
as
> well as very different types of UIs.

Absolutely.  What works really nicely about the Next stuff and its
children is that it's not "a controller object" often, but a set of
generic controller functionality, and you write custom controllers that
hook into that generic functionality.  Furthermore, they have their
widgets and controllers laden with "delegate methods" which are methods
executed on an object you set on it that implements these delegate
methods.  Essentially event hooks - nothing new, but the relative number
of hooks for these generic framework objects is really high. 

So for example, you can set a delegate object of your choice to be the
delegate for your EOAdaptorChannel object in their persistence layer.
This is a representation of a communications channel to the data source
(JDBC or JNDI by default) - very low level.  With that, you can hook
into methods such as 

public void adaptorChannelDidEvaluateExpression(EOAdapterChannel
channel,
	
EOSQLExpression expression);
public boolean adaptorChannelShouldEvaluateExpression(EOAdapterChannel
channel,
	
EOSQLExpression expression);

With similar methods for evaluating stored procedures, fetching single
rows, altering result-sets, selection based on attributes, etc.  With
these kind of hooks you can do amazing levels of debug logging,
optimization of queries in a pluggable way that doesn't mess with the
nice layering, or even some business-level validation on certain data to
avoid trips to the database in some conditions.  So much work done for
you... ;)

At any rate, you have these delegates doing some control, but you have
more traditional controllers providing an actual separation between
model and GUI, modifying access to the model and/or filtering the model
before it hits the GUI.

> > P.S.  MVC is not a UI paradigm (sorry about that word).  It's a
> > partitioning of roles in the code, with the advantages of
plugability,
> > manageability, and (often) reusability. It is well-used in a UI, but
> > that's a very limited area of application.  -cg.
> 
> Sounds like 20 cents to me (paradigm, get it? <ducking/>)

I feel dense, Scott, but I don't get it... :(

[remainder is mutual appreciation of MVC, and needless choir-preaching.
;)  I'm with you all the way there Steve. -cg]

regards,
Christian.