Hi Kevin, I agree with you that we shouldn't have to force folks to use Xxx.layout.xml, it should be possible to get a reasonable layout using only annotations if necessary.
On that basis we shouldn't, after all, deprecate @MemberGroupLayout. This is the annotation that allows us to layout using multiple columns. For the record, the .layout.xml is still more flexible, and there are things that one can do with it that cannot be done only with annotations - tab groups being the most obvious. I don't think it's worth trying to maintain full parity between annotations and .layout.xml - trying to model tab groups in annotations would be horrendous - but on the other hand there's also no point in needlessly removing support we do already have with annotations. I've updated the wiki page accordingly. ~~~ Also, I've updated the wiki page to reverse my current suggestion on recombining types where there are multiple versions over time. For example, BookmarkService2 extends BookmarkService. In my first draft I suggested pushing the behaviour of BookmarkService down into BookmarkService2, and then removing the former. I now think it should be the other way around ... pull BookmarkService2's behaviour up into BookmarkService etc etc. Thx Dan On Sat, 30 Sep 2017 at 12:22 Kevin Meyer <[email protected]> wrote: > Hi Dan, > > I'm not sure what's the best way to comment - I have added a comment at > the bottom of the wiki page. > > In general I think it is a good idea to remove all functionality that is > redundant, and to consolidate where there are multiple ways to achieve the > same effect. I think most of your proposals fall into those categories. > > I may have slightly different preferences (I do find the > @Property(hidden=...) syntax more cumbersome than @Hidden, but its a > personal thing). > However I think code stability/maintainability is more important - I think > it's a good idea to reduce the number of ways to do the same thing, to > reduce the chance of bugs. > > The only thing (that I really noticed) that I wanted to raise was the > reliance on Xxx.layout.xml for ordering. Personally, I don't like the > idea of relying on "out-of-band" resources. We have a pattern of > specifying everything entirely in code, and now suddenly layout can only > be specified in XML. Is this correct? > > However, since I am one reviewer, I will defer if none of our users have a > problem with the layout.xml files. > > Thanks for doing this analysis! > > Cheers, > Kevin > > > On Sat, September 30, 2017 07:45, Dan Haywood wrote: > > Hi folks, > > > > > > > > I've started work on Apache Isis 1.16.0 in which we'll be updating > > DataNucleus to 5.1. This in turn requires moving to Java 8 as the > minimum > > to run an Isis app. Now that Java 9 is out, I think that's a reasonable > > minimum. > > > > > > Moving to Java 8 is in itself probably a good enough reason to rename > > this release as Apache Isis 2.0.0 (rather than 1.16.0). But in any case, > > one of the DN classes - TypeSafeQuery - is exposed from the Apache Isis > > applib and in DN 5.1 that class is renamed ... so backward compatibility > > is broken anyway. Since we aim to follow semver, we ought anyway to call > > this next release Apache Isis 2.0.0. Do people agree? > > > > ~~~ > > > > > > And, if that's the case, then we probably should look to remove other > > features that have been deprecated for a while. I've created a wiki page > > [1] and identified what I think should be removed, based on stuff > > currently deprecated in the applib, along with some "softer" stuff, such > > as the old Xxx.layout.json format. > > > > > > > > If you have any opinions on this stuff, please edit that wiki page. > > > > > > I'm intending for 2.0.0 to be done by the end of year. > > > > > > > > Thx > > > > > > Dan > > > > > > [1] > > > https://cwiki.apache.org/confluence/display/ISIS/ApplibCandidatesForRemova > > lInApacheIsis2 > > > > > -- > Kevin Meyer > Ljubljana, Slovenia > > >
