ok, raised https://issues.apache.org/jira/browse/ISIS-1864
On Sat, 17 Feb 2018 at 15:24 Dan Haywood <d...@haywood-associates.co.uk> wrote: > Hi Erik, > > Yes, I'm not sure myself what the impact would be. > > I think that the parent EntityModel shouldnt' really have this > responsibility of telling each of its child ScalarModel's to reset > themselves. Rather, perhaps it should simply instruct the ScalarModels > that they are now dirty, so that if and when the ScalarModels are next > asked for their state (for re-rendering) they then will query the > underlying domain object ... but not before. > > I think I'd rather do this in a separate ticket, though, which I'll raise. > > thx > Dan > > > On Fri, 16 Feb 2018 at 10:18 Erik de Hair <e.deh...@pocos.nl> wrote: > >> Hi Dan, >> >> We have the same issues on [1] when executing an action. >> >> I can create a pull request and add equal code as for the fix on [2] but >> I can't foresee what a possible impact might be. >> >> Thanks, >> Erik >> >> [1] >> >> https://github.com/apache/isis/blob/master/core/viewer-wicket-model/src/main/java/org/apache/isis/viewer/wicket/model/models/EntityModel.java#L400 >> [2] >> >> https://github.com/apache/isis/blob/master/core/viewer-wicket-model/src/main/java/org/apache/isis/viewer/wicket/model/models/ScalarModel.java#L290 >> >> On 02/12/2018 04:01 PM, Dan Haywood wrote: >> > Hi Erik, >> > >> > Mistake on my part. I've brought the ticket back for fix in 1.16.1, and >> > added a comment to the ticket itself. >> > >> > thx >> > Dan >> > >> > >> > On Mon, 12 Feb 2018 at 11:48 Erik de Hair <e.deh...@pocos.nl> wrote: >> > >> >> Hi Dan, >> >> >> >> As far as I can see the fix [1] for ISIS-1759 [2] is not merged to >> >> current release of Apache Isis [3] >> >> >> >> [1] >> https://gitbox.apache.org/repos/asf?p=isis.git;a=commitdiff;h=c6c2fc7 >> >> [2] https://issues.apache.org/jira/browse/ISIS-1759 >> >> [3] >> >> >> >> >> https://github.com/apache/isis/blob/master/core/viewer-wicket-model/src/main/java/org/apache/isis/viewer/wicket/model/models/ScalarModel.java#L290 >> >> >> >> We're upgrading to 1.16.0 now but the issue is still there... >> >> >> >> Did I miss something or is the issue not fixed yet? >> >> >> >> Thanks, >> >> Erik >> >> >> >> >> >> On 10/26/2017 12:45 AM, Dan Haywood wrote: >> >>> Raised https://issues.apache.org/jira/browse/ISIS-1759 for this >> >>> >> >>> On Sun, 1 Oct 2017 at 19:52 Dan Haywood <d...@haywood-associates.co.uk >> > >> >>> wrote: >> >>> >> >>>> Hi Erik, >> >>>> I'll look into this... This doesn't sound right that this version is >> >>>> creating these extra calls into the domain code. >> >>>> Thx, >> >>>> Dan >> >>>> >> >>>> On Wed, 27 Sep 2017, 11:35 Erik de Hair, <e.deh...@pocos.nl> wrote: >> >>>> >> >>>>> Hi, >> >>>>> >> >>>>> I'm not really sure about this but it feels like our app's >> performance >> >>>>> (Apache Isis 1.15.0) is worse than before and I believe it might be >> >>>>> because of the fact that the getter and hide method of a property >> are >> >>>>> called both, despite the fact that the property is hidden. >> >>>>> >> >>>>> We have a (derived) property (or referenced property) defined like >> >> this: >> >>>>> public String getX(){ >> >>>>> return someService.createX(getY(), getZ()); // We don't want >> this >> >>>>> method to be called always, because it's an expensive one >> >>>>> } >> >>>>> public boolean hideX(){ >> >>>>> boolean condition = ... // some condition >> >>>>> return condition; >> >>>>> } >> >>>>> >> >>>>> In 1.14.0 getX() wouldn't be called if the hideX()-method returned >> true >> >>>>> and so wouldn't the expensive service-method be called. For 1.15.0 >> we >> >>>>> would have to change the implementation to something like the >> following >> >>>>> to make sure the expensive call wouldn't be executed: >> >>>>> >> >>>>> public String getX(){ >> >>>>> if(!hideConditionsForX){ >> >>>>> return someService.createX(getY(), getZ()); >> >>>>> } >> >>>>> return null; >> >>>>> } >> >>>>> public boolean hideX(){ >> >>>>> return hideConditionsForX(); >> >>>>> } >> >>>>> private boolean hideConditionsForX(){ >> >>>>> // ... must probably be implemented using QueryResultsCache >> to >> >>>>> reduce DB-calls >> >>>>> } >> >>>>> >> >>>>> This is also the case for referenced properties for which no >> DB-query >> >>>>> has to be executed if it was hidden. This could count up if we have >> a >> >>>>> lot of hidden properties (this might be solved with refactoring). >> >>>>> >> >>>>> Am I seeing this correctly? >> >>>>> >> >>>>> Erik >> >>>>> >> >>>>> >> >>>>> >> >> >> >>
