Why no GUI Design Framework?

[K Riaz]

For web applications, we have many frameworks available to help build our software (Struts, Hibernate, Spring etc), but why is there nothing for writing GUIs? Why not something which will help us properly apply some sort of MVC framework and separate logic from presentation? Is there nothing more than guidelines? Some sort of container and easy to maintain event handler for each component would be useful.

What is the best way to write a GUI application? Should you just create your logic-handling classes separate from the GUI classes and provide the correct method (from your logic class) for each event handler, for each GUI component?

[Pat Hays]

Hi Kashif

You may try JFrameBuilder

[Alex Kravets]

But isn't it true that all those MVC Frameworks were made to work on different media? If you have your models and controllers you can define your view even if it's Swing.

Alex

[Glenn Murray]

 

Originally posted by Kashif Riaz:

For web applications, we have many frameworks available to help build our software (Struts, Hibernate, Spring etc), but why is there nothing for writing GUIs? Why not something which will help us properly apply some sort of MVC framework and separate logic from presentation? Is there nothing more than guidelines? Some sort of container and easy to maintain event handler for each component would be useful.

I don't quite understand this question---Swing is a GUI design framework
and Hibernate and Spring support writing GUI's in Swing just as much
as they do in web applications, that is to say, not at all, since they
have to do with persistence. Swing is designed to separate logic
from presentation and it will happen pretty much automagically if you
are programming in a test-driven style.

What is the best way to write a GUI application? Should you just create your logic-handling classes separate from the GUI classes and provide the correct method (from your logic class) for each event handler, for each GUI component?

If you're programming in a test-driven style then you will find that the
logic separates itself from the view. If you are doing unit testing at
all then you'll find yourself putting logic in separate classes because
it is more problematic to unit test gui classes. If you are not doing
unit testing consider starting.

That said, a rule of thumb that I use for event handling code is that
if it changes the GUI in a shallow way. e.g., disabling a button, I
tend to leave the code in the GUI class. If it changes data or uses
business rules, then I want to unit test it and will pull the code
out of the GUI class.

Cheers,
Glenn

[K Riaz]

Thank you.