Robert Morley wrote: > > 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!)
Such a walker can not make any assumptions. Events called from widgets are difficult to walk down into, as are services themselves. services can be written in just about any language. What should be done, is that for each defined service, add a security check service(which can then cascade), and a validation service(which could do the same thing).
