Good input, thanks. My experience both with Estatio (4 years) but also with the big Naked Objects system in Ireland (12 years) is that actions only is good enough in the vast majority of cases ; and where bulk input is genuinely needed, then we can usually address it with a little lateral thinking.
For Estatio, there's an occasional requirement to bulk upload new tax rates, and for that we use the isis-module-excel that allows the users to just upload an excel spreadsheet and process that. Works quite well. The risk of allowing general free - form editing in ERP systems is that users are liable to abuse the freedom... we saw this for example in the packaged software that Estatio replaced... spare /unused fields end up being co-opted to store all sorts of adhoc info. Instead, we should be exploiting the fact that Isis allows such rapid development by keeping things tight: relying on actions only means that the conversation as to *why* the data needs to change can be had, resulting in a richer ubiquitous language/insights/domain model. All that said, we'll continue to evolve and improve the default UI, and to make it easier to allow it to be extended for use cases such as this. One option is different UIs, or to use custom UIs based on the Restful viewer, but they are completely different experiences from an end-user perspective. Another more seamless/smoother integration might be to leverage the nowicket framework which allows custom Wicket forms to be developed quite easily; we've been in touch with its developer, and have started spiking some things. Hope that helps explain some of the rationale a little better. Thanks, Dan http://invesdwin.de/nowicket/introduction Hello. I have to agree with Steve and Hector. In my experience creating and implementing ERP and large Merchandise Management systems, the ability to change all fields within a TAB combined with in-line row entry and editing is a must in a system where you handle a large volume of transactional data entry (we have been extensively using those features for the last 25 years or so in our systems, and the users strongly request them). As an example use case, a user must enter sometimes tens or even hundreds of rows (a purchase order line item detail, a price change batch line item, journal entries and so on). Just try doing that using the mouse and going back and forth on each row. Luckily in our current applications we are building with Apache ISIS, we are managing most of the data entry on the mobile devices, which handle this in-line editing and all form editing easily, leveraging the amazing ISIS capability to create web services from actions. But we do not see us using the current Isis forms for that a system where there is volume data entry in the browser. Having the ISIS ability to associate actions to enter a group of fields / properties together and trigger some action is beautiful, but I do not think it should replace all form editing nor in-line row entry and editing, but they can both work as a complement. I've heard from Dan that ISIS will have additional viewer options in the future as a result of its open hexagonal architecture and some join efforts with the NakedObjects guys, which sounds great!. I hope they might bring us some UI friendly features like those. I recognize there have been some recent significant improvements to the UI configuration, and hope there will be in-line row entry and editing and back to all form / all TAB editing soon. Cesar. On Wed, 2016-05-25 at 05:14 +0000, Dan Haywood wrote: > Well, editing is enabled by default, so CRUD is supported. We certainly > don't want to make the framework deliberately difficult to use. > > I think the best thing for me to say is that editing properties is a > work-in-progress, and where we're aiming to get to is a JIRA-like > look-n-feel. If it works well enough for that app, then I think it should > suffice for Isis too. > > Thx > Dan > > > > On 25 May 2016 at 03:36, Stephen Cameron <steve.cameron...@gmail.com> wrote: > > > I know this has been discussed previously, but it seems such a central > > thing that I have to add my two-bits worth again. > > > > Re: "it positions the framework away from the common perception of it being > > a CRUD framework;" > > > > Any database application is at its core a CRUD application, unless its view > > only. So the key thing, surely, is to show people how much more Isis can do > > and how easily. It seems you want to be deliberately unfamiliar to users in > > order to show that its different to those other 'CRUD in five minutes' > > frameworks. > > > > Making a group of properties read-only and providing an action to update > > all the properties together is a useful pattern, but you seem to be > > suggesting that this is the right way to do it everywhere because Estatio > > is done that way. > > > > I think the in-situ editing will be good as a default behaviour. > > > > On the upside, I think Isis is now a very sweet framework to use in many, > > many aspects. There is still alot for me to learn, but I am keen to do > > that, and try to convince others of its merits too. > > > > Cheers > > Steve > > > > > > > > > > > > On Tue, May 24, 2016 at 4:00 PM, Dan Haywood < d...@haywood-associates.co.uk > > > > > wrote: > > > > > Hi Hector, > > > welcome to the users@ mailing list. > > > > > > I'm afraid that there isn't a setting to go back to the previous > > behaviour, > > > but there are some good reasons - some practical, some more > > philosophical - > > > why this change has been made. > > > > > > 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 [1] 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. Again, the action > > > helps capture the intent. > > > > > > ~~~ > > > If you want to allow an object's properties to be changed in bulk, then I > > > recommend that you add an action that accepts all the fields, and > > position > > > that action on a top-level panel. We do this for the contactapp [2]. > > For > > > your remaining more complex objects, I suggest that you sprinkle in some > > > tabs, by way of recompense. > > > > > > > > > Hope that helps > > > > > > Dan > > > > > > [1] http://github.com/estatio/estatio > > > [2] http://github.com/incodehq/contactapp > > > > > > > > > > > > On 23 May 2016 at 21:13, Hector Fabio Meza < hector.m...@smartools.com.co > > > > > > wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > My company has been working on an Isis application in the last few > > > > months, and after the changes to the edit functionality on 1.12.0, our > > > > test users are asking if it's possible to put the whole form in edit > > > > mode instead of doing it field by field. > > > > > > > > Is there a way to tell the wicket viewer to use the previous behavior, > > > > i.e. an edit button that affects the whole form? > > > > > > > > Thank you. > > > > > > > > Hector Fabio Meza Martínez > > > > R&D Leader > > > > www.smartools.com.co [1] > > > > > > > > Links: > > > > ------ > > > > [1] http://www.smartools.com.co > > > > > > > > >
