ISIS-497 ... contributed associations (properties and collections)

[Dan Haywood <da...@haywood-associates.co.uk>]

Folks,

just to publicise a significant new feature that I've implemented.

In Estatio [1], we've taken some care to layer our modules; for example the
finance package depends upon the parties package, but not vice versa.  Each
finance.BankAccount knows its owning party.Party,but the Party does not
know of its bank accounts.

While this provides a clean architecture, the downside of this is that it
is not possible to view the parties accounts as if they are a collection.
 The best that has been possible is to invoke a contributed action, eg on
the Party, contributed by the BankAccounts service.  However, this takes
the user to a different page (in the Wicket viewer), so they lose the
context of what they were looking at.

In ISIS-497, I've extended the concept of contributed actions so that any
service action that is a single-argument for is non-void will be displayed
as a contributed property or collection (dependent upon its return type).

The ToDoItem example demonstrates this:
- the ToDoItem#similarItems collection has now gone, but the
ToDoItems#similarTo(ToDoItem) action is rendered as a contributed
colleciton.
- a new ToDoItems#priority(ToDoItem) action is rendered as a contributed
property.

The @NotContributed annotation has also been enhanced:

@NotContributed  ... not contributed at all
@NotContributed(As.ACTION)   .... but is contributed as a
property/collection (dependent on return type)
@NoContributed(As.ASSOCIATION) .... but is contributed as an action

Contributed collections are implicitly eagerly rendered.

Contributed properties can also be hidden from tables by annotating the
service action with @Hidden(where=ALL_TABLES), in the usual fashion.

~~~
I suspect that this new feature could make it much easier to keep designs
decoupled; these service actions are somewhat akin to traits/mixins of both
function and data.  (Indeed, Jeroen and I were talking a few days ago about
how Isis is as much an AOP framework as it is an OOP framework... these
contributed Xxx mixins are further evidence of that)

Note: there are still some issues with contributed actions; most notably
the supporting choices/default/ validate/disable aren't picked up.  I
intend to address that next.

As ever, feedback welcome

Thx
Dan







[1] https://github.com/estatio/estatio