Thanks for the detailed explanation, and I am just as interested to hear others opinions too.
Taking a nationalist (fellow Aussie) stance, if thats the way Jira does it then its probably good. ;) The one major concern I have is simply the efficient manual entry of large amounts of data, maybe from a paper format, so being able to enter data by tabbing without using the mouse is still desired by some. Maybe there is a the need for another kind of viewer for this scenario? This conversation has been had before, with the workflow add-on suggested as a possible solution. But there is also the scenario of needing a printable form. I'd like to be able to maintain one version of a such a printable 'form' only, that is to design something that can be printed and handed to be people for filling out, but which in its electronic form can be used for easy data-entry straight into the database. I've considered using Orbeon Forms (an XForms framework) in concert with Apache Isis as the solution to this issue. With JAXB support now in Isis it does seem like a nice combo, XML from the XForm into Apache Isis (and database) via JAXB. See a few inline comments below On Wed, Apr 20, 2016 at 4:28 PM, Dan Haywood <[email protected]> wrote: > Hi Steve, > > Thanks for the feedback. > > There are several reasons why I've made this change, some practical, some > more philosophical. > > The practical reason is that with tabs, it's not particularly clear what a > global edit should be... should it be for all properties, including those > not visible on other tabs? or should it somehow disable being able to > switch tabs when in edit mode? or perhaps there should be not a global edit > but instead an edit per fieldset/member group? It wasn't at all clear > which was preferable. > > Second, we've had a ticket knocking around for a while to move editing > towards that in JIRA, where one clicks in the field and then can do an > in-situ edit. The current implementation isn't quite a slick as that, but > the number of clicks is actually the same. > > The philosophical reason is that, actually, it positions the framework away > from the common perception of it being a CRUD framework; instead it is also > for (even mostly for) complex domains where the is significant business > logic to transition from one state of the system to another. When Jeroen > was implementing Estatio he deliberately made all fields read-only (in > stark contrast to the packaged application it replaced), not because there > wasn't a requirement to allow the data to be changed, but instead he wanted > the business users to come back to him and explain WHY the data should be > changed. (For example, changing the end of a tenancy date has impact > elsewhere). So it helped us get a deeper insight into the domain, and we > encoded that insight into actions. > > This is where I am departing in that what I have is essentially a CRUD app. Such an app with multiple viewers, all easy to maintain, and with the capacity for adding complexity where necessary (via actions, different user authorisations) is still a very good thing to have. > For the big Naked Objects system in Ireland, we also only have actions, no > edits... eg award a pension claim or disallow a jobseekers allowance > claim. Even for small stuff, eg a customer wants to change their phone > number, then this is an action because we then want to retain the old > address on file in a list of previous phone numbers. > > So I don't think that de-emphasising edit mode takes us away from the naked > objects pattern. > I kind of see your point, but maybe it would be nice to make this configurable, that is non-edit is default and you add actions to change state, or, edit as default and no actions needed? (the later to please us crudites, its a web-form mode I feel). > > In terms of changes to the viewer... as I say: eventually I intend to > implement in-place edits, which will remove the buttons. Another > short-term option might be to move the edit icon to the right of the field > (same place that actions go if positioned to the right). A medium term > option might be to introduce an edit button for the entire fieldset, but > I'm not completely convinced that it's necessary. > Just moving the edit icon to the right as a short-term option would be good. > > (By the way, the change has nothing to do with JAXB view models being > editable). > > Let me know your thoughts... and others reading this, too, please! > > Thx > Dan > > > > > > > > > > On 20 April 2016 at 03:00, Stephen Cameron <[email protected]> > wrote: > > > Hi, > > > > I want to give a little feed-back on the addition of the edit button to > the > > bottom right of each editable control. I note that this is probably a > > temporary thing but I'm not very keen on it so encourage a change to be > > made. > > > > My problems with it are that its pushes the next control down the page > and > > wastes space, and it means more actions if you are editing more than one > > item. > > > > One solution is to make all controls non-editable and provide a > mass-update > > action inside each group, this seems common in Estatio, but I don't see > it > > as a good practice get into, unless common workflows suggest it, there > is a > > far bit of work to do it and it seems to take you away from the Naked > > Objects paradigm. > > > > The question is what is the best solution? > > > > Personally I thought the global Edit (mode) button was fine, its pretty > > standard. But placing it in the left column under all the groups did have > > the undesirable effect of pushing it down out of sight sometimes. With > tabs > > that is not a good solution either, i.e on the first tab, and putting it > > under the tab-panel not any better. > > > > One solution is to put it into the first 'title' row of the page, but > > aligned on the right-hand side to differentiate is from other actions > that > > might be there, its kind of an action button. > > > > Having tabs is very welcome though, so now I have a dilemma. Go to 1.12 > or > > wait to see if the edit buttons disappear in 1.13. I am inclined to stay > at > > 1.11. > > > > Of course, as mentioned, there were issues associated with making JAXB > view > > models editable. If this has led to too much complexity in the viewer > then > > maybe it wasn't such a good move? My concern with that aspect has been > that > > conflating JAXB and a View-model mode. > > > > I hope this is of some usefulness. > > > > Regards > > Steve Cameron > > >
