Basic MVC Question(s)

[Thatguy Steve]

ARRRRRRG!!!!

I know this is going to sound stupid but i have gone just about everywhere
and also RTFM'd everything i've found on this topic but I haven't found a
simple explanation with code examples on MVC.

And I'd liked some help fromr y'all if I could. I know allot of you know
this sh%t in your sleep .......

So .....

Say you have a simple class named person with your typical name and address
info and you also want to write a simple gui called personadd that contains
each of these text fields in a panel that will be added to a frame.

I'd like to see some code that shows:

.. how/where the person class is instantiated in the personadd class
.. connections between the instance of the person class and the personadd
class
.. where and how the event handlers are positioned in each class and how they
operate
.. and all of the fields are bound and constrained.

All I seem to find in any books and/or websites are these examples that are
difficult for me to understand.

I know this is simple stuff but I just need one real(world) example I can
work with to lift me off my stump.

I'd also would like to see both these classes as bean examples that I can
work with.

Any and all help from any of you coding maniacs would be greatly
appreciated.

Thanks,

Steve
(e-mail address removed)

 

[Ed Yu]

The best way you can learn SWING is to use some kind of IDE. I prefer
JBuilder because the generated code is really easy to understand. You can
also try NetBean and others.

Usually you have a button to instantiate the person object and store it
inside the a vector either in your main class or somewhere inside your Frame
class so that button listeners can access it.

There are multiple styles to handle button code (IDE option allows you to
choose one or the other)

a) anonymous listener
b) listener adapters

It is just a matter of style. Look at the generated code is the best way to
learn SWING programming and use SWING documentation as a reference.

Good luck!

 

[Karsten Lentzsch]

I know this is going to sound stupid but i have gone
just about everywhere and also RTFM'd everything
i've found on this topic but I haven't found a simple
explanation with code examples on MVC.

First off, MVC is not the ultimate pattern to look for
in Swing, you better understand the motivation behind MVC
and apply that to your project. Likely you'll then end up
with something like: M(VC), M(VC)+AppModel layer,
MVP and HMVC.

Only if you implement Swing UI delegates as part
of an l&f, the MVC pattern applies directly.

I could find only a few examples in the net, that show
how to seperate the domain objects from the presentation
and how to connect these two layers and bind object
properties like street and name to UI components.

I aim to write about the available approaches and
compare their pros and cons. And I will contribute
an open source Swing skeleton application that consists
of three layers: domain, application models, presentation;
together with a library for general purpose data binding.

You can find more detailed information around these
issues in my postings at JavaDesktop.org. That's the place
where I write about these problems and I will publish
my new open source libraries and sample apps. Also,
I will answer your questions in the JavaDesktop.org forums.

I will announce major events and new findings at
JavaDesktop.org and in comp.lang.java.gui


The postings mentioned below contain a few references
to related articles:
http://www.javadesktop.org/forums/thread.jspa?threadID=236&tstart=0
and
http://www.javadesktop.org/forums/thread.jspa?threadID=137&tstart=0

Hope this helps. Kind regards,

 

[Thatguy Steve]

Thanks Karsten.

I'm probably going to end up with an M(VC) style (I think, ha ha).

Currently, IDE wise, I'm using NetBeans but I'm also very familiar with
VisualAge.

(I've been coding large mainframe style systems for 24+ years). I'm piecing
this Java thing together slowly and it seems to be working rather well.
It's a hellava lot of more fun to code than CICS COBOL with DB2 (ha ha).

The problem for me stems from either manuals, books and articles that depict
example senarios that do not deal with real world examples that I, as a
business analyst, designer and coder are not all that interested in. What I
would like to see is something more along the lines of a standard data
collection style system that shows the relationships between my major
classes (emloyee's for example) and the gui classes that allow the users to
add, change and delete the data (from a simple database). A clear example
that shows the connections between these objects along with properties that
are bound and/or constrained. I have a stack of books sitting next to me
and none of them pull it all together from the perspective I'm interested
in.

Again, thanks for the info and I'll check for your article(s) and see what
else you have out there that may assit me.

Steve

 

[Thomas Weidenfeller]

I'd like to see some code that shows:

. how/where the person class is instantiated in the personadd class
. connections between the instance of the person class and the personadd
class
. where and how the event handlers are positioned in each class and how they
operate
. and all of the fields are bound and constrained.

Sounds like you are looking for two thinks:

(1) What I call the "plumbing". You have all these nice architectures
and patterns, and they look as if everything magically falls together.
And then reality bites you: You build classes the follow the rules, but
you just end up with a bunch of classes and instances.

(2) Granularity. Should e.g. each entry field in a GUI have it's own
explicit model, or should the whole window, or even the whole GUI just
work on one application model?

All I seem to find in any books and/or websites are these examples that are
difficult for me to understand.

I know this is simple stuff but I just need one real(world) example I can
work with to lift me off my stump.

No, this stuff is not simple. IMHO it is still some kind of black art,
and textbooks avoid to talk about it. Lets start with (1):

Plumbing things together:

There is a clear structure in MVC (Swing uses a variant, not pure MVC,
but that isn't too relevant here), defining who knows about whom. This
includes that a view knows about the model, but the model not about the
view.

Conclusion: The model is not the right place to plumb a model and a
view together. That leaves the job to the view, or to some third
party. Or both. I tend to share the work between both.

The view gets a constructor taking a model and/or a method
setModel(MyModel m). The code inside the constructor/method is
responsible to subscribe to all interesting events from the model.
E.g. if the view displays some text data, setModel() should subscribe
to events indicating changes of that text data.

Some possible third parties could be:

- your main() method or initial object - for very simple applications

- an Action that is invoked in response to some other GUI interaction.
The action then gets the model (e.g. from an application object), or
creates a new one, it also gets a view (e.g. from some window pool),
or creates a new view, and glues the stuff together.

- An event handlen the GUI doing the same as one would do in an
Action.

One can come up with some more third parties like "gui directors" or
similar strange stuff, but the mentioned above should be a good start.

(2) Granularity

I once wrote a research paper about this, but it didn't get published.
Maybe it wasn't too great

The problem is, that if you give every little widget its fully visible
own model, you get mad about the plumbing and it gets very
impractical. Imho, such great experiments in OO GUI systems like
Interviews and Fresco badly suffered from this (Fresco also threw CORBA
into the mix, which didn't increase its ease of use ...).

IMHO there should be an intermediate level that allows one to think
about greater issues than wiring each text field to a model. The level
that I prefere is the window. I logically treat everything in the
window as one view, that should get one model.

Of course the window is build with the normal widgets, and these have -
or must have - their own little models (like a JComboBox). But I keep
the handling of these small models inside the window code, so they are
not visible from outside of the window.

This rougher Model-View granularity has a nice additional effect, that
I try to use in an application's architecture design: With "one Window
- one Model" I end up of having windows that are kind of object
editors. If there is a need to change an object (a model), I bind it to
an editor (a view, a window), and the object can be edited. This
becomes a two-way process in application design: When designing a class
I keep in mind that it should be possible to build a coherent "object
editor" for it, when I design a window, I keep in mind that it should
work on one object, so the window shouldn't be cluttered with all kinds
of unrelated stuff.

I'd also would like to see both these classes as bean examples that I can
work with.

Any and all help from any of you coding maniacs would be greatly
appreciated.

Please code your own. IMHO the only way to get some understanding about
this is to code something, to try out things, to evaluate the result,
and try to be better next time.

/Thomas

 

[Thatguy Steve]

Thomas,

Thanks for the information.

I agree, I should tinker with this until I find just how it works and make
use of what I get comfortable with. (I remember this from my old COBOL/CICS
days)

What has slowed me down I think has been my reluctance to tinker thinking
that I should wait for and learn what is the so called "best practice" in
the field before I learn any bad habits coding Java. This in turn has
(basically) prevented me from learning how to code from many possible
different angles. So instead of diving right in (trial & error) I have been
sitting back waiting for the magic answer. These IDE's I've been fooling
with (VisualAge, JBuilder & NetBeans) have been spoiling me in many ways.

But enough assigning the blame to everything else but me, ha ha. I know
what I have to do.

Your suggestions will come in handy as I screw around a bit.

Patients Grashopper, all things will come in time.

Again, thanks,

Steve

 

[Steven T Abell]

http://www.brising.com/MVCinJava.html

http://developer.netscape.com/docs/technote/simple/index.html

http://developer.netscape.com/docs/technote/database/web/index.html

Steve
--
Steven T Abell
Software Designer
http://www.brising.com

In software, nothing is more concrete than a good abstraction.