|
|
FormAction has a hook in it called doBind that allows you to do custom bind logic without overriding bind.
The Java doc says this:
quot;This action method is not designed to be overidden and might become final in a future version of Spring Web Flow. If you need to execute custom data binding logic have your flow call this method along with your own custom methods as part of a single action chain. Alternatively, override the doBind(RequestContext, DataBinder) hook.quot;
There is no equivalent hook for setupForm. The javadoc says:
quot;This action method is not designed to be overidden and might become final in a future version of Spring Web Flow. If you need to execute custom form setup logic have your flow call this method along with your own custom methods as part of a single action chain.quot;
I'd rather not change potentially hundreds of web flow states to introduce some global rendering logic that I could put in place in setupForm. Will Webflow 2 have this hook if it goes ahead and makes setupForm final ?
My question relates to this thread showthread.php?t=40095
I would suggest the solution is to use :
lt;context-paramgt;
lt;param-namegt;defaultHtmlEscapelt;/param-namegt;
lt;param-valuegt;truelt;/param-valuegt;
lt;/context-paramgt;
in your web.xml. If I've understood correctly, that other thread is really asking how to escape input before binding it to a Java object.
(What I think you're asking is quot;How to escape unescaped strings whilst rendering the page ?quot;)quot;defaultHTMLEscapequot; seems to do just what you want, but with one big caveat.
If you're using a (for example) lt;form:inputgt; type tag, unescaped data is passed to the Java object, but an escaped version will be displayed on the page on a refresh.
However this seems to break down when using expression language. If you output your data using ${}, your browser will display the unescaped data item instead of the escaped string.
Perhaps one option is to use lt;c ut/gt; instead of ${}, because it escapes values by default, but using this solution might depend on how many ${}'s there are to replace...
I'm left wondering why the quot;defaultHTMLEscapequot; doesn't affect ${}'s, and whether there's a way to force this to happen...
(Any takers ?)
Paul,
We don't plan on changing FormAction in SWF 2 - it's there for backwards compatability. I'll update the javadoc, thanks. |
|