[EMAIL PROTECTED] wrote:
Hi Noah,
Why is it hard for the back-end logic to set these defaults when it constructs
the unpersisted Reservation instance? I'm not sure I followed that part, it's
something we do all the time in our system.
I guess it depends. In some cases it is the *business object* that
logically has a default value, in which case it should be that tier
which implements the defaulting logic.
However I can imagine cases where the default is really not part of the
business behaviour of that object (eg defaulting "http:" as a prefix).
Maybe you could write a custom tag that sets defaults, eg
<s:setDefault value="default-value"/>
which would:
* get the parent component
* do nothing if its submittedValue property is set
* do nothing if getValue() is set
* set its submittedValue to the value of the default tag
Note that it is probably not possible with JSF1.1/JSP for this component
to take a "for" attribute like a label can; it would be necessary to use
it as a child of the target component. The problem is that the tag needs
to run *before* the target is rendered, otherwise setting the submitted
value will obviously have no effect. However with JSF1.1/JSP the tag
would need to run *after* the target is rendered in order to be sure
that target exists on the first render of the page :-(. Having this tag
as a child works (I think) because the component will be created when
the open tag is encountered. The HtmlTextRendererBase class does its
rendering at encodeEnd(), so child components have their render methods
execute first. Not sure it's a great idea to depend on whether text
inputs render in encodeBegin() or encodeEnd, but AFAICT it will work. I
believe this ordering problem does not apply for JSF1.2 or with Facelets.
Cheers,
Simon
