On Apr 23, 2010, at 4: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?
IMO it would be a bad idea to do something like that. If service A calls services B and C then service A is responsible for what it passes to those. Just because there is a required parameter on service B that happens to have the same name as an optional parameter doesn't mean we'd want to make it required when calling service A, it just means that service A is filling in a value before calling service B (or if it isn't then there is a bug in service A). -David
