On 1/6/06, Dave Newton <[EMAIL PROTECTED]> wrote: > Doesn't it just need validation info rather than model knowledge (you > listed validation constraints/msgs in your original list, which is why I > can't figure out why it needs any more info).
If we consider the target type to be a validation constraint, then we are stating the same fact twice. Target type is an implicit validation constraint. Other domain constraints might be a range of values within the target type. And, of course, in practice, checking subranges usually begs converting the input to the target type. Ideally, formatting and conversion should be part of validation, so that we don't do any of these things more than once as part of the same request/response. But, all this is something that we also need to do with *any* presentation layer, not just a web front-end. For example, we should be able to run independant unit tests (another presentation layer) that demonstrate that input and output are being formatted as expected. These concerns, and many others, beg the existing of a layer between *any* presentation layer and *any* business layer. I think we've been trying to create this layer with efforts like XWork and Commons Chain. A controller layer between the view and model that handles concerns like conversion/formatting/validation, and even logical navigation, but that is independant of a particular presentation layer. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
