Common MVC framework for a Swing or servlet UI?
Hello,
for a pet project (but I've seen this need in business projects too), I'd like to design a Java application unaware yet whether the final UI will be Web-based or Swing-based, and maybe both will be offered.
I have no practical experience of Struts, WebWork, SpringMVC, JSF, but from a superfical read, they all seem to focus on servlet-like UI.
I've found an example porting a web app based on Spring MVC to a Swing app but the guy used an additional layer (M2VC or something).
Do you know whether some of these frameworks allow the different view technologies, allowing to reuse model and controller code?
Do you have experience fulfilling of similar needs? Did you use such frameworks, or did you develop an ad-hoc design?
Thanks.
J.
[794 byte] By [
jdupreza] at [2007-10-2 9:19:23]
> Hello,
>
> for a pet project (but I've seen this need in
> business projects too), I'd like to design a Java
> application unaware yet whether the final UI will be
> Web-based or Swing-based, and maybe both will be
> offered.
Quite possible to do. The Swing and web UIs will both use the same services, that's all.
> I have no practical experience of Struts, WebWork,
> SpringMVC, JSF, but from a superfical read, they all
> seem to focus on servlet-like UI.
Yes, because they're all web UI frameworks.
> I've found an example porting a web app based on
> Spring MVC to a Swing app but the guy used an
> additional layer (M2VC or something).
The problem is that the Swing UI cannot be like the desktop examples you see in all the books, where the whole app runs in the same JVM. To be like the web UI, the Swing UI has to decide on a protocol to use to communicate to a remote server. Once you sort that out the Swing events just trigger messages sent to the remove server and unmarshalls the response into something sensible to it.
> Do you know whether some of these frameworks allow
> the different view technologies, allowing to reuse
> model and controller code?
None of those frameworks will help you with the Swing communication with the server, AFAIK. There's a Spring Swing UI project in the works, but I don't know what its status is.
> Do you have experience fulfilling of similar needs?
Not me.
> Did you use such frameworks, or did you develop an ad-hoc design?
See above.
If the Swing Listeners can turn events into HTTP requests and then unmarshal the HTTP responses that come back, you can have the Swing UI talk to the same servlets that the MVC-2 web UIs communicate with. All the communication code is encapsulated in the Listeners you write. Could be a good way to go. You just have to generate the same HTTP POST requests that an HTTP form would.
%
Oh, many thanks for taking the time, but I realize there was an ambiguity in my description:
> > for a pet project (but I've seen this need in
> > business projects too), I'd like to design a Java
> > application unaware yet whether the final UI will be
> > Web-based or Swing-based, and maybe both will be
> > offered.
Indeed I mean that the application will be either standalone, with an intra-JVM Swing UI, or server-based, with a Web UI.
> Quite possible to do. The Swing and web UIs will
> both use the same services, that's all.
Actually, I'd like that the controller code, that invokes the proper model logic, and dispatches to the appropriate view, be independant of the UI technology.
For an oversimplified example, the job of the controller, after a request has been handled and treated by the model, is to specify the name of the JSP to render the output. A web framework would use the name to look up the JSP class, whereas a hypothetical Swing framework would use the name to look up an applicative View class.
Without much investigation I confess, I believe that a fair number of interactions (mandatory fields check, master-detail hierarchy, sequencing of screens in a wizard) could be coded independantly of the view, while still not in the model (a model needs not know whether the "Create Account" wizard displays 3 or 4 steps).
> > I have no practical experience of Struts, WebWork,
> > SpringMVC, JSF, but from a superfical read, they
> all
> > seem to focus on servlet-like UI.
>
> Yes, because they're all web UI frameworks.
OK that's how I've always seen them presented, but for lack of practical experience, I wondered whether they could be applied independantly of the servlet API.
Obviously Struts is devoted to web UIs as the callback use the Servlet API.
But when people present SwingMVC and JSF as "view-agnostic", they indeed mean "Web-rendering-agnostic", but it's still tied to Web UIs and Servlet API?
Other than those, are there known frameworks that promise to make some non-model code reusable in web as well as standalone Swing UIs?
I seem to remember commercial products that did, couldn't find them on Google, but I'd rather stay within bounds of freely available stuff, at least for the "Pet project" part :o)
> Indeed I mean that the application will be either
> standalone, with an intra-JVM Swing UI, or
> server-based, with a Web UI.
Yes, that was clear.
> Actually, I'd like that the controller code, that
> invokes the proper model logic, and dispatches to the
> appropriate view, be independant of the UI
> technology.
Not possible. The Swing controller includes the Listeners, IMO. Those won't be part of your web UI. Everything from the servlet back can remain the same.
>
> For an oversimplified example, the job of the
> controller, after a request has been handled and
> treated by the model, is to specify the name of the
> JSP to render the output. A web framework would use
> the name to look up the JSP class, whereas a
> hypothetical Swing framework would use the name to
> look up an applicative View class.
And then do what with it? How is that View class sent back to the client? Serialized? As an attibute added to the request? That's what is missing.
Spring might be able to help here with its ModelAndView class.
> Without much investigation I confess, I believe that
> a fair number of interactions (mandatory fields
> check, master-detail hierarchy, sequencing of screens
> in a wizard) could be coded independantly of the
> view, while still not in the model (a model needs not
> know whether the "Create Account" wizard displays 3
> or 4 steps).
Mandatory fields check is validation.
Master-detail hierarchy? Not sure what you mean here.
Multi-screen wizards and page flow are certainly done for the web. Your problem, as you well know, is making all that machinery work for Swing in a generic way.
> OK that's how I've always seen them presented, but
> for lack of practical experience, I wondered whether
> they could be applied independantly of the servlet
> API.
No. Web UI implies HTTP as the protocol on the wire and a request/response idiom.
> Obviously Struts is devoted to web UIs as the
> callback use the Servlet API.
>
> But when people present SwingMVC and JSF as
> "view-agnostic", they indeed mean
> "Web-rendering-agnostic", but it's still tied to Web
> UIs and Servlet API?
Yes, still all web UIs, tied to servlets and HTTP. Agnostic in the sense that you can use different templating technologies (e.g., JSP or Velocity)
> Other than those, are there known frameworks that
> promise to make some non-model code reusable in web
> as well as standalone Swing UIs?
Here's what Spring is doing along those lines:
http://www.springframework.org/spring-rcp
%
> > Indeed I mean that the application will be either
> > standalone, with an intra-JVM Swing UI, or
> > server-based, with a Web UI.
>
> Yes, that was clear.
I don't think so : you seem to talk of the Swing UI as a "client" to some server JVM.
> > Actually, I'd like that the controller code, that
> > invokes the proper model logic, and dispatches to
> > appropriate view, be independant of the UI
> > technology.
>
> Not possible. The Swing controller includes the
> Listeners, IMO. Those won't be part of your web UI.
> Everything from the servlet back can remain the
> e same.
The listeners can be very basic, and just delegate to a Mediator using methods independent of the Swing listener APIs. I don't know if it's a degenerate form, but my mediators tend to become kind of controllers.
The hard part is merely making the view update without calls to the view API, which easy if the view is a mere observer, but a bit far-fetched when "another view" has to replace the current one (wizard, master/details,...).
> > whereas a
> > hypothetical Swing framework would use the name to
> > look up an applicative View class.
>
> And then do what with it? How is that View class
> sent back to the client? Serialized? As an attibute
> added to the request? That's what is missing.
The view class can be for example a JRootPane subclass, or merely contain a getContentPaneDisplay() method whose return value would be used as the content pane of some RootPane.
I understand there would be limitations to such an approach (in particular I don't dream about a hypothetical generic SwingUI framework) : of course the Swing UI would have to be "limited" to Web-like interactions.
> Spring might be able to help here with its
> ModelAndView class.
> Mandatory fields check is validation.
I don't want to start a debate; let's accept that in some cases it can be done at the controller level. In Web UIs, it's often done not to burden the model layer (e.g. EJB) with calls that are doomed from the start because e.g. the username is empty. Probably less of a concern for a single-node Swing app, but who knows, the model layer could connect to some legacy back-end...
> Master-detail hierarchy? Not sure what you mean
> here.
Maybe the term was wrong.
I mean, an inventory browsing app is often of the form "find all items that match <whatever>", then select any of the result to display its details...
The "DisplaySelectedItem" action has similar logic for the Web and Swing (fetch details data, specify the relevant view).
> Multi-screen wizards and page flow are certainly done
> for the web. Your problem, as you well know, is
> making all that machinery work for Swing in a generic
> way.
Again I don't mean to find a generic thing for all apps.
But a generic wizard can certainly be implemented as: whenever the user validate step N's form, prpocess it and if all goes well display step N+1. Each "step display" is a JRootPane containing some form widgets
> > But when people present SwingMVC and JSF as
> > "view-agnostic", they indeed mean
> > "Web-rendering-agnostic", but it's still tied to
> Web
> > UIs and Servlet API?
>
> Yes, still all web UIs, tied to servlets and HTTP.
> Agnostic in the sense that you can use different
> t templating technologies (e.g., JSP or Velocity)
Thanks for the clarification.
> > Other than those, are there known frameworks that
> > promise to make some non-model code reusable in
> web
> > as well as standalone Swing UIs?
>
> Here's what Spring is doing along those lines:
>
> http://www.springframework.org/spring-rcp
I promise to have a look. Thanks for the feedback and answers.
> I don't think so : you seem to talk of the Swing UI
> as a "client" to some server JVM.
Maybe I did miss it. If that's the case, I'd say you're really off base, because the two are fundamentally different.
> The listeners can be very basic, and just delegate to
> a Mediator using methods independent of the Swing
> listener APIs. I don't know if it's a degenerate
> form, but my mediators tend to become kind of
> controllers.
> The hard part is merely making the view update
> without calls to the view API, which easy if the view
> is a mere observer, but a bit far-fetched when
> "another view" has to replace the current one
> (wizard, master/details,...).
> The view class can be for example a JRootPane
> subclass, or merely contain a getContentPaneDisplay()
> method whose return value would be used as the
> content pane of some RootPane.
All of this already exists, but the fundaments of desktop and remote client/server are different enough where it might not be possible to unify them into a single framework.
> I understand there would be limitations to such an
> approach (in particular I don't dream about a
> hypothetical generic SwingUI framework) : of course
> the Swing UI would have to be "limited" to Web-like
> interactions.
>
> > Spring might be able to help here with its
> > ModelAndView class.
>
> > Mandatory fields check is validation.
>
> I don't want to start a debate; let's accept that in
> some cases it can be done at the controller level.
I thought the debate was the whole point. 8)
> In
> Web UIs, it's often done not to burden the model
> layer (e.g. EJB) with calls that are doomed from the
> start because e.g. the username is empty.
Always done in apps that I write.
> Probably
> less of a concern for a single-node Swing app, but
> who knows, the model layer could connect to some
> legacy back-end...
Why less?
> Maybe the term was wrong.
> I mean, an inventory browsing app is often of the
> form "find all items that match <whatever>", then
> select any of the result to display its details...
> The "DisplaySelectedItem" action has similar logic
> for the Web and Swing (fetch details data, specify
> the relevant view).
>
> Again I don't mean to find a generic thing for all
> apps.
Sorry, that's what I keep thinking you're trying to do. That's what "common" means to me. Your subject line is misleading, IMO.
> But a generic wizard can certainly be implemented as:
> whenever the user validate step N's form, prpocess it
> and if all goes well display step N+1. Each "step
> display" is a JRootPane containing some form widgets
> I promise to have a look. Thanks for the feedback and answers.
Sorry I'm not more helpful.
%
> I'd say
> you're really off base, because the two are
> fundamentally different.
> All of this already exists, but the fundaments of
> desktop and remote client/server are different enough
> where it might not be possible to unify them into a
> single framework.
OK, my point was not initially to demonstrate whether it was possible or not,
but whether such things existed. This topic closed.
> > Again I don't mean to find a generic thing for all
> > apps.
>
> Sorry, that's what I keep thinking you're trying to
> do. That's what "common" means to me. Your subject
> line is misleading, IMO.
You're right. I rather meant to "find a framework that enables to build certain kinds of apps
regardless of the UI".
Indeed over the course of the discussion, I realized that such apps
would probably have to be restrained to screen-by-screen interactions,
which is the regular way of Web apps, but appears very limited for Swing apps.
Is that why you meant by "fundamentally different"?
By screen-by-screen I mean:
- the user gets a screen displayed
- he can modify a few things in that screen without invoking the model under the hood
(filter, fill fields, etc...)
- when he's done with that screen, he uses some trigger (link, button, menu)
- this invokes under the hood the controller and model
- the outcome is a new screen
In this model the view is not an observer of the model, it is really driven by the controller
Without more study, more dynamic interactions (autocompletion, preview, result scrolling,...)
appear to be handled quite differently in Web apps vs Swing.
Maybe the outcome of our discussion is a characterization of apps eligible
to such a "common" design, or framework.
Anyway I think I'll start a new topic instead,
devoted to how to start designing my specific application
so that its UI can be either Web or Swing.
Off-topic: a few comments on your remarks:
> > > Mandatory fields check is validation.
> >
> > I don't want to start a debate; let's accept that in
> > some cases it can be done at the controller level.
>
> I thought the debate was the whole point. 8)
OK you're kidding, but I meant I didn't want to start a debate on
"where to put validation logic" (I assumed you implied "validation must be at the model level").
> > Web UIs, it's often done [at the servlet/controller level] not to burden the model
> > layer (e.g. EJB) with calls that are doomed from the
> > start because e.g. the username is empty.
>
> Always done in apps that I write.
OK.
> > Probably
> > less of a concern for a single-node Swing app
>
> Why less?
Well I see 2 reasons to perform part of this validation at the controller level.
Order meaningless:
1 - Performance. Avoid to invoke the model layer uselessly, when it will be costly (EJB, remote, DB).
2 - Ease and quality of programming. Model layer is much easier to write maintain when it can assume that the data it works on is valid
(no stupid null-checks, empty-checks,...).
2 of course applies to Swing apps as well.
But 1 may not always be such a concern, when the model triggered will work in-process on local in-memory data.
As not all kinds of validation can be performed at the controller level (e.g. check that customer is entitled to 24x7 support before entering his ticket),
some validation logic will probably have to exist at the model level anyway,
so I can understand that some design put ALL the validation there.
See? Debate started... you tricked me! :o)
Forget it! I don't do this anyway.
