Pull requests accepted for documentation pages too...! Perhaps add something to the release notes page for 1.12.0, at least? On 20 Apr 2016 7:38 am, "David Soff" <[email protected]> wrote:
> This is an awesome explanation which should be on the documentation site. > > On Wed, 20 Apr 2016 07:28 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. > > > > 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. > > > > 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. > > > > (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 > > > > > >
