Griffon 2.1.0 Release Notes

In previous versions instances of MVCGroup would let you create other MVCGroup instances, with no direct relationship between the two unless explicitly stated (via an additional argument Map). This is no longer the case.

Child groups may now have a direct relationship with the parent group that created them. The parentGroup property will be set to the correct MVCGroup instance in every group member that defines it. Fine grained parent properties matching each member (such as parentController, parentModel and parentView) will also be set automatically. There are 2 sample applications that demonstrate this new feature in action

MVCGroupManager added getter/finder methods for Controllers, Models and Views. Finder methods may return a null value if the matching artifact was not found. Getter methods on the other hand will throw a ArtifactNotFoundException if the artifact could not be found.

The MVCHandler interface has been altered to better handle MVCGroups. Methods that sport MVCGroup in their name work with instances (createMVCGroup and withMCGroup) of MVCGroup, either they take such type as argument or return instances of it. In contrast, methods that only have MVC on their names (createMVC and withMC) work with individual MVC members, such as Controller, Model and View. The following table summarizes the changes

Finally, base artifacts such as Services can no longer create new MVCGroups by themselves, as this capability has been removed from the base GriffonArtifact interface.

The ActionHandler interface supersedes ActionInterceptor interface, as it delivers a much better abstraction for configuring, handling and updating actions an their properties. ActionManager also gained the capability to update an action or a set of actions.

GriffonAddons now have the capability of supplying startup groups. These groups are initialized during the STARTUP phase, right after the startup groups defined by the application.

The java.util.ServiceLoader class allows you to load instances of a particular type as long as it conforms to the following rules

However sometimes you’d need to load types in a similar fashion without being forced by the last 3 rules, that is, you may want to load a type that is an interface or that provides a constructor with one or more arguments. If you ever encounter this scenario then annotate the classes/interfaces with @TypeProviderFor and load them using ServiceLoaderUtils. For example the griffon-mybatis-plugin loads instances of MybatisMapper using this mechanism.