Hi Dan. For me Jira has always been an inspiration. So I would love inbound editing, as it would hide if the property has or not a modifyXXX method associated (or a clearXXX one) when Domain Rules are placed.
That ways there's no need to implement its single change through an action. Obviously actions will still be needed if the express other intents in addition to execute business logic each time this property is modified (directly or indirectly invoked by actions inside a "wrap(...)"). Thanks, Oscar > El 20 abr 2016, a las 8:37, David Soff <[email protected]> escribió: > > 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 >>
