Discussions

A new article by Kris Thompson walks you through the development of the Wafer weblog application using the WebWork 2.x release and covers many of the basic features of WebWork2. Using extensive code samples, he looks at how to configure the framework, describes Interceptors, Field Driven and Model Driven Actions, the Inversion of Control pattern, Validation techniques, and various other features.

WebWork boosts a lot of interesting features, but what happened to KISS? In the world of J2EE complexity, a framework like Folium(shameless plug) or other frameworks that have simplicity at their core have a lot to offer.

Frameworks are suppose to make things easier, but it seems that in a lot of ways Struts/WebWork are more complicated then they need to be. What are your thoughts?

I guess simplicity is all relative and I think it is only fair to use Struts as the baseline since it is considered by many to be the "standard" MVC. So having said that WebWork *is* much easier to work with (here comes the holy war). Comparing WebWork to say ASP.NET or PHP well maybe it does hold more structure then they do hence adding more more complexity but that can be a bonus too depending on the application you are trying to construct and other factors like growth, usage, etc.

Thanks for the link. I'll add that to my list of frameworks which now shows 34 web frameworks! Amazing! Inovation rocks!

Actually I was to suggest a framework solution for my project but I feel the initial feel of WW2 is a bit confusing.Although Kris has recommended WW as a framework that one needs to choose if selecting on one framework you want to learn...I still struts has a lot of comfort factor associated with it.

WebWork boosts a lot of interesting features, but what happened to KISS? In the world of J2EE complexity, a framework like Folium(shameless plug) or other frameworks that have simplicity at their core have a lot to offer.

>
> Frameworks are suppose to make things easier, but it seems that in a lot of ways Struts/WebWork are more complicated then they need to be. What are your thoughts?

Well, I don't know anything about your framework, but I can tell you that XW/WW2 is exactly as complex as it needs to be to provide the power that it does, and no more. It's actually VERY simple for doing the standard things (define a default interceptor stack and you don't have to specify them per Action, for instance) and makes very complex things not only possible but pretty darned simple too (especially compared to what you need to do in other frameworks).

Having worked with many frameworks myself and having build and help build 4 of these wafer weblog applications WW2 MVC is one of the easiest/most flexiable. However if you want KISS then throw out the whole MVC and code the MS way with ASP.NET. I'm doing that right now and it is making me quite depressed having just come off of this WW2 project. Live long MVC!

For you information, ASP.NET does support MVC (it's based on the Page Controller design pattern), actually it's the recommended MS way, if I am not mistaken. And it is also simple. Just good design. Unfortunatelly, we in the Java community (me included, I am not an MS developer) have to live with MVC frameworks which are based on not so good designs.

In my experience, xml config files quickly become a maintenance headache. Why bother with the XML config at all? The config's always duplicate information that is already in the class itself. For instance, return "codes" such as "success" or "display" simply provide another name for a url. Why not just use the URL? There is no need to give a new name to something that already has a perfectly good name. Same thing with renaming class names to action names. It is a royal pain to keep "action names", class names, and url paths in web pages in synch, especially when people can arbitrarily name actions. I can hear the academic types now mumbling about "separation". Separation is also possible in code, but unlike XML, you have the full facilities of an OO language at your fingertips.

People claim that xml configs are wonderful b/c you can change the config at runtime. In theory, this may be a wonderful idea, but in practice it is rarely if ever done. If it is hard to redeploy your app, then you need to revaluate your build process.

My current preferred web MVC architecture simply requires developers to extend a BaseAction. That is all. The forwards are all validated during build time. You can easily extend, chain, etc. to your heart's content. The simple architecture I use is the result of too many debugging sessions wondering why Struts can't load my action instance. Once I dropped the struts xml config. The other developers cheered.

In your framework, how do you chain actions, declaratively or programatically? For example, say I have actions A, B, C and D. Now, say for a particular request I want to do A and C. How would you do this? Create another class that directly calls A and C? Or declare (by some external means, such as XML) another action that is composed of A and C?

I could do it programatically, but I actually never need to chain actions b/c I find that the "chaining" logic should be in the business code where it belongs (do steps 1,2,3 in that order or just do 1 and 3), not in an xml config. It is easier to do this chaining in code then return a magic string to a controller that does the exact same thing far less efficiently.

Hmmm. I prefer to be able to chain actions together declaratively. Quite often, a request requires many different things to happen (verify user is logged in, process user's form, load navigation, etc). For me, it is nice to have each distinct action in its own class and be able to declaratively chain them together how I want.

Programmatic chaining clutters things up for me. If I have an AddItemToCartAction, here is what the body should look like:

In my experience, xml config files quickly become a maintenance headache. Why bother with the XML config at all? The config's always duplicate information that is already in the class itself. For instance, return "codes" such as "success" or "display" simply provide another name for a url. Why not just use the URL? There is no need to give a new name to something that already has a perfectly good name. Same thing with renaming class names to action names. It is a royal pain to keep "action names", class names, and url paths in web pages in synch, especially when people can arbitrarily name actions. I can hear the academic types now mumbling about "separation". Separation is also possible in code, but unlike XML, you have the full facilities of an OO language at your fingertips.

>

Maintaining your navigation and page flow in one place as opposed to N places is very valuable. You can also use your xwork.xml to generate documentation and graphs (which a more than one person has working now) which can help you visualize your web application nicely.

> People claim that xml configs are wonderful b/c you can change the config at runtime. In theory, this may be a wonderful idea, but in practice it is rarely if ever done. If it is hard to redeploy your app, then you need to revaluate your build process.
>

You should try running a servlet engine like Resin inside your IDE. It makes you very productive. With our config file reloading support, you can edit your config files and have the changes show up immediately.

> My current preferred web MVC architecture simply requires developers to extend a BaseAction. That is all. The forwards are all validated during build time. You can easily extend, chain, etc. to your heart's content. The simple architecture I use is the result of too many debugging sessions wondering why Struts can't load my action instance. Once I dropped the struts xml config. The other developers cheered.
>
> Goodbye XML, hello productivity.

Well, I understand your frustration with having to use Struts, but that doesn't mean you should go to the opposite extreme. Loosely coupling classes is very valuable, and centrally managing the application flow is the only way to do it for large sites. That's not to say we don't split up our configuration files, we do, but they should be broken into logical pieces, not scattering configuration throughout every Action class.

Keep in mind that if you don't like XML, you can write your own ConfigurationProvider, which can just be hard-coded (we do these for our unit tests)

People claim that xml configs are wonderful b/c you can change the config at runtime. In theory, this may be a wonderful idea, but in practice it is rarely if ever done. If it is hard to redeploy your app, then you need to revaluate your build process.

I think the real power of the XML config file is being a centralized location for understanding the flow of the site. This helps in having new developers work on the code who were not part of the initial build team. This doesn't havve to be XML. I agree that the power of dynamically changing flows is overrated but the centralized depot of this information is NOT.

People claim that xml configs are wonderful b/c you can change the config at runtime. In theory, this may be a wonderful idea, but in practice it is rarely if ever done. If it is hard to redeploy your app, then you need to revaluate your build process.

>
>
> I think the real power of the XML config file is being a centralized location for understanding the flow of the site. This helps in having new developers work on the code who were not part of the initial build team. This doesn't havve to be XML. I agree that the power of dynamically changing flows is overrated but the centralized depot of this information is NOT.

People claim that xml configs are wonderful b/c you can change the config at runtime. In theory, this may be a wonderful idea, but in practice it is rarely if ever done. If it is hard to redeploy your app, then you need to revaluate your build process.

> >
> >
> > I think the real power of the XML config file is being a centralized location for understanding the flow of the site. This helps in having new developers work on the code who were not part of the initial build team. This doesn't havve to be XML. I agree that the power of dynamically changing flows is overrated but the centralized depot of this information is NOT.
>
> I think it easy to understand too:
>
> static {
>
> mapping( RE1, MyCommand1.class );
>
> ..................................
>
> mapping( REn, MyCommandn.class );
>
>
> }

I agree, whether it's xml or programmatically I don't mind. As long as it is centeralized. Just don't do it programmatically all over the place.

Instead of scattering the authorization code around the application code in the example, you have to scatter a lot of meta data config around your configuration file. This I think is not a good idea because AOP has provided a way to consolidate this crosscutting.

I recently spent a lot of time getting the migration support done. The end result is:

* the old EL is "magically" converted to the new EL in real time (if you turn that option on)
* the old classes (it the webwork.* package) will be included in a webwork-migration.jar to help with compiling against the new version
* 100% of the taglibs have been migrated, with the TLD being a drop-in replacement, so migrating tags is a non-issue
* support for views.properties and actions.xml (the old config files) will be included in webwork-migration.jar

Overall, migration looks to be not nearly as much of a challenge as previously thought. We'll be trying out some test projects shortly to proove this theory :)

Why did you choose to follow the Model 2 MVC design (which is based on the Front Controller design pattern)? IMO, this is a fundamentally flawed design, because it forces the framework user to define an artificial URL for nearly every HTTP request. For example, instead of a URL like

Why did you choose to follow the Model 2 MVC design (which is based on the Front Controller design pattern)? IMO, this is a fundamentally flawed design, because it forces the framework user to define an artificial URL for nearly every HTTP request. For example, instead of a URL like

>
> /hr/employee.jsp?action=save
>
> you are forced to create one, such as
>
> /hr/saveEmployee.do
>
> and then map it to the appropriate Java class.

If you have /hr/employee.jsp?action=save, what would this map to? Who would handle this request? The JSP?

If you have /hr/employee.jsp?action=save, what would this map to? Who would handle this request? The JSP?

It would map to the <context-path>/hr/employee.jsp web resource (i.e., .jsp file). If using an MVC framework based on the Page Controller pattern, the request handling would be delegated to a POJO instance, as specified by a JSP custom tag at the top of the employee.jsp file.

Let's take your example, saving an employee. There are two obvious paths this action can take:

- the data is valid and the employee is saved
- the data is invalid and needs to be fixed before saving

Now, what if these two paths end in two different displays (former displays the employee data on a page, latter takes you bach to the employee form)? How does the "Page Controller" pattern handle this? Pardon my ignorance, I have never heard of this design.

It's great to see MS giving proper recognition to Fowler's work. Now, if we could only get the Java folks to do the same...

I don't quite agree with everything they say in this article, tough. The Front Controller is definitelly more complex, but I am not so sure it's more powerful.
The only true advantage over Page Controller, it seems, is that one can map an URL directly to an Action class or method, without incurring an extra "action=doSomething" request parameter. Not much of an advantage, I would say. (Note that the standard web.xml file allows the mapping of URLs to Servlets and JSP resources.)

>
> Let's take your example, saving an employee. There are two obvious paths this action can take:
>
> - the data is valid and the employee is saved
> - the data is invalid and needs to be fixed before saving
>
> Now, what if these two paths end in two different displays (former displays the employee data on a page, latter takes you bach to the employee form)? How does the "Page Controller" pattern handle this? Pardon my ignorance, I have never heard of this design.

No problem. With Page Controller, there would be 2 ways to do this:
1) Simply declare the next page to go, when data is valid, in the JSP custom tag responsible for submitting the HTML form. This would be preferable in this case, because the next page for successful processing is known at design time. For the validation failure case, you could use either a JSP errorPage, or let the employee.jsp file itself print out error messages at the appropriate places in the page.
2) Use the Application Controller design pattern, to which the Page Controller delegates this decision. This would be appropriate when the next page depends on some business rule, and therefore can't be determined at design time.

These patterns are described in Martin Fowler's book, "Patterns of Enterprise Application Architecture". The Application Controller is also described (although not so clearly, IMO) in the "Core J2EE Patterns, 2o. edition" book.

What about a request where the view is not determinable until you have the model? Let me give you a use case from a site I worked on...

When a user clicks on a product category, the system retrieves the category and...
- if the category has sub-categories, show these sub-categories
- if the category is a leaf, show its products

I don't see how you could link to a specific JSP page and handle this elegantly. Personally, I thinking linking to a JSP is bad in almost all but the most trivial cases. You should link to a URL to abstractly represents the request. These can transparently translate to a JSP (/home -> home.jsp) in the beginning. But this adds enough abstraction so that you can change to behavior of your requests without having to change all of you links (or links on other web sites). Down the road, you can add new behavior to the /home request without touching any JSPs.

What you are saying and what the MS "Page Controller" article desribes sound like two different things.

What about a request where the view is not determinable until you have the model? Let me give you a use case from a site I worked on...

>
> When a user clicks on a product category, the system retrieves the category and...
> - if the category has sub-categories, show these sub-categories
> - if the category is a leaf, show its products
>
> I don't see how you could link to a specific JSP page and handle this elegantly. Personally, I thinking linking to a JSP is bad in almost all but the most trivial cases. You should link to a URL to abstractly represents the request. These can transparently translate to a JSP (/home -> home.jsp) in the beginning. But this adds enough abstraction so that you can change to behavior of your requests without having to change all of you links (or links on other web sites). Down the road, you can add new behavior to the /home request without touching any JSPs.

This actually is a use case for the Application Controller design pattern, which assumes the responsibility of choosing the next page to render after a request is handled. Actually, it's simpler than that. The Application Controller object, in the method that process the incoming request, could delegate to an Application Controller object that decides what the next page should be, and communicates it back by returning the path to the .jsp file. The Application Controller implementation could be configured through a config file (web.xml or a non-standard XML file); you could also embed it in the Application Controller class itself.

I think one of the great advantages of the Application Controller pattern is that it allows for the "default page" (that is, the page targetted by the request is the same that gets rendered), which is not supported at all in "Model 2 " frameworks, which require almost all HTTP requests to be forwarded/redirected from the central Servlet to a .jsp file (also a Servlet). With Page Controller, this forwarding/redirection only happens when actually needed. In my experience with web apps, the use case you described is the exception, rather than the rule. In fact, default pages are very common. Most page navigation IS static (known at UI design time), and not just in simple or small web apps.

> What you are saying and what the MS "Page Controller" article desribes sound like two different things.

Yes, we seem to have somewhat different views on the Page Controller pattern. Aparently, they don't talk about the complementary "Application Controller" pattern (AFAIK, ASP.NET has no direct support for it). I will comment more after I finish reading the MS articles.

Well, from what you indicated earlier, it sounded like the custom tag was helping prepare the model for the JSP page that was directly reffered to in the URL. Is that right? If so, I disagree with this approach.

For me, custom tags are "helpers" for the JSPs. They remove all of the nasty code from JSPs and place them is reusable components. IMO, they are not to be used to communicate with the back end systems at all. When a request gets to the view layer, the model is ready to be rendered. That is what views do. Having objects in the view turn around and process the request to prepare the model seems quite backwards to me.

Regarding your most recent post, I still am not clear on the flow of the request. You originally eluded to linking directly to a JSP page. Now you are talking about Application Controllers and Page Controllers. How does this fit together, or are they two different scenarios?

Well, from what you indicated earlier, it sounded like the custom tag was helping prepare the model for the JSP page that was directly reffered to in the URL. Is that right? If so, I disagree with this approach.

Hmm, yes and no. The custom tag only calls the appropriate methods on the controller class, and after these return, it either lets the .jsp in which it is contained be rendered, or forwards the request to the web resource indicated by the controller. The controller object is responsible for calling the domain model in order to perform business operations, and to populate the presentation model with the data needed to render the view.

> For me, custom tags are "helpers" for the JSPs. They remove all of the nasty code from JSPs and place them is reusable components. IMO, they are not to be used to communicate with the back end systems at all. When a request gets to the view layer, the model is ready to be rendered. That is what views do. Having objects in the view turn around and process the request to prepare the model seems quite backwards to me.

I guess we agree on this. In the framework I propose, the JSP custom tags never communicate with the (domain) model (a.k.a. back end systems), only with the controller object and helper objects created by the controller.

> Regarding your most recent post, I still am not clear on the flow of the request. You originally eluded to linking directly to a JSP page. Now you are talking about Application Controllers and Page Controllers. How does this fit together, or are they two different scenarios?

These are two different design patterns which normally work in conjuction. The Application Controller can also be used with the Front Controller pattern. In most use cases, however, there is no need to use an Application Controller, or it's so simple that could be embedded in the Front/Page Controller itself.
So, the Application Controller (as explained in a previous post) takes care of any logic and configurability needed in those rare cases where page flow is truly dynamic. I would like to point out, however, that in many cases where people claim to need "dynamic page flow", they are really doing over-engineering, since the page flow is really static, that is, it still is specified at design time. Also, the argument that a web resource (usually a .jsp file) can be requested in so many places that changing its name or path is not practical, is a very weak one; in reality this does not usually happen, for pages of specific purpose, such as "employee.jsp" (the URLs to common pages such as menus can and should be factored out using static includes, or some templating mechanism).

Isn't there also a weakness in that the links point to a specific JSP? If you need to rename or move that JSP, or use a different JSP, you have to do a search and replace. The MS article on Page Controller mentions this too, and says their code-behind technique makes Page Controller viable.... unless you can make do with one controller per page, which the article admits is a limitation of Page Controller.

Looking at the example of MS MVC, there seem to be a few questionable things that might make life easier in the short term, but they break separation of concerns - the aspx page specifies the specific controller class to use (if you repackage or rename classes, you're doing a search/replace, as opposed to just editing a single config file), the controller is tightly bound to web controls (not the case in Webwork, and how do you test this easily?), and the controller is referencing the names of database fields. Again - that's all fine for a small application where changes aren't expected, but I think those decisions can lead to major problems later in a larger application. Kinda typical of MS's M.O. - make the common stuff easy to do, but good luck when the brown stuff hits the fan.

I'd argue that search and replace, for file names at least, is a better solution than a configuration script and corresponding monitor, parser, propogator, and error handler. Most config files (even especially XML) have a higher barrier to entry than even compiled java classes. How much easier it would be to edit and run a quick javac (or ant task?) on

and then restart whatever service reads the xml on init. At the very least, the java code is easier to read. The real problem, though, is that the config format will be different for every single application.

Search and replace is a solved problem. And, if it becomes complex and repetitive, a script could be written to do it for you, which would actually be easier to maintain, and more robust than your config files and config activation code in your build script config file.

In the example I gave of using a virtual URL instead of the physical URL, you would still do a search and replace when the physical URL changes - but you only do it in the configuration file for your MVC framework, and you don't have to worry about what pages might reference the physical URL since they're all using a virtual URL. Virtual URL's are also helpful when an external application links to yours, as you probably can't do a search/replace on their code too.

At the risk of offending Mike Spille, if you're looking for a consistent format for configuring application objects, check out the Spring BeanFactory (and you can even use regular property files if you dislike XML so much). Your example is obviously skewed to make configuration files look awful, but I'd greatly prefer that to hard-coding database connection properties, JNDI references, mail session properties, and generally anything else that may change when you deploy an application from one environment to another.

I have to say that placing configurations in code is not the best way to go for a couple of reasons. First, if you change one property, you have to recompile. With most IDEs and build processes, the dependency checks are good enough that it won't slow down your build cycle much.

However, there is a *much* bigger problem with this. Your code is now *unreusable*. You can't use it cross-project. For every environment you run this in where properties differ, you have recomplie. No thanks.

And if you are going to try to make your "code is easier to read than XML" point, don't skew your examples - it doesn't help make you point. One could easily say XML is easier to read:

Wait a second. That XML is *much* more concise! I am not arguing the XML is easier to read. I am saying you example was silly. However, most XML editors allow for auto-complete, collapsing, etc that make editing XML quite easy. So does XDoclet (no editing!). But my point is not that XML is easy to edit, although it is nice that we have a standard structure. My point is that I think configs in code is a Bad Idea.

However, most XML editors allow for auto-complete, collapsing, etc that make

>editing XML quite easy. So does XDoclet (no editing!).

Off topic, I know, but lest anyone be confused by Ryan's mention of XDoclet here...You may think that tagging code for code-generation by XDoclet is akin to doing configuration directly in source code. And it is, if you do it the naive way (e.g., hardcoded attribute values on your tags). But be aware that you can also use Ant properties as values for XDoclet attributes, making your code reusable when used with a unique set of properties per deployment.

Now, ever so slightly back on topic: XDoclet does have a module for WebWork, but it is the old WebWork, not WebWork 2. I was pondering the notion of updating it to support WebWork 2. If nobody else beats me to it, I may write add WebWork 2 support to XDoclet in the next few days. I've looked over what needs to go into the xwork.xml file and it doesn't look like it'd take much effort.

Ok, the conversation is already over, but . . . it seems like we're trying to trade off the values of centralized versus local configuration of M with V with C.

The benefit of centralized configuration is you can see everything in one place, so there's one place to go when you want to know which Controller a particular URL maps to, and which JSPs are used for the view, and which bean is used for the form, etc.

On the other hand, what a pain in the butt it is when you're looking at a controller class, and you want to know which JSP is actually being routed to. You have to go find that stupid XML config file and look it up. You're more likely to keep things consistent if you don't have to go do that every time you make a modification to a controller class (because you probably won't look at the config file every time, unless you have OCD). What a pain in the butt it is to have to look at that XML config file when you want to know which controller class is handling the URL that isn't working.

The problem with xml configuration files is all that indirection, which on most projects staffed with OCD-less developers will lead to inconsistency. Putting your configuration parameters in an Ant properties file seems even more indirect. Using XDoclet to produce a centralized XML file from localized, hard-coded configuration attributes seems a good compromise between local and centralized config.

On a final note: there certainly are benefits of declarative configuration (esp. for cross-cutting concerns a la interceptors), but it seems like xml configuration files usually treat every action in your app like it's an exception to the rule, requiring its own configuration element, when in fact most actions follow the same general pattern (or, at least, it would be better if they did; see my above complaint about consistency). It would be nice if you could have one configuration pattern apply to any action that did not have its own explicit configuration. This would also obviate the practice of giving JSPs names unrelated to their filenames (e.g., success, display, input) and actions names unrelated to their classname. The more I see that practice, the less I understand it. But I've been dim before.

>
> I have to say that placing configurations in code is not the best way to go for a couple of reasons. First, if you change one property, you have to recompile. With most IDEs and build processes, the dependency checks are good enough that it won't slow down your build cycle much.
>
> However, there is a *much* bigger problem with this. Your code is now *unreusable*. You can't use it cross-project. For every environment you run this in where properties differ, you have recomplie. No thanks.
>

As I understand It was nothing about configuration in code. It is very good to have external configuration files for something like "maxConnections".
But external XML file is not a good place for code and metadata. XML is a very nice file format, but I prefer JAVA file format for JAVA applications,
Hashtable is a very good mapping too, is not it ?

Isn't there also a weakness in that the links point to a specific JSP? If you need to rename or move that JSP, or use a different JSP, you have to do a search and replace. The MS article on Page Controller mentions this too, and says their code-behind technique makes Page Controller viable.... unless you can make do with one controller per page, which the article admits is a limitation of Page Controller.

Good points, but such issues can be solved or minimized, by good MVC framework design, and/or tool support. Besides, in practice 1) the need to rename/move a JSP is usually rare; and 2) even without explicit tool support (such as a much needed rename/move refactoring for .jsp files in IntelliJ IDEA), the "search/replace in path" feature common in IDEs makes it a matter of minutes, if not seconds to perform. It's interesting to note that IDEA 3 already supports the rename/move class refactoring for .xml files (for example, it does the renaming of Action/ActionForm classes in struts-config.xml). But of course, my preferrence is to NOT use any such non-standard xml files.

As for the one controller per page restriction, I see no reason why a good Page Controller-based (Java) MVC framework would not allow for included .jsp files to have their own controller. Such includes would be reusable web components, and if no such components are used in a given .jsp, then it should only need one controller. So, really, this is not a limitation of the Page Controller, but perhaps of ASP.NET.

> Looking at the example of MS MVC, there seem to be a few questionable things that might make life easier in the short term, but they break separation of concerns - the aspx page specifies the specific controller class to use (if you repackage or rename classes, you're doing a search/replace, as opposed to just editing a single config file), the controller is tightly bound to web controls (not the case in Webwork, and how do you test this easily?), and the controller is referencing the names of database fields. Again - that's all fine for a small application where changes aren't expected, but I think those decisions can lead to major problems later in a larger application. Kinda typical of MS's M.O. - make the common stuff easy to do, but good luck when the brown stuff hits the fan.

I think the idea of "web controls", present in both ASP.NET and JavaServer Faces, is generally bad. A view (page) element should not have its counterpart in C#/Java. This is rarelly useful (for example, when programmatically changing the enabled/disabled status, colors, etc.), and there are other ways to achieve the same effect (in Java, a JSP custom tag could load additional properties associated to a page data field, with the property values populated by the controller).

I don't see how specifying the controller class in the .jsp (or .aspx) file breaks the separation of corcerns. It's only a convenient and cohesive way of doing the necessary association between view and controller.
As for the refactorings, the considerations I made above also apply here.

Referencing database fields in the view is optional, even in ASP.NET. No MVC framework can guarantee the developer will stick to MVC principles. But you're right on MS's M.O.; I've been there...

I hate URL examples myself, especially since they can be so radically different depending on the framework and/or implementation. Indeed, I've seen elegant and messy URL's from ASP pages, so I think it really does depend on the developer and what they decide to use.

That said, I try not to be an MVC2 zealot. I'm having to use a Stored Procedure in an application that basically performs business logic on the data model. There are always exceptions. MVC2 is a guideline for me, and I think it has benefits.

If done right, you can still develop just as fast with it as you can without. It really depends on your framework and how much complexity you want to use. I tend to keep things as simple as possible and I don't try to force design patterns into my code.

The current application I am writing is using Tapestry for its front-end. This means the front-end presentation layer is more-or-less HTML. Anyone can go modify the look and feel and not trash my presentation logic. As it turns out, this may be very important later on in the project. If I was not using MVC2 design, then I would be responsible for every little update, graphic change, or layout change. Although I know the Java community is infamous for pounding in nails with a monkeywrench, I prefer not to work that way.

Advanced presentation logic is kept behind the scenes and written in Java. So even my presentation logic is kept in seperate modules. I like to think of it as a division of responsibility. The top-most visible layer is shared between myself and non-developers. They can provide me with templates and layouts, and all I have to do is provide the 'hooks' that will make them dynamic. No muss no fuss. Try doing that as easily with PHP, ASP, or even JSPs. I've experienced quite a deal of pain in the past turning HTML done in Dreamweaver into a functional JSP page. Sometimes I had to rewrite the HTML from scratch!

Keeping with MVC2, my presentation logic has a 'hook' to the business logic. This is usually just a reference to a static method or calling a Java object with the appropriate logic. The business logic has it's own hooks into the data model. Again, division of responsibility. By not messing with the data model as anything more than a reference for my business logic, I don't have to do any advanced DBA stuff to make it work. Let the DBA's worry about table layouts, schemas, triggers, etc.

When do you not need MVC2? Well, if every developer also works as a graphic designer, web designer, and database administrator then you don't need MVC2. However, not every team is blessed to have individuals who are skilled in every area of application development. Shoot, I know developers who can't pick a decent color scheme or even settle on a decent looking font. They can write presentation logic all day long, but they should not be allowed to actually create the look-and-feel.

I won't be a slave to MVC2, but it has had definite benefits. I think the trick is to find a framework or process that makes it a natural part of your application development.

That said, I try not to be an MVC2 zealot. I'm having to use a Stored Procedure in an application that basically performs business logic on the data model. There are always exceptions. MVC2 is a guideline for me, and I think it has benefits.

Hmmm, I wonder where this "MVC2" thing came from. I understand MVC and "Model 2", but AFAIK, there is no such thing as a second edition or version of the MVC paradigm.

> If done right, you can still develop just as fast with it as you can without. It really depends on your framework and how much complexity you want to use. I tend to keep things as simple as possible and I don't try to force design patterns into my code.

I think the only practical way to develop a non-trivial web app is by following the MVC paradigm. However, the "Model 2" way (which is NOT the only way to achieve MVC) is MVC done wrong, IMO.

> The current application I am writing is using Tapestry for its front-end. This means the front-end presentation layer is more-or-less HTML. Anyone can go modify the look and feel and not trash my presentation logic. As it turns out, this may be very important later on in the project. If I was not using MVC2 design, then I would be responsible for every little update, graphic change, or layout change. Although I know the Java community is infamous for pounding in nails with a monkeywrench, I prefer not to work that way.

Tapestry is nice, but I don't see it as a viable long-term alternative to JSP and JSP-based MVC frameworks. In many (most?) J2EE projects, the web UI is initially developed in HTML, then given to the Java developers, which convert it to .jsp files; after this conversion, there are few changes to the UI design.
Of course, it would be very nice to be able to have an HTML designer easily modify the .jsp files after that initial conversion. I believe this should be achievable in practice: tools such as Dreamweaver MX already support JSP tags, browsers will ignore unknown tags, and JSP tags that replace HTML tags (such as Struts' html:text tag) are unnecessary and a bad practice in general.

> Keeping with MVC2, my presentation logic has a 'hook' to the business logic. This is usually just a reference to a static method or calling a Java object with the appropriate logic. The business logic has it's own hooks into the data model. Again, division of responsibility. By not messing with the data model as anything more than a reference for my business logic, I don't have to do any advanced DBA stuff to make it work. Let the DBA's worry about table layouts, schemas, triggers, etc.

Hmmm...I was told by a former manager that an earlier attempt at MVC still mixed some business and presentation logic. Ok, so my labeling was wrong but I think you still understood my point and I apologize for the lack of clarity.

I had to cut my last reply a bit short since I nipped the end of my finger with my pocket-knife in the middle of my last comment.

Back to business.

In my zeal to advocate MVC I see that I missed your point entirely. However, I disagree about Tapestry not being a viable alternative.

Why do the conversion to JSP at all? Isn't it better just to be handed the HTML, have the content that needs to be dynamic clearly marked, and then all the developer has to do is throw in a few tag attributes (you may not even need to add any new tags depending on what you're doing) to make the HTML work. Of course, the developer has to do the page specification, which is XML, as well as the Java work, but that's pretty much expected.

We've all been waiting for the day that JSP tags won't break common IDE's, but the problem is that most web designers aren't comfortable messing around with anything that does logic. This whole game of "pass the template" has gotten really old with JSP's. We either ask designers to play around where they might break logic or we ask developers to create logic without messing up the design. I think that JSP's are not conducive to MVC.

As for Model 2, I have no strong opinions on it, but I am geniunely(sp?) curious as to why you think it is "MVC done wrong". Not being sarcastic here, I really want to be educated on your opinion. That is, after all, why I post and participate here. To discover new information and perspectives.

Why do the conversion to JSP at all? Isn't it better just to be handed the HTML, have the content that needs to be dynamic clearly marked, and then all the developer has to do is throw in a few tag attributes (you may not even need to add any new tags depending on what you're doing) to make the HTML work. Of course, the developer has to do the page specification, which is XML, as well as the Java work, but that's pretty much expected.

Yes, this is a much better approach to the conventional JSP way of doing things.
It doesn't have to be this way with JSP, but unfortunatelly, no existing JSP-based MVC framework, to the best of my knowlegde, has got it right yet.
Notice that even with Tapestry, there is still a conversion from the original HTML file: id attributes need to be added, a few <span> elements, etc.
This could also be done with JSP custom tags wrapping HTML tags, without removing any of the original HTML. More verbose and potentially less performant, but it could be done.

Why do the conversion to JSP at all? Isn't it better just to be handed the HTML, have the content that needs to be dynamic clearly marked, and then all the developer has to do is throw in a few tag attributes (you may not even need to add any new tags depending on what you're doing) to make the HTML work. Of course, the developer has to do the page specification, which is XML, as well as the Java work, but that's pretty much expected.

My intent is to be able to do essentially the same thing with JSP, by adding custom JSP tags where required. You get a more verbose .jsp file, sure, but there is no need for a separate XML page specification file. As for the Java code, I guess it's about the same in both approaches.

> We've all been waiting for the day that JSP tags won't break common IDE's, but the problem is that most web designers aren't comfortable messing around with anything that does logic. This whole game of "pass the template" has gotten really old with JSP's. We either ask designers to play around where they might break logic or we ask developers to create logic without messing up the design. I think that JSP's are not conducive to MVC.

I agree, the need for both Java developers and web designers to work in the same file is a significant problem, and Tapestry perhaps provides the best partial solution. Unless I am missing something, I don't see how Tapestry's approach can fully solve this issue. For example, once you start extracting components from the many web pages where a certain amount of HTML code would be otherwise duplicated, you lose the ability to preview those pages in the browser or IDE.
But this has little to do with MVC, really, unless you consider the separation of those two roles to be its main benefit. (To me, the main benefit is the separation of code which deals with separate concerns. Web page files with HTML, scriplets, lots of logic tags, and/or Javascript are just to ugly for me to accept.)

> As for Model 2, I have no strong opinions on it, but I am geniunely(sp?) curious as to why you think it is "MVC done wrong". Not being sarcastic here, I really want to be educated on your opinion. That is, after all, why I post and participate here. To discover new information and perspectives.

Sure, that's why I am here too.
In short, I think Model 2 is flawed because its implementations are usually too difficult to use productivelly. Think Struts, for example. I haven't used ASP.NET, but it seems to allow for MVC in a more productive way, because of its support for the Page Controller pattern. I am not sure how to handle dynamic page navigation in ASP.NET, though. Anyway, my interest is in developing a JSP-based MVC framework that follows the Page Controller pattern (with many other ideas too, such as no such tags as <html:text />, Javascript code generation for form validation, integration with JSTL, and so on).

Interesting reading these post even if they did go off topic from the main article. What I notice is how some like xml config in their MVC and some don't, some like to programmatically chain actions some like it declaritive, some hate URL references while other like going straight to the JSP's. Most of their reasons seem reasonable and what is so great about our J2EE community is that we *have* these as options when selecting an MVC for your solution. When I started researching MVC's in detail I use to bang my head against the desk eveytime some punk would tell me about their new MVC. My frustration of why they would create another MVC when their are already sooooo many out there. But this discussions help clarify that not only do folks have different problems to solve (duh, I knew that) they also have different preferences so thank goodness for all those frameworks, they give us diversity and inovation. I feel like my list is fairly complete, http://www.frameworks-boulder.org/Application_Frameworks.html Notice how the J2EE community has about 34 frameworks while others have like MS has 1 and PHP has only a few. Many times in selecting a framework whether it is WW2, Struts, Expresso, Tapetestry, etc. they are all good solutions (some better than others -;) but the fact that we have the freedom to choose is wonderful unlike the other communities. I haven't been in the MS community long and everytime I complain about the lack of MVC it has folks responed, "you could always build your own MVC". Well yes but that wasn't part of my plan and in agreeing with Carmon Purdy's post eariler this week I only have a 1% chance of getting it right(although I think I have seen enough frameworks I think that % is a little higer).

I failed to point out before that you CAN do the page controller pattern with WebWork... You can embed the <webwork:action> tag to call an Action whether or not you've come to the page from an Action invocation, so you can have your page control which Actions get executed.

Pretty much any of the ideas here can be done using WebWork, it's just a matter of different styles.

I failed to point out before that you CAN do the page controller pattern with WebWork... You can embed the <webwork:action> tag to call an Action whether or not you've come to the page from an Action invocation, so you can have your page control which Actions get executed.

>
> Pretty much any of the ideas here can be done using WebWork, it's just a matter of different styles.

That's great! I read that WW2 followed Model 2, so I assumed it couldn't support the Page Controller pattern. I will have a deeper look when time allows.
However, I am worried WW2 may offer a bit too much flexibility. Wouldn't it be better to settle on one of the two competing patterns, Front or Page Controller?

I failed to point out before that you CAN do the page controller pattern with WebWork... You can embed the <webwork:action> tag to call an Action whether or not you've come to the page from an Action invocation, so you can have your page control which Actions get executed.

> >
> > Pretty much any of the ideas here can be done using WebWork, it's just a matter of different styles.
>
> That's great! I read that WW2 followed Model 2, so I assumed it couldn't support the Page Controller pattern. I will have a deeper look when time allows.
> However, I am worried WW2 may offer a bit too much flexibility. Wouldn't it be better to settle on one of the two competing patterns, Front or Page Controller?

The webwork:action tag has many uses, including creating reusable UI components and encapsulating lookups for things like dropdowns. It can also be used to drive the processing of the request in the same way as a Model2 controller from the JSP (or Velocity) page.

Problem in JAVA (but this is benefit too) is a lot of frameworks. Next week our team will start a new huge project (Database is Oracle, Web-based client, ~100 clients). Deadline is April 2004.

We are very hesitate what framework is best for us (Struts vs. Spring vs. Webwork2 vs ...). Until now we decide for Hibernate (it defeats CMP EJB and JDO too) as OR mapping tool, XP Programming as methodology, Crystal Report as report tool.

What do you recomended for us ? When we use .NET everything is clear and desicions are quick :)

Problem in JAVA (but this is benefit too) is a lot of frameworks. Next week our team will start a new huge project (Database is Oracle, Web-based client, ~100 clients). Deadline is April 2004.

>
> We are very hesitate what framework is best for us (Struts vs. Spring vs. Webwork2 vs ...). Until now we decide for Hibernate (it defeats CMP EJB and JDO too) as OR mapping tool, XP Programming as methodology, Crystal Report as report tool.
>
> What do you recomended for us ? When we use .NET everything is clear and desicions are quick :)

I'm obviously biased, but I'd say WW2 :-)

Kris has done a lot of research into all of the different frameworks, and I think it's pretty telling that he's recommending WebWork2 (at least I read his comparison of WW2 vs. Struts vs. Maverick as a recommendation, excuse me if I'm wrong).

Well your sort of right Jason. When not talking about the problem (web application) at hand I think Webwork is a wonderful solution, it gives you flexiablity, loose coupling, and a few other great features like Interceptors. I won't go as far as to say that everyone should use WebWork, it really depends on you problem but in general by choosing Webwork you probably can't go wrong. There are 34-ish J2ee frameworks out there and I don't know them all but I know a lot of them and from what I've see Webwork is the winner.

My suggestion to you is check out webwork yourself, and some of the others. One of the big reasons behind the wafer project, www.waferproject.org is to help folks like yourself in selecting a framework. Currently the best thing we have at wafer are the various weblogs written with different frameworks.

I also know of a wonderful consulting company that can help aid you in making that decision if you need, www.flyingbuttressconsulting.com

- WW2 (or WW 1.3, which is production stable) for MVC
- Velocity for UI (as much as possible, use Velocity)
- Hibernate's my first choice for the data tier, but iBatis, which doesn't get as much pub, is a very nice choice too, particularly if you've got some very strong SQL developers who'd prefer to write SQL as opposed to using an ORM
- I'm an avid drinker of the Spring Kool-Aid, so give the lightweight container approach a shot and use the Spring BeanFactory. You don't need to use the Spring MVC, it's completely optional, and it's a cinch to integrate the BeanFactory with WW2 (or WW 1.3). There are some nice Hibernate and transaction goodies in Spring as well that will make using Hibernate even more productive than it already is.

I had been reading the thread on this article with great interest since I just got through integrating WW2, and absolutely loved it! But I couldn't just sit quietly when you ask such a tempting question, even though it is a shameless plug. I am obviously biased based on the countless hours of effort others and I have put into it, so I won't tell you it is "best". The ultimate "best" will be what meets your needs, don't let anybody tell you what that is. You should at least consider the Keel Framework, particularly if you are on short notice, based on what is *already* integrated in it. Since you are looking at WW2, let me tell you that WW2 is already integrated and available from CVS, as are Maverick, Struts, Cocoon and Velocity. There are many other things, but a more appropriate venue for that discussion, if you are interested, is the Keel list.

The ultimate "best" will be what meets your needs, don't let anybody tell you what that is.

Correct. I only mentioned WW2 because "in general" it is nice but it might not fit your problem at hand. And defining "in general" is ambiguous but one has to put a stake in the ground somewhere, not even I can learn all 34 frameworks!

There is a article recently released on Keel for those interested which was written by the previous poster

I didn't mean that as a remark against your statement, only as an answer to the original question. I personally, wouldn't have any heartburn recommending WW2, since as I said, I actually liked it a lot, and am considering it for use on my next implementation.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.