Best Java web framework
-
I know this is a bit of a religious issue for some, and I don't want to start a flame war, but this is something I've had to research a bit recently and I was wondering what other people's thoughts were.
There seems to be a huge proliferation of Java web frameworks out there at the moment: Struts 2, JSF, Spring MVC / WebFlow, Tapestry, Wicket...
A month ago I started a new project at work based on JSF and IceFaces (JSF was mandated due to the choices made on a previous project). I've used JSF a couple of times before and and it's alright, but there are definitely problems with it.
I came across Wicket yesterday which seems pretty good. But I've been wanting to try out Spring WebFlow for a while, as I like the idea of flows (one problems with JSF is there is no "conversation" scope).
Anyway, I was thinking of starting a new home project sometime soon, and I thought I'd ask to see if people had thoughts on the relative pros and cons of the various different frameworks.
-
ColdFusion all the way. It runs on Java and is completely invulnerable to buffer overflows. Also, combining your view, business and data logic in the same code is the newest paradigm for web development.
-
@morbiuswilters said:
ColdFusion all the way. It runs on Java and is completely invulnerable to buffer overflows. Also, combining your view, business and data logic in the same code is the newest paradigm for web development.
You forgot how elegant it is.
-
@PhillS said:
I came across Wicket yesterday which seems pretty good.
Apache writes a new Java framework every month, seems like. How about making Struts suck less and calling it a day?! Although Wicket looks intriguing. Are they finally catching on to the fact that RoR is popular because it tries to make things less cumbersome?
-
well there's JRuby. write your RoR app and then run it in the JVM.
-
Has anyone heard of (or even experience with) ZK?
-
Apache doesn't "write" frameworks, it's a community of developers/ projects and most projects in there started out outside of Apache.
Anyway, people are trying to make Struts suck less; see their 2.0 version. Personally, I think it's a lost battle, because the whole concept of 'Web MVC' is just wrong. Read the first (and free) chapter of Wicket In Action if you want to have my take on it.
-
@chillenious said:
Apache doesn't "write" frameworks, it's a community of developers/ projects and most projects in there started out outside of Apache.
Anyway, people are trying to make Struts suck less; see their 2.0 version. Personally, I think it's a lost battle, because the whole concept of 'Web MVC' is just wrong. Read the first (and free) chapter of Wicket In Action if you want to have my take on it.
Gentlemen, we are in the company of genius. Please shower your intelligences upon us, oh great Chillenious!
-
@morbiuswilters said:
oh great Chillenious!
Yeah, but what a great frist post!
BANG! First post, and we immediately know he is a genius!
-
Such an impact already! Very classy to thank me that promptly kids.
-
@chillenious said:
Read the first (and free) chapter of Wicket In Action if you want to have my take on it.
Congratulations: you've managed to make a Java clone of asp.NET's MVP (Model-View-Presenter) architecture, although with a few flaws snuck in. Flaws like requiring the manual instancing in the page's backend code of controls/components present in your HTML layout and manually linking them through a weak string-matching reference. Or flaws like dismissing RESTful, aka state-preserving, pages as a simple optimization and only treating the naive case of directly preserving state in the URL. (Hint; take a look at asp.NET's viewstate system which works through an encrypted hidden form field which is automatically (de)serialized for the application programmer by the framework...)
As for your framework's usefulness; enterprise level asp.NET developers have been anxiously anticipating the asp.NET MVC framework (to ship with VS2008 SP1, iirc) for some time now, as it will allow for an altogether better decoupling and tiering of the various application components, making the development of modularized 'plugin' web applications much easier and simultaneously allowing for better integration into unit test frameworks and more elegant handling of asynchronous postbacks.
The argument you make against MVC is actually laughable when considering the section you write on AJAX in the first chapter of your book. An MVC approach would have the Controller processing an Ajax request, by manipulating data retrieved from the Model and forwarding it to the View to format into whatever the client website expects back (XML, XHTML, etc.). Much more elegant than having to manually match tags in pages to do partial page updates on a page that serverside is still interpreted as a complete synchronous postback as you are suggesting!
Basicly, Wicket is a case of reinventing the square wheel and a case of 'too little, too late'.
PS:
You might also want to contact your digital distributor; the PDF of the first chapter that you offer up for download contains no copyright information on Google, which I believe is quite the prerequisite for a commerical work that includes images of copyrighted material like Google's website.
-
Wicket's goal is to provide a 'regular' Java OO programming model. So yeah, instantiating objects yourself, objects are stateful by default, stuff like that. Whether it is your taste of not, there is no web framework like it. "the naive case of directly preserving state in the URL"? Oh if it's a post it's very different, right? I hated the viewstate construct when I did ASP.NET projects. And I had to profile an ASP.NET app a while ago that had over a meg of serialized viewstate in a page. WTF. Oh, and there were pages that the editor in VS couldn't handle and crashed VS. ASP.NET served as great input for us how not to do things. And yeah, AJAX + web MVC works a lot better, but if you go AJAX all the way, why not choose GWT and write services instead of controllers? Besides, building your whole site using AJAX isn't always the best or even available option, and if isn't, my experience is that Wicket gives a much better handle for dealing with complexity.
-
Disclaimer: All I know about wicket is from the free "Wicket in Action" chapter and a few pages of the wiki.
While I perfectly understand the motivation for making wicket the way it is, it seems to me that it puts some constraints on the applications built with it. While those supposed constraints are acceptable for a wide range of applications, it might be a problem with other applications. My main concern is dynamic layout. As I understand it, wicket uses its sophisticated ListView for repeated content. For some kinds of applications, that isn't enough. E.g. a content management system might want to let its users define layouts dynamically, like in "Heading on top, a picture on the right, some text left to the picture, more text below the picture, then a list of links to related pages." I fail to see how that could be done in wicket.
-
If you would use Wicket, you would typically implement layout using panels, fragments (inline panels) and markup inheritance. Repeaters (of which ListView is one variant) take care of repeated content. For flexible layout, there aren't any limitations really. You build up your component tree dynamically (one of the advantages of letting users instantiate their components), and you can replace components at run time. The only catch with the latter is that the component hierarchy and markup hierarchy need to match. But you can work around that by using panels or fragments. You can find a simple example of that in the wicket-examples project; it's named 'template' (package org.apache.wicket.examples.template).
If you're interested in building a CMS system and would like to know what that would look like with Wicket, a couple of guys just started up such a project.
I think a more typical reason to not use Wicket would be if your site's UI is very straightforward, or if you can go AJAX all the way and bookmarkability etc isn't very important for you. In that case, something like GWT might be a better mach. Or just do it yourself with YUI or something similar. Imho, Wicket is a good match if you build at least part of your application without AJAX and if your UI is complex (wizards, pageable lists, nested tabs that hold state, etc).
And FWIW, another framework that I like is Lift, which is built on Scala.
-
Web MVC is an insufferable concept that must die. Once upon a time the GOF wrote about a pattern called MVC. Not that complicated, but useful. Now, somehow, it became the basis for all web based frameworks and actually has little to do with the original MVC. A controller used to be a graphical control that responded to both the changes to the data, and to user events. Now its some routing mechanism for web-requests. It's stupid. Stop it now.
-
@chebrock said:
Web MVC is an insufferable concept that must die. Once upon a time the GOF wrote about a pattern called MVC. Not that complicated, but useful. Now, somehow, it became the basis for all web based frameworks and actually has little to do with the original MVC. A controller used to be a graphical control that responded to both the changes to the data, and to user events. Now its some routing mechanism for web-requests. It's stupid. Stop it now.
I suggest taking a look at the original paper on MVC by Burbeck. He clearly states that:
"The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller)."
I don't see any mention of the controller being a graphical control.
What you describe matches closest to MVP (model-view-presenter), a derivative of MVC that more tightly binds the MVC concept of controller and view together into the presenter. The view in MVP is merely the common interface by which a set of presenters can communicate with the model. This is the paradigm the asp.net framework uses.
Think about the following as well: In web programming the MVC view represents the resulting page. It is one of the controller's tasks to command the view to change. That makes it natural for the controller to (partly) be a routing mechanism for requests. Infact that's all a controller is ever supposed to do: control, not act!
-
@chebrock said:
Web MVC is an insufferable concept that must die. Once upon a time the GOF wrote about a pattern called MVC. Not that complicated, but useful. Now, somehow, it became the basis for all web based frameworks and actually has little to do with the original MVC. A controller used to be a graphical control that responded to both the changes to the data, and to user events. Now its some routing mechanism for web-requests. It's stupid. Stop it now.
Actually, MVC is not one of the patterns described in the GoF book, though it might be mentioned therein since it is the most commonly cited example of a pattern that was well-known before the book.
-
I suggest taking a look at the original paper on MVC by Burbeck. He clearly states that:
I'm sure many of us read that. As it often goes with such acronyms, over the years people attached various meanings to it, and it lives it's own live. You can bend it to be something like 'Web MVC' (which I believe was coined by people from Sun when they described the 'model 2' way of development which is the same thing). However, web MVC used in the way it's been used for years now (read: without Ajax) horribly breaks encapsulation for all of the simplest cases.
Think about the following as well: In web programming the MVC view represents the resulting page. It is one of the controller's tasks to command the view to change. That makes it natural for the controller to (partly) be a routing mechanism for requests. Infact that's all a controller is ever supposed to do: control, not act!
Whether that interpretation is valid or not, Web MVC doesn't give us better abstractions. Unless you're building really simple stuff or adopt Ajax all the way (in which case you can get back to widgets with their own views, but in which case I would prefer to have all of the widgets on the client side and let them communicate with services), page orientation isn't helpful for building web applications. It's unfortunate so many people still seem to disagree with that, though the tide is turning (also due to frameworks like ASP.NET which do provide a good means to abstracting the UI and which are not in the category of Web MVC frameworks as most people understand it).
-
Two points. GOF does mention MVC in the introduction. Second, you're right, it's not specifically mentioned as a graphical control, but it is tied to the concept of input, not routing.
-
@chebrock said:
Two points. GOF does mention MVC in the introduction. Second, you're right, it's not specifically mentioned as a graphical control, but it is tied to the concept of input, not routing.
Routing is the changing of view (since pages are views), which is part of a controller's job: changing the view and/or model based on the input the controller receives.
-
One thing that always confuses me about the standard MVC. Say you have a graphical slider. The slider can respond to user input, but needs to also update in response to changes to the model. Is that considered a controller or a view?
-
@chebrock said:
One thing that always confuses me about the standard MVC. Say you have a graphical slider. The slider can respond to user input, but needs to also update in response to changes to the model. Is that considered a controller or a view?
That would be the controller.
-
@chillenious said:
That would be the controller.
Yes, I would say that too but it's a blurry issue. The controller is acting like a view in that it responds to external changes in the model. I feel like this is a flaw in the concept of the pattern.
-
@chebrock said:
@chillenious said:
That would be the controller.
Yes, I would say that too but it's a blurry issue. The controller is acting like a view in that it responds to external changes in the model. I feel like this is a flaw in the concept of the pattern.
Well, the original definition says: "The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate."
So it is the responsibility of the controller to update the view when the model changes. In practice though, certainly when it comes to web frameworks, I think the controller is often bypassed and the view 'pulls' it's recent values (and thus any updates) without needing the controller directly. And yeah, it does get blurry pretty fast :-) Personally, I prefer to use patterns as rough ideas of how certain problems can be solved rather than exact descriptions.
-
@chillenious said:
I prefer to use patterns as rough ideas of how certain problems can be solved rather than exact descriptions.
That about sums up good use of patterns.
-
Try with Appcelerator! it is a fast, elegant and simple web develoment framework based on soa like services and support for Java, PHP and others.
url: www.appcelerator.com
