Question

Is it possible to define the type of the view commands in Spring? As it is right now, it is dangerous for us to change anything in our command classes. Properties on these classes may be used by the view (path="myDto.persons[0].name"), but if anything in the command class changes, the view will only fail runtime.

All other parts of our MVC stack is tested, so we can safely do refactorings when needed. The only problem is with the view, as the paths are “just strings”, and we cannot in any reasonable way search and replace everywhere we use the specific command.

It would be a great help if there was some way to tell Spring what type the command actually is, so it could be validated when we do precompilation of our .jsp’s. An added bonus would also be completion when editing the view, but I guess that is more of an IDE issue.

So, do any of you know how and if this is possible?

Answer 1

It might be possible to add type safety to your views if you completely redesign your JSP files (in a very ugly way if I may say so myself).

Servlets offer you type safety since that’s Java code. If you refactor your classes and miss something, the compiler will immediately tell you you missed it. But JSPs replace servlets as a view technology offering a much more dynamic/rapid development pace (no more endless out.write instructions opening tags, closing them, escaping quotes etc).

EL expressions, as you noticed, are basically strings which later get evaluated and fail at runtime if something is off. Even if you precompile the JSPs, it would still fail because ELs remains as strings in the generated servlet. They are either passed as such to tags and they evaluate it themselves, or if using a JSP 2.x version, the servlet container itself wraps the expression in an evaluation call before passing it as a value.

Basically for a version less than JSP 2, for a tag like:

<my:tag value="${bean.someProp}" />

You get a result like:

myTagInstance.setValue("${bean.someProp}");

in the servlet.

The tag itself will do the evaluation of that string, at runtime.

For JSP 2 you don’t get any better, the evaluation still occurs at runtime but the servlet container takes this burden away from the tag, generating a code like:

myTagInstance.setValue((SomePropTypeCastHere) ProprietaryServletContainerEvaluationUtil.evaluate("${bean.someProp}"));

If the content of the object itself isn’t the expected one when evaluation occurs, you get weird results or errors.

The only way (I know) to enforce static typing in a JSP is to bring Java code back in the JSP (the thing EL was invented to eliminate). That is why I said at the begging that you have to change your JSP in an ugly way.

If all your tags can use <rtexprvalue>true</rtexprvalue> values, you can use scriptlets to enforce type safety.

A tag like:

<my:tag value="<%=bean.getSomeProp()%>" />

now gets converted to this:

myTagInstance.setValue(bean.getSomeProp());

If the someProp property was renamed, deleted, changed type or whatever, the compiler can tell you about it. The IDE itself should be able to tell you, you don’t even need to precompile the JSPs.

If I’m not mistaken, the Spring tags support runtime expressions so this should work… if you are willing to mess up your JSPs that is!

As for the IDE support for completion, you have that for scriptlets but not for EL. That’s because for EL it’s the same discussion, it happens at runtime. How is the IDE to know what’s in context (page, request, session etc) when the JSP is executed, and know that when you are developing the JSP?