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)? ~~~ 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 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. 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 > >
