Hi, I think I've read somewhere that domain services aren't always injected into entities by default and you sometimes have to trigger this yourself?
Is this a correct? Thank On Thu, Nov 26, 2015 at 10:00 AM, Stephen Cameron < [email protected]> wrote: > I cannot try alternatives till later this evening, will let you know > of results. If I cannot get tenancies working for tomorrow its not the end > of the world. I was getting "record not found" errors last night due to > making region allowsNull="false", so a bit of a panic, given its > mostly been working very smoothly now for a while. > > On Thu, Nov 26, 2015 at 9:40 AM, Dan Haywood <[email protected] > > wrote: > >> 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 >> > > > >> > > >> > >> > >
