JADE Environment Development Ideas

What's new in the upcoming JADE release?

IMPROVED DEVELOPER EFFICIENCY. ENHANCED SECURITY. SMOOTHER INTEGRATION

The JADE 2022 release meets tomorrow’s business demands.


Start your update to JADE's latest release

Abstract Form Class Support

It'd be useful if we could access the 'Change...' function for form classes in order to set them as being abstract, along with other class level options (final, subschema hidden/final).

For applications where we provide the ability to open forms in a generic/dynamic way, we have to explicitly exclude abstract forms.

If we had the ability to specify a form class as abstract, we'd gain the ability to define abstract methods which helps to ensure methods are re-implemented when required.
  • Kevin Saul
  • May 1 2019
  • IDE Backlog
HistoricalComments
Brian Johnstone 9/10/2018 2:22:21 PM
"We do have real forms that also have subclasses". I wondered if that may be the case. We have a development standard in our product that only 'leaf' classes can be 'non-abstract'. The term 'leaf class' is our way of referring to a class with no subclasses, mostly because it's rendered with the 'leaf' listbox graphic in the class browser in the IDE. Whilst abstract can't be set currently, for forms, we still take the approach that we will never create/show forms which are not 'leaf' classes, in the same way we can never create instances of non-leaf classes for our non-form classes.

Kevin Saul 9/10/2018 12:14:01 PM
Thanks :) We do have real forms that also have subclasses, so can't make that assumption. Window::tag is a reasonable suggestion, but in my experience getting everyone to tag/set things in the right way for the sake of generic functionality they're not necessarily using/checking during their form development is a headache. Prior to explicitly registering abstract forms, which I think all my colleagues find to be a clear approach now, I initially set things up to exclude forms when the visible property was set to false in the painter, with the intention we essentially treat that like an abstract flag. However, that approach ultimately failed because the visible property is copied when you subclass a form, so we ended up in a situation where forms would be hidden unintentionally until someone realised & set the visible property to true on the real subclass.

Brian Johnstone 9/10/2018 10:41:20 AM
Nice idea. I've wanted to be able to add abstract methods to superforms a number of times. With regard to the generic/dynamic opening of forms and your currently explicit excluded list of effectively abstract forms, in the interim if you're not already using the Window::tag property for anything else you could set this to say 'Abstract' in painter for forms that are effectively abstract and then use that to generically exclude all forms with 'Abstract' set in the Window::tag property in painter. Not quite as nice, but maybe easier to maintain that a hard-wired list of forms. Alternately, you could automatically exclude any forms which have subclasses, as presumably your 'real forms' are all forms that have no subclasses and all your forms that do have subclasses are effectively abstract?
  • Attach files
  • +4