Strandz is an application programming framework that has been specifically designed with two principles in mind. The first is that Strandz applications are maintainable. A by-product of this is that there is only a small amount of code required per unit of functionality. Another by-product is that they are quick to get up and running. The second principle is that the dependencies of a Strandz application can be 'plugged-in'. Thus all Strandz applications will be easy to modify and resilient to changes to the user interface (UI) toolkit or database access software they use.
With Strandz the programmer constructs a 'wire outline' of the database application and then programs to it. Programming to a wire outline not only provides portability, which flows through to longevity and hence a lower total cost of ownership, but also significantly reduces the amount of work that a programmer has to do. Although a deployed application will of course usually require UI and database layers, the application logic is independent from those layers and hence simpler than would otherwise be the case. Additionally the logic can use the services provided by the wire outline - the kind of services that are required in almost all projects. With this approach Strandz applications are faster to write and easier to maintain than those written with any other framework.
The developer can 'program to the wire' at either or both design and runtime. Thus despite the framework's usefulness for straightforward CRUD applications, it can also be used as the basis for highly configurable programs.
Strandz is a domain driven development framework that targets rich-client software applications. From the front-end point of view it takes care of application binding and controller requirements. And from the back-end point of view it talks to POJOs as well as other types of data objects.
Strandz comes with a datastore independent data access layer. Having this access layer means that the same application can be configured to work with data that comes from lists in memory or one of several object-relational mapped data sources.
For any Strandz application screen to function the developer will have specified how its controls bind to the data fields of the domain model. Application screen controls are bound to the underlying data objects in a 'big picture' way: the application's runtime code is able to access a meta-object model that describes the master-detail and lookup relationships that the user's actions will be invoking. This is the 'wire outline' we mentioned earlier.
These special meta-objects are of type Application, Strand, Node, Cell and Attribute. In a typical application they are created and organised in a 'drag and drop' design time tool. It feels as if you have your design documents with you at all times whilst maintaining the project, and it is assured that the meta-information they contain will always be kept up to date. Because these SdzBeans can optionally be worked with (even created) at runtime, the framework can meet the most demanding user-interaction requirements.Translation to Om Next
Strandz has been designed to be able to carry its applications through changes in technology. Om Next is similar enough that application translation should be possible. Both systems have the idea that an app describes its structure, which the framework then picks up on. Both systems 'look inwards', which means that complete applications can be build without a UI or a back-end / database.
There are three parts of an application that need to be translated. The front and back ends will just need to be re-written - the front end as Om components and the back end as Datomic, using the Untangled framework which sits on top of Om Next. The middle and third part is the most interesting as it allows us to compare the two frameworks.
Where Strandz has master-detail and lookup relationships Om Next has one to many and one to one joins. So the structure of the application should remain unchanged - we already know what all the idents should be. With stub components we should be able to rapidly get the default db format version of our application built, enough to be able to write tests. So that's the start - the UI can be done independently and at the same time. In theory the Datomic database should look just like the client-side app db, especially since we used ORM and so brought the database over to the client anyway.
It goes without saying that Om Next applications will be superior to Strandz applications - ClojureScript/Om Next is functional and more flexible than Strandz could ever hope to be. However Strandz is 'higher level'. Thus there are abstractions and tooling ideas here that can be put on top of Om Next.