On Apr 23, 2010, at 5:53 PM, Adam Heath wrote:
Robert Morley wrote:
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).
I do not believe the walker is making any assumptions. It cascades
security artifacts from wherever they are defined. In just so happens
that a controller request (which in our world can have security
artifacts) may define an event of type service. We do not attempt to
walk any deeper than the service definition; and it can harvest
security artifacts from there regardless if they are primitive
security checks or invocations to a security method (as long as it is
modeled).
If one was to do what you are saying, I believe it would boil down to
the same thing -- service definition defines behaviour and modeled
objects that have a hard reference to that service definition could
obtain that behaviour and transform themselves as a result.
Is it complete? Of course not -- if a widget has a soft reference
(say a target is determined dynamically) then we can not do anything
(remember this is loaded at cache time). Moreover, there is (in this
case) permission join considerations. Say I have a form that has two
links; does the parent widget OR those permissions or AND them? We
have expected the presentment model to account for this; so on a
screenlet (for example) you can indicate if all permissions are
required to show that widget (AND) or if you can partially show it (OR).
Having said all this; it is one of the reasons why we like minilang.
Being heavily modeled it provides an opportunity to get right in there
and walk and transform it. That is something that has come up quite a
bit as well as additional uses for walking the entity model. In my
mind the form can be shaped quite a bit if you have a deterministic
way to link it to the entity it operates on and the service that does
that work.
