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
