On 25 November 2015 at 22:26, Stephen Cameron <[email protected]>
wrote:
> Hi Dan,
>
> I did not explain it that well sorry.
>
> I want to get rid of nulls completely, the fact that I do handle them is
> just a work-around for the fact that they are still being created, but only
> for People. That is, if a new Participant is registered it looks to see if
> there is an existing Person with the same details then adds a new one if
> not present (a single Person can be a Participant and/or a Volunteer). The
> Participant is getting its region set in setUpdatedBy() but the Person is
> not, I need to debug this.
>
>
In 1.10.0, a better approach is probably to add a subscriber to the
lifecycle events:
@DomainService(nature=NatureOfService.DOMAIN)
public class RegionSubscriber extends AbstractSubscriber {
@Subscribe
public void on(ObjectPersistingEvent ev) {
Object domainObject = ev.getSource();
}
@Subscribe
public void on(ObjectUpdatingEvent ev) {
Object domainObject = ev.getSource();
}
}
> As general interest is handling such things via such a service better, that
> is to avoid injecting services into entities if possible?
>
>
There's nothing wrong with injecting services into entities; it allows them
to perform their responsibilities without leaking details of how they do it
(their implementation) to the caller. I don't hold by this "pass in the
services" and "double dispatch"... I see that as a code smell.
On the other hand, we now have a very rich set of domain events; in AOP
terms these are jointpoints (or is it pointcuts? see [1]), anyway they are
a different way to cause "stuff to happen".
Should one have the entity call a services, or rely on subscribers to
domain events? With the latter, the entity is very clean and the
responsibility kept completely separate. On the other hand, with events
the order in which the subscribers fire is non-deterministic.
> Last minute tweeks aren't the best idea, but the tests that I do have are
> proving their value. These particular issues are probably a result of no
> integration tests yet.
>
>
It's not clear to me if my suggestion to use the TenancyEvaluator SPI
helped ? Or, indeed, whether you have a reasonable workaround in your
current handling of the nulls?
> Thanks
>
>
[1]
http://stackoverflow.com/questions/15447397/spring-aop-whats-the-difference-between-joinpoint-and-pointcut
> On Thu, Nov 26, 2015 at 8:09 AM, Dan Haywood <[email protected]
> >
> wrote:
>
> > Hi Steve,
> >
> > Not sure I follow quite all the ins-and-outs of this, but what could well
> > be of use is the optional ApplicationTenancyPathEvaluator domain
> > service[1]. If an implementation is registered (on the classpath), then
> > the security module will delegate to this [2] in order to determine who
> > gets to see/edit what.
> >
> > From what I did follow, it sounds like you need to treat objects with a
> > null region in a particular way? If so, then hopefully you can put this
> > "special case" logic in an implementation of said service.
> >
> > HTH
> > Dan
> >
> >
> >
> > [1]
> >
> >
> https://github.com/isisaddons/isis-module-security/blob/master/dom/src/main/java/org/isisaddons/module/security/dom/tenancy/ApplicationTenancyPathEvaluator.java
> > [2]
> >
> >
> https://github.com/isisaddons/isis-module-security/blob/master/dom/src/main/java/org/isisaddons/module/security/facets/TenantedAuthorizationFacetFactory.java#L72
> >
> >
> > On 25 November 2015 at 20:25, Stephen Cameron <
> [email protected]>
> > wrote:
> >
> > > Hi,
> > >
> > > I have a problem with Application Tenancies not working the way I
> want, I
> > > want to drive it off a field 'region', such that a person is assigned a
> > > tenancy of GLOBAL, NORTH, SOUTH, NORTH-WEST and these are also the
> > regions
> > > that they are working in too, so when they create a record their region
> > > gets assigned to the new record and that controls who else can see the
> > > record.
> > >
> > > This mostly works, but there is one small glitch. The main problem I
> have
> > > is setting it up so that region is non-null and any records created by
> a
> > > GLOBAL tenancy user are seen by all users, while those created by a
> > NORTH,
> > > SOUTH or NORTH-WEST user are seen only by users with the same tenancy.
> By
> > > changing the region of a record it can change tenancy.
> > >
> > > Presently this is broken, or at least it I think it was working
> correctly
> > > when I allowed a record with a region of null to be the GLOBAL ones. I
> > need
> > > to have this working for a demo tomorrow, so advice is welcomed on how
> > best
> > > to set this up properly.
> > >
> > > My base class that controls all this here:
> > >
> > >
> >
> https://github.com/Stephen-Cameron-Data-Services/isis-chats/blob/master/dom/src/main/java/au/com/scds/chats/dom/AbstractChatsDomainEntity.java
> > >
> > > The other small glitch is that a person record created in the process
> of
> > > creating a participant doesn't get assigned a region automatically. I
> > have
> > > a work-around for that in place at present, anything that has a null
> > region
> > > gets presented as having a global tenancy.
> > >
> > >
> > > Thanks
> > >
> > > Steve Cameron
> > >
> >
>
