I've also raised https://issues.apache.org/jira/browse/ISIS-1761 for the other points raised on this thread
On Tue, 26 Sep 2017 at 10:02 Erik de Hair <[email protected]> wrote: > Hi Dan, > > Thanks for your elaborate answer. > > > On 09/25/2017 07:03 PM, Dan Haywood wrote: > > Hi Erik, > > > > Yes, things did change quite a lot in 1.15.0, so apologies if there are > > still some bumps. > > > > The biggest change is that the page is if the action returns the same > > object, or for a property edit, then the page is redrawn rather than > doing > > a redirect to the next page. > > > > Because of this, the evaluation of whether an object member is > > visible/disabled had to move out of the constructor (when the Wicket > > component is instantiated) and into some other of the Wicket callback > hooks > > ... IIRC then configure(...) being one that is called prior to each > redraw. > > > > This explains also why we are getting empty field sets ... previously > when > > the page was rendered the fieldset could be suppressed if all of its > > members are invisible. However, they now might become visible in a > future > > redraw. What I didn't yet do is add the intelligence to be able to make > > the fieldset invisible initially but then to re-evaluate and have it > drawn > > it if any of its children become visible. > > > > As a partial work-around, you can set the configuration property > > "isis.viewer.wicket.redirectEvenIfSameObject" which will restore the > > previous behaviour. This is global, unfortunately. Do we think - until > > the bumps are smoothed out some more - that it would make sense to allow > > this to be enabled on an object-by-object basis (eg via > > @DomainObjectLayout)? > Enabling this on an object-by-object basis would work for me now. Most > objects don't have contributions or at least no contributed action for > multiple object-types where it should be hidden for some of these types. > > > > ~~~ > > Regarding the particular query you raise, I agree, if hideXxx() returns > > true then disableXxx() shouldn't be called. Could you raise a ticket for > > this, and if you have the time put together an example based on > helloworld > > or simpleapp that demonstrates the issue > Raised ISIS-1739 [1] and create a helloworld app [2]. See readme for how > to reproduce. > > > > Also (minor point) ... rather than using contributed actions, I would > > suggest you write a mixin for each instead. If necessary the mixins can > > delegate off to a supporting domain service for any common logic. > Will do that. > > > > Thx > > Dan > > > > On Mon, 25 Sep 2017 at 16:55 Erik de Hair <[email protected]> wrote: > > > >> Hi, > >> > >> I have some other hiding/disabling issues. Did anything change on how > >> methods are hidden/disabled? > >> > >> I have a contributed action that must be rendered on the first > >> parameter's page (OrderAbstract) on top of the page but shouldn't be > >> rendered on the other parameter's page. > >> > >> public Blob downloadDealerQuotationAsPdf(final OrderAbstract order, > >> final Contact recipient){ > >> Blob quotation = ... > >> return quotation; > >> } > >> public String disableDownloadDealerQuotationAsPdf(final OrderAbstract > >> order, final Contact recipient){ > >> if(order == null){ > >> return "Some dummy reason"; > >> } > >> if(order.getOrderLines().isEmpty()){ > >> return "No orderline added yet"); > >> } > >> return null; > >> } > >> public boolean hideDownloadDealerQuotationAsPdf(final OrderAbstract > >> order, final Contact recipient) { > >> return order == null || !order.getCompany().hasDealer(); > >> } > >> > >> As far as I can see the disableXXX method wouldn't be called in Apache > >> Isis 1.14.x when the Contact page was rendered, because this was > >> suppressed by the fact that the action was already hidden by the > >> hiddenXXX method. But now they're both called but when rendering the > >> Contact page it will fail due to a NPE on the first line of the > >> disableXXX method so I have to change this method to > >> > >> public String disableDownloadDealerQuotationAsPdf(final OrderAbstract > >> order, final Contact recipient){ > >> if(order == null){ > >> return "Some dummy reason"; > >> } > >> // actual disable conditions > >> ... > >> } > >> > >> Am I right here or did I miss something? (again ;-P ) > >> > >> Erik > >> > >> > >> > >> On 09/25/2017 01:59 PM, Erik de Hair wrote: > >>> Hi, > >>> > >>> On Apache Isis <1.15.x an empty fieldset would be hidden. On 1.15.0 > >>> the fieldset is still there but without any fields. Is that on purpose? > >>> > >>> Thanks, > >>> Erik > >> > > [1] https://issues.apache.org/jira/browse/ISIS-1739 > [2] https://github.com/erikdehair/ISIS-1739 >
