Yes, this feature would be great one! In one application (non Isis but Eclipse RCP) we developed times ago, we had UI style guide where each input field can have warning/information/error depending on current user input (ideally giving feedback on each keystroke or when list selection happened). Additionaly, whole dialog (if modal) can provide same feedback to user, when e.g. multiple input values in their combination lead to invalid state...
Would be interesting if this feedback/validation could be (partially?) delegated to browser JS engine and so reduce network overhead but at the same time keeping the beauty of Isis programming model? Regs,Vladimir Am Fr., 23. Nov. 2018, 17:06 hat Dan Haywood <d...@haywood-associates.co.uk> geschrieben: > Yeah, I think this is a great idea. > > How about "advise" as a prefix to me; as in we are providing advice. Also > sounds "softer" in tone than "warn". > > I guess it'll introduce a new phase ... hide, disable, validate, advise, > executing, executed. So might be quite a bit of work to implement, but I > can see the value. > > What do others think? > > Thx > Dan > > On Fri, 23 Nov 2018 at 15:56, Sander Ginn <san...@ginn.it> wrote: > > > Hi, > > > > We’ve had a number of support requests relating to new users of our > > application that are not yet fully familiar with their business process. > > We do not wish to invalidate input as many business rules are not clearly > > defined in a ‘correct/incorrect’ fashion, with many exceptions and > special > > cases. > > > > As a middle ground, I would like to propose an extension of the metamodel > > with a support method similar to validateXxx(), which renders the > familiar > > dialog and warning message underneath the input field with another colour > > (yellow, probably) but does not block the user from completing the > action. > > > > Does anyone else consider this to be a useful addition, and if so, what > > would be a good method prefix? My first thought was warnXxx(), but that > > does not make a lot of sense syntactically; after all, we aren’t warning > > the action in question (as opposed to validate/hide/disableXxx()) but the > > user instead. > > > > Best > > Sander Ginn >
