On Apr 23, 2010, at 5:33 PM, Adam Heath wrote:
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.
Validation is more than just a required check. Various fields may be
restricted to a certain list of allowed values. This list could
change based on other incoming parameters. And copying such
validation all over the place would lead to more madness(I have enough
of my own).
No argument about validation; but I thought the original point was
adjusting the model form field's required attribute based on the
service that is it bound to. In that case, my expectation would be
that it would honour what is marked as non-optional from the service
definition.
One could certainly harness the power of the model to walk and
transform based on all sorts of associations. Internally we have
added the visitor pattern to the presentment, service, and controller
models with the intent of doing these sort of things. To date we have
applied (traditional ofbiz) security -- think service definition
defines a permission check for PARTYMGR_VIEW and because a controller
request "ViewParty" uses that as a service event, it gets transformed
to have the same security check. Naturally, the modeled MenuItem has
a link to this controller request, so it gets transformed to be
wrapped with the security check. Net result is that the application
no longer renders the menu link because the logged in user does not
have that permission. But alas, I suspect that is a discussion for
another day .... or is it? ;) (Please don't tell me I have to look
at the security re-design, i know know!)
