On Apr 23, 2010, at 5:18 PM, Adam Heath wrote:
Adrian Crum wrote:
--- On Fri, 4/23/10, Robert Morley <[email protected]> wrote:
+1 - I think properly modeling the
field using the required-field attribute makes perfect
sense. I would think our html form renderer
implementation should probably just apply a class "required"
at render time and the visual should be handled by css.
I believe I was the one who introduced the required CSS class and
that was my reasoning - have the style sheet determine what a
required field looks like.
At the time, the asterisk was being used to indicate a required
field. The problem was, most forms didn't have an explanation as to
what the asterisk meant. So the result looked odd.
No "best practice" was discussed or decided upon. I just put the
new CSS class in the style sheet and I left it to the community to
decide by using it or not.
I like the idea of service definitions driving the required fields.
Sure, that would be nice. However, what happens when service A calls
service B, and service C sometimes dependening on the situation. How
would you chain the validations, so that no processing code was run in
A until both B and C were satisified that the data was correct?
I think you would be using the required fields defined by the service
definition of service A which is what the form would be bound to. If
there are optional parameters to service A that are required by
service B (and service B is always called) then service A should have
them marked as required as well. However, if service B is optionally
called itself (based on logic) then without the client duplicating
that logic client-side, the page has no choice but to make those
parameters optional as well.
