> -----Original Message-----
> From: Bob Tarling [mailto:[EMAIL PROTECTED]
> Sent: den 10 februari 2007 23:33
> To: [email protected]
> Subject: Re: [argouml-dev] Subsystems with GUI-parts
>
> > I have some idea that the subsystems are, to some extent,
independent.
> > They could be maintained independently. Because of that, the
GUI-parts
> > of a subsystem are problematic. In your diagrams you have either
ignored
> > the fact that Notation, CG/RE, and Critics need small GUI-parts
(they
> > are colored pink) or you have included that in the ArgoUML Frame. My
> > whole reasoning is around how we shall treat them.
>
> The model subsystem also needs GUI parts to operate as does any other
> subsystem. But you seem to think the model subsystem has some other
> special rules that make it different.
This is exactly the conflict of what we define as subsystems. I'd say,
no, it doesn't. It isn't configurable in any way and we have defined
views in separate subsystems.
> The only thing that makes it different to my perspective is that it's
> the only subsystem with a clear interface and its available from all
> the GUI. Others should follow the same lead.
>
> I see subsystem as units of self contained business logic OR
presentation.
It looks more and more as you are advocating my second alternative with
breaking out all GUI-parts from each subsystem.
> The presentation of the business logic should remain entirely
> independent with ArgoUML providing swing controls which may or may not
> be used by an external system like eclipse or netbeans.
To me, on the conceptual level, the GUI subsystem provides the swing
controls. Replacing the GUI subsystem by some other implementation would
then be possible. As the GUI subsystem currently is implemented using
java.awt and javax.swing things, the replacement implementation would
have to provide new implementation for those classes.
[...]
> > > In here I would consider those few GUI notation classes to be
among
> > > the common available Actions and dialogs contained in some package
> > > within that subsystem.
> >
> > As I mentioned before, then they shouldn't be pink then.
>
> You're confusing something here. The subsystems in pink are those that
> do not need to and should not contain any GUI. Just as with the model
> subsystem.
Yes, but you just wrote that it was to be within that subsystem. I am
confused.
> > > It may be that all GUI subsystems need to have access to some set
of
> > > GUI utility classes. I've left this off for clarity.
> >
> > In the cookbook this is modeled as a dependency on the GUI
subsystem. In
> > the current application the GUI utility classes are awt and swing
> > classes.
>
> The cookbook describes the explorer as being part of the GUI
> subsystem. The explorer is one of the major graphical views of the
> model interface. So why wouldn't the GUI subsystem also contain the
> other major graphical views of other non-visual subsystems.
But it does. It contains menus, toolbars, tabbed pane, and settings tab
just as well as it contains javax.swing.tree and some other things to
create the Explorer.
Then we need just the View level subsystems to fill these with contents
from the Model subsystem.
> We seem to carry on with this disagreement and return to the same
> arguments time and time again.
I don't think we disagree. We just don't understand each-other.
> I've simply never worked on a system before that actively tries to
> create such a strong relationship between view and model.
I'd say we are working in the opposite direction trying to untangle
everything. It is complicated and since we are completely incapable of
establishing a common goal we are not pulling in the same direction so
there is a lot of frustration and extra work created.
I started this discussion hoping to get one step further towards the
definition of a common goal. I am still hopeful.
/Linus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
