Back Forum Reply New

Overriding setupForm

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;cut/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.
¥
Back Forum Reply New