On 16 December 2014 at 21:48, GESCONSULTOR <[email protected]> wrote: > > Sorry about expressing my opinion here :) > > Please do continue to do so :-)
> I've always love the way Jora works, editing each field without needing > the update button. > s/Jora/Jira ... presumably > That way it shouldn't be needed to always implement actions, as the > property setter can be intercepted by ISIS as the setter is wrapped inside > the viewer. > > I'm not suggesting that we get rid of property setters either. And yes, the modifyXxx and clearXxx are the places to put additoinal business logic (they represent the API, while the getter/setter is really the SPI for the viewer and for the objectstore). So Isis as a platform needs to support this use case. But it's also worth noting that with Estatio we've found ourselves moving away from property setters, to the extent that we (or rather, Jeroen) eventually got rid of them altogether. One reason is that there are, indeed, many quite complex use cases in that product. But the other reason we got rid of them is also very interesting, I think: to drive out the user requirements. To backfill on this a bit... Estatio didn't start out with an empty database, rather data was migrated (via Isis' REST API, in fact) from the legacy packaged system. Originally Jeroen started out leaving things as editable, but discovered that the users used the app somewhat like a spreadsheet, so that the business rules would remain in their heads. By making the data immutable, it forced the discussion of "why do you want to edit the data"... from which the real objectives could be gleaned. The point being, of course, that if an action was required, then it could be implemented and deployed very quickly (often the same business day). > Actions would only be needed for complex use cases, such as updating > multiple properties or entities from it. > > if a modifyXXX or clearXXXis present it would execute custom logic without > needing and explicit action. > > Do you agree? > > But yes, this is also a use case we should support. One gap though is that we don't yet capture @Command for property edits, so we don't get the same richness of profiling/auditing, nor do we get the ability to execute such edits "in the background". Perhaps that's less important. Also... for completeness, Isis / Naked Objects has always also supported the concept of mutable collections; it's just that the Wicket viewer has never implemented them (the Restful Objects viewer does, though). In code these correspond to addToXxx and removeFromXxx supporting methods (along with hideXxx, disableXxx, also validateAddToXxx and validateRemoveFromXxx). > I think it's really interesting to discuss it here as it would be a > completely new paradigm. > > Certainly having the ability to edit a single field at a time would be a better user experience. Don't think it's a new paradigm though, just a better UI to an old concept. Cheers Dan > Thanks for raising this question. > > > > El 16/12/2014, a las 21:59, Dan Haywood <[email protected]> > escribió: > > > > @Boris, > > Although being able to edit properties is initially convenient, what > we've > > found "in real life" (that is, Estatio) is that most if not all > operations > > should be modelled as actions. > > > > Using actions allows you to more accurately capture the use cases/goals > of > > the user. They also support @Command and @PublishedAction which are > great > > for both auditing/profiling and also system-to-system integration > > scenarios. > > > > But did I misunderstand your question, please say... > > > > > > @Martin > > In ISIS-784 [1] we discussed an enhancement so that each property could > be > > edited by itself, rather than placing the entire form into an edit mode. > > On that ticket is a link to a widget library that I think you found? > > Anyway, I'm still keen on that, I think Jeroen is too. > > > > > > Cheers > > Dan > > > > > > [1] https://issues.apache.org/jira/browse/ISIS-784 > > > >> On 16 December 2014 at 20:28, Martin Grigorov <[email protected]> > wrote: > >> > >> Hi, > >> > >> I have asked myself the same question recently. > >> > >> Martin Grigorov > >> Wicket Training and Consulting > >> https://twitter.com/mtgrigorov > >> > >> On Tue, Dec 16, 2014 at 8:22 PM, Boris Toninski < > >> [email protected] > >>> wrote: > >>> > >>> Hi guys, > >>> > >>> what I have seen till now in the demos is that when you open a form > for a > >>> entity, all fields are disabled. You have to firs click on the edit > >> button > >>> to edit the properties. > >>> > >>> Is this the recommended way of using Isis. Would there be some problems > >> or > >>> difficulties if the form is ready to be edited when opened? > >>> > >>> Thanks in advance! > >> >
