MVC versus Taglibs, opinions/alternatives?

I'm a frontend developer and I find myself in the jsp view layer a lot and seen quite a few solutions to push data (model) into a view. Recently I've come across a taglib solution that pulls data into the jsp, which to me seems more natural and sensible.

First the problem

Given a single page and seeing it as a seperate entity, MVC makes absolute sense, however a single page can be quite complex and most likely reuses components/services that are used on other pages. As a result the controller becomes rather complex as well.

In my experience a page is mutable as well since clients love to shift functionality around or turn the whole site inside out at the next "redesign". This usually leads to a rather tedious refactoring project where literally EVERYTHING needs to be rewritten.

Then there's the issue of consistency, on one page a dataset is put into the ModelView as "list" and on another page where "list" might be to abstract, it's put into the ModelView as "specificList". Maintaining consistency during a project lifecycle becomes a tedious mundane task and is usually avoided, but this is exactly what happens with a pure MVC solution.

Solution?

So in a recent project I inheritted, I've seen two solutions that pull data into a pageView. The first is rather ugly using a jsp:include to call a jsp page and fire off another controller.

The second I found rather elegant, they used a taglib to pull specific datasets into a pageView. The taglib was documented inside the TLD and it was a joy to use. Suddenly I could reuse data on a multitude of pages without messing about with controllers.

So in this project I had to implement a "redesign" and all the data pulling solutions made my job a lot easier, however at the points where they used data injection (MVC) it was a pain in the arse (I'm not a java developer) and java developers to help out where few to none.

Also taglibs when written properly can be write-once only whereas using data injection (MVC) can become a child you constantly need to care for (on top of the jsp's).

Taglib example

Let's say we have services.tld with the following tag definitions/implementations.

- getEmployeeAddress

- getEmployees

<services:getEmployees filter="a">
   <!-- loop, get addresses, otherwise if empty list, render nothing -->
</services:getEmployees>

This allows me (the frontender) to display employees and their addresses on virtually any page, frees up a java dev for more important tasks. The service is testable seperate from the pageView controller, the pageView controller becomes a lot less complex (say for example only handle authentication and site wide functionality) and life (to me at least) seems a lot more fun.

My ques开发者_JAVA技巧tion

Multipart actually:

1.) Is my reasoning crap and if so, why and from what perspective? =P

2.) Are there better alternatives? (I've also used tiles for example).

3.) Are you using the above mentioned taglib solution and how is your experience with that?

4.) What's the cost/benefit/risk of above taglib solution from a java dev's view?

I understand why MVC makes it simple for Java devs, but in my experience (sofar) it just moves the hardship to the jsp layer, it's like I sometimes need to learn a seperate API for each page... Oh and being a frontend developer, I do admit data pulling comes more natural to me using Ajax and all that shizzle, having all the data available at page load is an anti-pattern in my area...

You've clearly heard the mantra that it is the bad to implement business logic in JSPs. But do you understand why?

One of the reasons is the technical problem the problem of when the HTTP response is committed.

In an MVC based system, the controller checks parameters, decides what needs to be done and tries to do it. Then on the basis of that it sets a response status code and pulls data to be displayed in the response. Finally, it selects a view (e.g. a JSP) and hands control to the JSP engine ... which commits the HTTP response.

If you try to do everything in a JSP, you have the problem that the response is HTTP likely to be committed too soon; i.e before your business logic has done the things that will determine what the correct HTTP status code is.

Your dissatisfaction with MVC seems to be largely derived from your assumption that the controller and the view (the JSP) are implemented by different people: i.e. "front end developers" and "java developers" who have non-overlapping skillsets and areas of responsibility. My take is that you should just have "developers" who have the skills to work on both sides of "the fence". In fact, there shouldn't be a fence at all.