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])
