This one is really for Rob to respond to...
~~~
Rob,
You might have seen that in ISIS-497 [1] I've extended the concept of
contributed actions to also incorporate contributed associations
(properties or collections). For example, a service action:
public class ToDoItems {
public List<ToDoItem> similarTo(ToDoItem t) { .. }
}
is rendered as a collection on the ToDoItem.
>From an implementation perspective, basically these are ObjectAssociation
objects that I create on the fly (of type OneToOneAssociationContributed or
OneToManyAssociationContributed) which are backed by the underlying
ObjectAction.
What I'd now like to do is to refactor the contributed actions in the same
way: create an ObjectActionContributed whose target is the contributee
entity (eg ToDoItem), which delegates to the service's ObjectAction. This
would allow us to suppress the entity parameter when rendered, and ought to
make it easier to fix the issue that choices, defaults, validate etc are
not currently picked up for contributed actions.
None of the above is controversial, I think.
~~~
However, I'd also now like to look at ObjectActionSet, which we use to
group actions. At the moment when there are contributed actions from a
service, they get wrapped up in an ObjectActionSet; thereby creating a
hierarchy. As I recall the DnD viewer uses this to render the contributed
actions in submenus. Perhaps Scimpi does too, I don't know.
However, I think this is conflating concerns; I think that the layout of
members should be independent of where the functionality lives (on the
entity or on a contibuting domain service). The Wicket viewer now uses
MemberOrder facet and MemberGroupLayoutFacet to do its rendering; this
information can now also be captured in a JSON file [2]. I would like to
be able to specify contributed actions (and indeed associations) in this
file.
The current design has
ObjectSpecificationDefault#introspectTypeHierarchyAndMembers() use the
MemberLayoutArranger to create an ordered set of actions, but this is only
for the entities actions, not contributed actions. The contributed actions
are computed lazily afterwards. Also, the MemberLayoutArranger's API
assumes that there's a backing FacetedMethod, which won't be the case if
its responsibility was also to order contributed actions. The net effect
for me is that it isn't currently possible to order contributed actions,
nor contributed associations, using this mechanism; they simply appear
"last".
My proposal is therefore
- (a) to remove the hierarchy of contributed actions, so that everything is
flat
- (b) remove the ObjectActionSet
- (c) rework the MemberLayoutArranger
- (d) calculate the contributed actions eagerly
Rob, know you haven't committed anything on DnD viewer or Scimpi viewer for
a long while (and they still haven't been formally released), but I presume
they aren't dead. If I go ahead and make this change then it shouldn't
break them, but they may need to be enhanced to start parsing the
MemberOrderFacet and MemberGroupLayoutFacet (similar to the way that the
Wicket viewer does this).
~~~
Rob (or anyone else, of course), if you have any opinions on this, let me
know. Otherwise I'll press on with this simplification.
Dan
[1] https://issues.apache.org/jira/browse/ISIS-497
[2]
https://github.com/apache/isis/blob/869668e2cb75447f4c1f783d0164f5a1797a5832/example/application/quickstart_wicket_restful_jdo/dom/src/main/java/dom/todo/ToDoItem.layout.json
