|
Replies:
7
-
Last Post:
Sep 19, 2006 5:51 AM
by: dimwight
|
|
|
|
|
|
|
Putting it all together
Posted:
Sep 8, 2006 10:32 AM
|
|
|
Ok, so I have found a ton of books/articles/etc about the individual components of Swing, some even with small sample applications to show off the components. But what I'm looking for is books/articles/(good) examples on how to actually create good, maintainable Client-side applications. I have some ideas on things I want to create, but I always get stuck on where to start the "architecture" of the application so that it is maintainable, simple, and acstetically pleasing.
Any suggestions? Thanks.
|
|
|
|
|
|
|
Re: Putting it all together
Posted:
Sep 9, 2006 2:57 PM
in response to: paul_mattheis
|
|
|
This site includes a couple of sample apps that demonstrate many of the recommended practices.
http://www.javapractices.com/index.cjp
It's good advice, too, judging by the tips I've read. Most of Bloch's Effective Java is reproduced there, but without the accompanying dicsussion that makes that book such a treasure.
|
|
|
|
|
|
|
|
|
JSR-296
Posted:
Sep 12, 2006 5:32 AM
in response to: paul_mattheis
|
|
|
If JSR-296 were available, I would suggest using it. Since it isn't, take a look at where JSR-296 is likely to go:
"A Simple Framework for Desktop Applications : TS-3399, 2006"
http://developers.sun.com/learning/javaoneonline/2006/desktop/TS-3399.html
Depending on your application, you may want to use some other existing framework. Eclipse, NetBeans, and jMatter are all worth investigating.
|
|
|
|
|
|
|
|
|
Re: Putting it all together
Posted:
Sep 12, 2006 8:47 AM
in response to: paul_mattheis
|
|
|
I highly recommend the book Desktop Java Live by Scott Delap.
|
|
|
|
|
|
|
|
|
Re: Putting it all together
Posted:
Sep 15, 2006 6:09 AM
in response to: paul_mattheis
|
|
|
Hi Paul
A few years ago I found myself in just the same position - there just didn't seem to be any frameworks that helped with the architectural side of GUI applications.
So I had a go myself, with the result that Superficial http://superficial.sourceforge.net already does at least as much as what's promised for JSR 296. It also handles the databinding issues addressed by JSR 295 Beans Binding, albeit in a quite different way (hint - no beans required).
Have a look at Superficial and see if it would help you, hopefully it will at least give you some ideas.
Regards, David Wright
|
|
|
|
|
|
|
|
|
Re: Putting it all together
Posted:
Sep 18, 2006 11:50 AM
in response to: paul_mattheis
|
|
|
Thanks all. These are some really helpful suggestions. Now that I have thought about it some more, I realize one of the biggest issues for me is how many models to have if I'm doing MVC. If I think about it, components have a model, the page has a model, the data as it's store in persistence has a model... Is the a model for business logic? Is there a model for tieing the forms together? I think this is where I get stuck. That and how they should all communicate. In the one article, it suggests (from how I read it) having lots of listeners to update as the model changes.
Does any of the suggestions already given or others address this more? Or am I looking at this from the wrong perspective?
|
|
|
|
|
|
|
|
|
Re: Putting it all together
Posted:
Sep 19, 2006 5:51 AM
in response to: paul_mattheis
|
|
|
Hi Paul
I think you've got a very interesting perspective on the problem.
The puzzle about how many models to have and how they should be related is an excellent example of the strength of the MVC paradigm, in that it stimulates sensible questions about a design; and of its weakness, in that doesn’t offer much in the way of answers.
Looking at an application in terms of its models, ie broadly speaking its state rather than its logic, produces a whole range of candidates:
* domain content – possibly multiple instances, even multiple types
* persistable session values - aka options/preferences
* transient session state - current window/pane/tab layout and which of these has focus
* widget state - including viewer widgets such as trees, tables, text panes
The first three of these represent largely orthogonal concerns, so it’s fairly straightforward to maintain independent model objects for each and update them as required.
The problem area is widget state. This certainly has to be maintained, whether or not the widget has an explicit model as in Swing. What’s tricky is that the whole purpose of a widget is to expose the state of some other model, so that
* its state must always be transparently aligned with that of the exposed model
* changes in its state must be relayed somehow to the exposed model
* it may need to respond to selection change by exposing a different model (or a different region of the same model, which amounts to the same thing)
It sounds as if the article you read on listeners is suggesting the standard approach of applying the Observer pattern, with the exposed model listening for changes on its exposing widgets, while each widget listens on the exposed model, the other exposing widgets, or both.
This is a very flexible approach and works perfectly well for simple applications, but it certainly does necessitate ‘lots of listeners’. This can make serious applications dauntingly complex and prone to bugs, basically because all those listeners tend to result in a closely-coupled design in which it is hard to maintain separation of concerns.
As explained in my contribution to ‘Questions about Best Practices…’ http://forums.java.net/jive/thread.jspa?messageID=153995 , I personally think the time has come to look at alternative approaches to building and managing GUIs on MVC principles. Superficial is my take on the problem, does anyone else have other suggestions?
Regards, David Wright http://superficial.sourceforge.net
|
|
|
|
|
java.net RSS
