Announcing release of Naked Objects 5.4

Mar 18, 2013 at 3:23 PM
Edited Mar 18, 2013 at 3:23 PM
First, what happened to 5.2 & 5.3 ? The reason for the jump in numbering is that we are, henceforth, aligning the version numbers of the Framework (previous version: 5.1) and the ProgrammingModel (previous version 5.3), in order to ensure strict binary compatibility. (This is due to the fact that certain of the Naked Objects assemblies interact with each other via reflection, not just through the Api).

Thus, to run with version 5.4 of NakedObjects,Mvc, you should ensure that your model projects are all using ProgrammingModel 5.4. (As this is a second-digit change, there should be no need to change any of your domain code).

New upgrade process
We have changed the upgrade process, in response to difficulties that some users have experienced with previous upgrades. The previous package NakedObjects.Mvc has been replaced by two new packages: NakedObjects.Mvc-FreshInstall and NakedObjects.Mvc-Assemblies. As the name, and the accompanying description, hopefully make clear…
  • if you are installing into a new MVC project, you use ‘-FreshInstall’, which also adds the ‘-Assemblies’ as a dependency. Thereafter, you only upgrade the –Assemblies.
  • if you are upgrading an existing NO.MVC project (from 5.0 or 5.1) then you need to install NakedObjects.Mvc-Assemblies. Thereafter, you upgrade the –Assemblies.
The –Assemblies package upgrades the various NakedObjects assemblies, and also any other packages on which the core framework depends. It also adds into your project:
  • A .zip folder (e.g. NakedObjects.Mvc-files(5.4.0).zip) - containing the files, and .pp file templates, that would have been installed by NuGet had you used –FreshInstall
  • One or more .txt files that list which of those files changed since the previous version(s) e.g. FilesChangedSince5.0.txt, FilesChangedSince5.1.txt. (If you are upgrading from 5.0 you will need to read both.)
Take a note of which files you need to update, get files from the .zip, and do a manual compare and merge as needed. The number of changes is usually small, so you should be talking a few minutes work at most.

The net result of this change to the package install process, is that any upgrade will be a few more minutes’ work than before - but hopefully we will get less problems arising where developers have (legimately) customised files, which can take a lot longer to identify and resolve.

Significant enhancements
  • View Models are now properly supported. See the Application Developer Manual > Writing Domain Models > Programming Concepts > View Model. Note that this new pattern eliminates the most common need for storing transient objects on the session - View Models behave (from the perspective of the client) like persistent objects, but they are not in fact persisted.
  • It is now possible to return a FileAttachment from an action. As a by-product of this change it is now possible to return a scalar value from an action. Note that this is unlikely to be used in a deployed application (because a page that just says '35' with no other contextual information is of little value), but it can be useful as a temporary action to help in debugging, for example.
  • We have changed the approach to transactions slightly. Although the Persisted() and Updated() lifecycle methods continue to be called in a separate transaction (so, for example, the Id properties of the objects will have been set by then), this is now within a single super-transaction. So an error thrown within either of those methods will now cause the whole persisting/updating operation to fail. In addition, if, within those methods you were to create or modify an object that is held in a different DbContext, the persistence process will be called recursively to ensure that all contexts have been completely flushed before the transaction ends.
  • There is now an optional mechanism to associate domain types with a DbContext, which can result in better performance when you are working with multiple DbContexts in your domain model(s). See the Application Developer Manual > Writing Domain Models > Adding behaviour to your domain objects > Advanced Entity Framework techniques > How to work with multiple database contexts.
  • It is now possible to control visiblity of columns in a table view using custom authorization. See Application Developer Manual > Authentication & Authorization > Custom Authorization. (Note that we have changed code to use the 'z' spelling for authorization throughout. The 's' versions still exist but are obsoleted.)
  • The SetUser method on an XATs now allows you to specify the role(s) of the simulated user, in order to test visibility of properties/actions.
Bug fixes
In addition to the enhancements listed above, the latest release fixes a number of bugs and minor defects. For a full list of changes, please view the Issue tracker, selecting on Release 5.4.

A number of methods/types have been marked obsolete - and in most cases a replacement type/method is indicated. Although it is not necessary to make changes now, we recommend that you do take the opportunity to respond to any obsolete warnings. Obsoleted methods/types will not be deleted until the next major release (v 6) - which is not yet even in the planning stage.