+1 on all that. I'll go ahead and make these changes, hopefully later on this week if I get time.
Thx Dan On 20 August 2013 16:01, Robert Matthews <[email protected]> wrote: > On Tue, 20 Aug 2013 12:58:55 +0100 > Dan Haywood <[email protected]> wrote: > > Dan > > The flattening is fine - makes a lot of sense. The end result should > still (or needs to) allow grouping such that for > > - a() for employment > - b() for billing > - c() > - p'() -> p() for employment > - q'() -> q() > - w'() -> w() for billing > - x'() -> x() > > would mean that the viewer could tell that actions a() and p'() and > actions b() and w'() are related to each other in the pair but not to > to the other pair. > > Regards > Rob > > > > > Rob, > > Replies inline, and cc'ing [email protected] for visibility > > > > > > On 20 August 2013 12:09, Robert Matthews <[email protected]> > > wrote: > > > > > Dan > > > > > > Without responding to the whole message at once I'll just start > > > with a question. > > > > > > My usual response, as you know (but others might not), to questions > > > about encoding "UI" attributes into the domain model is to state > > > that the added information is there not to control the user > > > interface specifically but to show how people expect to deal with > > > the information. So taking the case of member ordering, we humans > > > (culturally?) expect to see names and addresses grouped together, > > > and specifically the road name before the town and post/zip code. > > > > > > Similarly, the way that actions are related naturally > > > (for us mere mortals) makes us group them, so actions in the Company > > > class that deal with employing people go together and should not be > > > intermingled with those actions that deal with bills and payments > > > for example. > > > > > > Obviously when we render them on the web or via a GUI we'd like > > > them to maintain that order. When they are shown in lists and in > > > debug logs that order is useful as well. All because humans are > > > looking at it. It's quite likely that we use that the same order > > > exists in our code because it makes it easier for us to read it > > > later. > > > > > > So, first off, I think it is important that we maintain these > > > attributes of the model. > > > > > > > Agreed... that's not being debated. > > > > Just to recap what we currently capture in the metamodel: > > > > We have @MemberOrder, as we always have, where: > > - for properties, @MemberOrder#name is used to group members together > > (the name being an arbitrary group name) > > - for collections, @MemberOrder#name currently has no purpose > > - for actions, @MemberOrder#name associates the action with a > > property or collection (the name being the name of the > > property/collection to associate with) > > > > We also have @MemberGroupLayout, that defines four columns: > > - the first three columns lists property groups in order (as defined > > above by properties' use of @MemberOrder#name) > > - the last column lists collection names > > - there is also a hint specifying the relative width of each of these > > columns > > > > The new Xxx.layout.json file allows this information to also be > > specified outside of the domain model, but underneath the covers it > > all corresponds to the same MemberOrderFacet and > > MemberGroupLayoutFacet. > > > > > > > > > > > > > > That said I'm not convinced that the ObjectActionSet is > > > necessarily/always used for this. Dan, as you've got your head in > > > that part of the code, can you explain when these are sets are > > > created. I can't recall what we can do within the domain model to > > > get these sets and I'm not seeing them in the specification debug > > > output. I've got the feeling that I might be thinking about the > > > wrong thing. > > > > > > > Here's how it works: > > - the entity actions are stored in the > > ObjectSpecificationAbstract#actions field. These are sorted by > > @MemberOrder#sequence. This is populated eagerly in the > > bootstrapping. > > - when ObjectSpecificationAbstract#getObjectActions() is called, the > > contributed actions are lazily discovered. This is done by service. > > If a given service does contribute actions, then we create an > > ObjectActionSet to group them together, with the contributed actions > > being the leaf. The new ObjectActionSet is then appended to the > > #actions from above. > > > > For example, if an entity E has three of its own actions a(), b(), > > c(), and service S contributes actions p() and q(), and service T > > contributes actions w() and x(), then the actions we return are: > > > > - a() > > - b() > > - c() > > - ObjectActionSet for service S > > - p() > > - q() > > - ObjectActionSet for service T > > - w() > > - x() > > > > In the Wicket viewer, I call a "flattening" action that basically > > ignores the intermediary ObjectActionSets. So for the above list, > > this would be simply: a(), b(), c(), p(), q(), x(), w(). > > > > When the Wicket viewer renders the object form, it filters this list > > by the MemberOrder#name, so that those actions not associated with > > properties/collections are displayed in the header by the icon/title, > > those associated with properties/collections are rendered close by > > that > > > > > > > > > How does the MemberOrder relate to ObjectActionSet? > > > > > > It orders the entity's own actions (a(), b(), c()), and it also > > > orders the > > actions within the OrderActionSets (p(), q()). > > > > ~~~ > > > > Note, though, the refactoring that I've just done has simplified a > > lot of the internals. You might remember that an ObjectActionImpl > > had an "isContributed()" method, and there was quite a lot of > > special-case code to handle this situation. Now, though, I create > > new ObjectActionContributee actions that wrap the underlying service > > Actions. > > > > So, for the above, what we actually have is > > > > - a() > > - b() > > - c() > > - ObjectActionSet for service S > > - p'() -> p() > > - q'() -> q() > > - ObjectActionSet for service T > > - w'() -> w() > > - x'() -> x() > > > > where p'(), q'() etc are these new ObjectActionContributee. > > > > The benefit of this is that, to the rest of Isis, it doesn't know > > about contributed actions as a concept; every action appears to be an > > entity action. I also transparently adjust the parameter list too; > > where S contributes p() to entity E: > > > > public class S { > > public void p(E e, int f, String g) > > ... > > } > > > > the corresponding p'() appears to the rest of Isis as: > > > > public class E { > > public void p'(int f, String g) > > } > > > > > > ~~~ > > Anyway, my original question was about getting rid of > > ObjectActionSets as the wrappers of these contributed actions; in > > other words to hold the entity's actions in flattened form: > > > > - a() > > - b() > > - c() > > - p'() -> p() > > - q'() -> q() > > - w'() -> w() > > - x'() -> x() > > > > If this is done, then the actions could be ordered irrespective of > > whether they were contributed or not. > > > > > > Dan > > > > > > > > > Maybe talking this though might be quicker. > > > > > > Regards > > > > > > Rob > > > > > > > > > PS btw sending this to my personal address unfortunately didn't help > > > distinguish it from any other Isis emails, as all emails from > > > [email protected] get moved to the Isis folder. I guess the thing > > > to do is send it one of my other accounts. > > > > > > > > (I sent the mail to you directly from my personal mail, as well as to > > [email protected]) > >
