Spring MVC Extension Points

[ashik]

I would like to know a little detail about extending Spring MVC to develop custom view/navigation/flow framework. For some reason, we will not use Spring Web Flow. We developed a small frameowrk specification and sample implementation based on usage of many simple form controller; one for every jsp page that holds a form and one for the rest of non-form JSPs. Our custom framework is under active redesign and improvement. One of our design goal is to make our framework less dependent on Spring engine.

I am going through a high-level but unclear/inconsistent explanation of our framework development requirements. Our framework development requirements are as follows.

* The framework is being developed for a group of applications related to banking, that consumes a lot of related services from different third parties. Currently my team is concerned with the top layer (MVC) architecture.
* Enable developers write only minimal codes and configurations to add a new sub-module. Template patterns will be used heavily to fulfill this requirement.
* Use our custom POJO based validation/error handling framework in our MVC layer.
* Use our custom navigation/work flow management system (but not Spring Web Flow) on top of Spring MVC. JSP pages should be reusable among different similar work flows and controllers should not have any knowledge of previous or next pages - that is the sole responsibility of navigation manager to whom it makes only a single call to get the next view.
* Take advantage of Spring's automatic request parameter binding.
* Take the i18n features of Spring MVC.
* Use our own back-end or middle tier technologies.
* Make the framework so change-friendly that in future, if necessary, we should be able to remove Spring as our framework engine and use something else, for example, plain vanilla Servlets, JSP/JSTL with comparatively less efforts.
* Application should be highly scalable and performance is not so big concern yet, partially because the company can provide as much hardware and other resources as necessary to cover it up. Rather saving developer's time or minimizing developer's chances of making mistakes are of greater concern.
* Use Java Reflection API in places where it reduces developer involvement.
* No XP or unit/functional testings are considered at this stage.

It may seem that better to develop the whole framework on top of Servlets/JSP rather than using limited portion of Spring MVC.

I wrote a quick implementaion of Spring MVC's Controller interface and now considering to use BaseCommandController or AbstractFormController and use its template methods to introduce further templating of our various service-related method calls that interest our framework. Or any other idea to extend it?

-- Ashik
San Francisco, CA

[Colin Yates]

Given the following statements:

No XP or unit/functional testings are considered at this stage.

Application should be highly scalable and performance is not so big concern yet, partially because the company can provide as much hardware and other resources as necessary to cover it up. Rather saving developer's time or minimizing developer's chances of making mistakes are of greater concern.

I would very quickly walk away. You are being led by a plonker

[ashik]

Actually not that case. They have their different check points rather than regular testing staffs. Different clients have different requirements and this is something we like as a contractor. This client is concerned more with developer productivity/involvement etc. rather than anything else.

[ojolly]

I would strongly confirm what yatesco stated.
IMHO, having unit test is a security net for the coders, they feel free to refactor badly wrote stuff because they have a second look at their code this way. Else, the code will be frozen in the state of a giant prototype, the kind of stuff which can take up to 30 minuts to render a dozen of item on screen (I've seen it from my own eyes). The same base code rewrote with a bit of performance in head would divide by 500 the rendering time. In our case the hardware needed to make it work in an acceptable speed for a single user didn't exist yet (and still don't I think).
In a word : don't accept those statements !

[Colin Yates]

Actually not that case. They have their different check points rather than regular testing staffs. Different clients have different requirements and this is something we like as a contractor. This client is concerned more with developer productivity/involvement etc. rather than anything else.

ashik; one of the main reasons I am a contractor is, as you say, different clients have different ways of doing things.

*but* there are some golden rules which you absolutely cannot break. "don't unit test" could, by some very clever people (i.e. not me) be argued to be redundant if there are utterly extensive funtional tests, but "don't design for performance; we will bolt on extra hardware" is such a fundamental mistake it is silly In fact, I never thought I would ever hear that written down as an actual requirement

Ashik; again, walk away

P.S. Just to be clear; I personally think that unit tests are excellent and I fully subscribe to the test first. *but* you could academically argue that if you have functional tests to test *every* possible usage of the system then finer grained testing is mute. Note the word "academically"

[ashik]

In most of my projects I have used unit testing though not in current project. I understand its requirement and its role. I just wanted to point out that our emphasize is now on some other area, mainly developer productivity which does not exclude any possibility for unit testing.

BTW, we already developed the early version of our framework using a bunch of simple form controllers without any multi action controller. Its fulfilling our requirements fine now. But still would like to know more extension points of Spring MVC for future.