+1 I also consider really useful a TabOrderService or similar that could allow define the tab order for a given Entity.
A default implementation could navigate from top to bottom, left to right, by groups. > El 20 abr 2016, a las 11:08, Stephen Cameron <[email protected]> > escribió: > > 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 >>
