Typed Query Release

Besides more technically driven details the breaking API-change in the BeanFactory interface is the main feature of this release.

Type Queries

BeanFactories now are generic types and introduce type-safe access to the underlying storage-solution's query types. This way queries don't need to be mere strings and with many APIs it is not possible to use the whole query functionality with string-representations of query expressions. This was needed to complete the work on the morphia integration.

Along with that integration the dynamic data model feature was also introduced when using morphia like it can be used with JDO. Using this feature, you can add model/persistent classes placed in the repository and thus be changeable and extendable on runtime.

Change in Google Guice integration

During the maintenance of release 1.1 we ran into trouble with the mycila JSR250 stuff which was used from the Googe Guice module integration. We provided the needed changes for mycile for 1.1 while adding a custom, limited JSR250 integration directly here.

This release only contains the latter module. Feedback is welcome, which solution fits better.

Library Update List

The update-list of the work during the passed months includes among others

• Spring 4.3
• Java 8
• DataNucleus 5.0
• JDO 3.2 pre-release
• Dinistiq 0.6

To unify library usage, commons-lang3 was removed from the list in favour of commons-lang, which is used by velocity.

The test coverage is now at a 90%-ish level.

Consolidation Release - Update

The 1.1 release is a consolidation release removing outdated stuff leaving room for latest versions of the used libraries and modules and providing some polishing in the existing feature set.

With Tangram 1.0 we had to stick to older Servlet/JSP API versions especially to support the Google App Engine. Since Google doesn't seem to put much effort into this PaaS, this release removes the Google App Engine support and made it thus possible to do the following updates:

• Servlet 3.1 API now included
• JSP 2.1 now included
• Google Guice updated to 4.1
• DataNucleus updated to 4.1
• dinistiq updated to 0.5

The 1.1 track is supposed to stay Java 7 compatible.

Updating applications should be in most cases as simple as changing the dependency versions of Tangram and modifying the package reference org.tangram.view.Link to org.tangram.link.Link in your code (don't forget the Groovy codes in the repository).

Version 1.1.3 updates many dependencies which got outdated during the 1.1 life cycle.

Gretty Plugin

Since not only the Google App Engine has a defect with old releases of Java Web APIs but also Gradle has a obsolete Jetty plugin with an old version of Jetty, all examples have been migrated to Gretty. While doing this they now have decent product packaging means with

gradle archiveProduct

which generates a ZIP file.

To support this, all examples have been migrated to logback as the slf4j provider and illustrate how to unify logging from the container and the application.

Morphia Support

Latest Tangram applications always used Mongo DB as the storage backend with either JPA or JDO as the API. If you don't need the API abstraction or want an even leaner storage integration (before that DataNucleus JDO and EBean had the smallest footprint) you now can start using the "Mongo DB only Mapping" Morphia.

Markdown Support

Up to now every property using char[] for getters and setters was handled as structured text. It was edited as an HTML fragment (p or div) using the CKEditor.

Starting with this release, every property using org.tangram.content.Markdown for the getters and setters is handled through the CodeMirror editor as Markdown syntax. It is transformed to HTML in rendering.

Internally you are free to store both types of structured text in Strings or char[] or blobs, whatever fits best for the ORM in use.

Also templates can now be in Markdown syntax whenever appropriate. Also here the output is transformed to HTML before passing the templates to the
other layers of Tangram. When you want to use Markdown the mime type of the template has to be set to text/x-markdow.

Taking Care of the Modification Date and Time

If you need to track the modification time of an object through the Tangram editor module, you simply have to implement the org.tangram.mutable.HasModificationTime interface and store a long value together with the needed getters and setters.

All code implementations of Tangram implement this interface, so you will be able to check when you last modified the codes stored in the Tangram repository like you can do this on you local disk storage with file containing code.

Also the ftp module has been extended to make use of the modification time field.

File Restart Cache

The file restart cache provides a cache which stays available between restarts of the application to be able to be fast with responses starting from the first request to a newly started instance of an application. The downside was, that this cache didn't recognize, when the application itself changed during development. This was changed with this release, but you have to provide a little hint: Provide the file restart cache with the resource name of a resource which is changed together with the relevant classes of your application - s.g. the base package of your model classes like "org/tangram/example" for the Tangram examples.

Exporting and Importing

The export and import features of Tangram are now strictly symmetrical:

There is a generic XML exporter which exports the whole repository as XML. The XML importer should more or less independent of the storage flavour of Tangram in use be able to import this kind of XML.

The old code exporter, exporting the codes from the repository in a ZIP file with a folder structure resembling the mime types of the code elements, is now accompanied by a ZIP file importer which reads exactly this form of ZIP files and creates or updates code resources.

Fat JARs

Additionally it is now possible to leave out the "war" dependencies since resources like templates can be placed in the respective JARs.

Extended testing

Tangram now for the first time has a decent test coverage. While there still is room for more in depth testing of many functions, we now can put more trust into the single snapshot builds. This was quite important since most Tangram applications not residing on the Google App Engine already migrated to the 1.1 level.

Update Process

If your application has a code dependency in the DefaultServlet or DefaultController you will need to update this. Those two have been refactored into one class, the DefaultHandler. There are no examples for spring specific controllers or Servlet for Google Guice or dinistiq in the
platform itself any more. Of course it is still possible to use those facilities in you own applications.

All Java and Groovy codes need to update the import of org.tangram.view.Link to read org.tangram.link.Link.

Consolidation Release

The 1.1 release is a consolidation release removing outdated stuff leaving room for latest versions of the used libraries and modules and providing some polishing in the existing feature set.

With Tangram 1.0 we had to stick to older Servlet/JSP API versions especially to support the Google App Engine. Since Google doesn't seem to put much effort into this PaaS, this release removes the Google App Engine support and made it thus possible to do the following updates:

• Servlet 3.1 API now included
• JSP 2.1 now included
• DataNucleus updated to 4.1
• dinistiq updated to 0.5

Updating applications should be in most cases as simple as changing the dependency versions of Tangram and modifying the package reference org.tangram.view.Link to org.tangram.link.Link in your code (don't forget the Groovy codes in the repository).
Version 1.1.2 supports Java 7 binary format again. The 1.1 track is supposed to stay Java 7 compatible.

Gretty Plugin

Since not only the Google App Engine has a defect with old releases of Java Web APIs but also Gradle has a obsolete Jetty plugin with an old version of Jetty, all examples have been migrated to Gretty. While doing this they now have decent product packaging means with

gradle archiveProduct

which generates a ZIP file.

To support this, all examples have been migrated to logback as the slf4j provider and illustrate how to unify logging from the container and the application.

Morphia Support

Latest Tangram applications always used Mongo DB as the storage backend with either JPA or JDO as the API. If you don't need the API abstraction or want an even leaner storage integration (before that DataNucleus JDO and EBean had the smallest footprint) you now can start using the "Mongo DB only Mapping" Morphia.

Markdown Support

Up to now every property using char[] for getters and setters was handled as structured text. It was edited as an HTML fragment (p or div) using the CKEditor.

Starting with this release, every property using org.tangram.content.Markdown for the getters and setters is handled through the CodeMirror editor as Markdown syntax. It is transformed to HTML in rendering.

Internally you are free to store both types of structured text in Strings or char[] or blobs, whatever fits best for the ORM in use.

Also templates can now be in Markdown syntax whenever appropriate. Also here the output is transformed to HTML before passing the templates to the
other layers of Tangram. When you want to use Markdown the mime type of the template has to be set to text/x-markdow.

Taking Care of the Modification Date and Time

If you need to track the modification time of an object through the Tangram editor module, you simply have to implement the org.tangram.mutable.HasModificationTime interface and store a long value together with the needed getters and setters.

All code implementations of Tangram implement this interface, so you will be able to check when you last modified the codes stored in the Tangram repository like you can do this on you local disk storage with file containing code.

Also the ftp module has been extended to make use of the modification time field.

File Restart Cache

The file restart cache provides a cache which stays available between restarts of the application to be able to be fast with responses starting from the first request to a newly started instance of an application. The downside was, that this cache didn't recognize, when the application itself changed during development. This was changed with this release, but you have to provide a little hint: Provide the file restart cache with the resource name of a resource which is changed together with the relevant classes of your application - s.g. the base package of your model classes like "org/tangram/example" for the Tangram examples.

Exporting and Importing

The export and import features of Tangram are now strictly symmetrical:

There is a generic XML exporter which exports the whole repository as XML. The XML importer should more or less independent of the storage flavour of Tangram in use be able to import this kind of XML.

The old code exporter, exporting the codes from the repository in a ZIP file with a folder structure resembling the mime types of the code elements, is now accompanied by a ZIP file importer which reads exactly this form of ZIP files and creates or updates code resources.

Fat JARs

Additionally it is now possible to leave out the "war" dependencies since resources like templates can be placed in the respective JARs.

Extended testing

Tangram now for the first time has a decent test coverage. While there still is room for more in depth testing of many functions, we now can put more trust into the single snapshot builds. This was quite important since most Tangram applications not residing on the Google App Engine already migrated to the 1.1 level.

Update Process

If your application has a code dependency in the DefaultServlet or DefaultController you will need to update this. Those two have been refactored into one class, the DefaultHandler. There are no examples for spring specific controllers or Servlet for Google Guice or dinistiq in the
platform itself any more. Of course it is still possible to use those facilities in you own applications.

All Java and Groovy codes need to update the import of org.tangram.view.Link to read org.tangram.link.Link.

Consolidation Release

The 1.1 release is a consolidation release removing outdated stuff leaving room for latest versions of the used libraries and modules and providing some polishing in the existing feature set.

With Tangram 1.0 we had to stick to older Servlet/JSP API versions especially to support the Google App Engine. Since Google doesn't seem to put much effort into this PaaS, this release removes the Google App Engine support and made it thus possible to do the following updates:

• Servlet 3.1 API now included
• JSP 2.1 now included
• DataNucleus updated to 4.1
• dinistiq updated to 0.5

Updating applications should be in most cases as simple as changing the dependency versions of Tangram and modifying the package reference org.tangram.view.Link to org.tangram.link.Link in your code (don't forget the Groovy codes in the repository).

Gretty Plugin

Since not only the Google App Engine has a defect with old releases of Java Web APIs but also Gradle has a obsolete Jetty plugin with an old version of Jetty, all examples have been migrated to Gretty. While doing this they now have decent product packaging means with

gradle archiveProduct

which generates a ZIP file.

To support this, all examples have been migrated to logback as the slf4j provider and illustrate how to unify logging from the container and the application.

Morphia Support

Latest Tangram applications always used Mongo DB as the storage backend with either JPA or JDO as the API. If you don't need the API abstraction or want an even leaner storage integration (before that DataNucleus JDO and EBean had the smallest footprint) you now can start using the "Mongo DB only Mapping" Morphia.

Markdown Support

Up to now every property using char[] for getters and setters was handled as structured text. It was edited as an HTML fragment (p or div) using the CKEditor.

Starting with this release, every property using org.tangram.content.Markdown for the getters and setters is handled through the CodeMirror editor as Markdown syntax. It is transformed to HTML in rendering.

Internally you are free to store both types of structured text in Strings or char[] or blobs, whatever fits best for the ORM in use.

Also templates can now be in Markdown syntax whenever appropriate. Also here the output is transformed to HTML before passing the templates to the
other layers of Tangram. When you want to use Markdown the mime type of the template has to be set to text/x-markdow.

Taking Care of the Modification Date and Time

If you need to track the modification time of an object through the Tangram editor module, you simply have to implement the org.tangram.mutable.HasModificationTime interface and store a long value together with the needed getters and setters.

All code implementations of Tangram implement this interface, so you will be able to check when you last modified the codes stored in the Tangram repository like you can do this on you local disk storage with file containing code.

Also the ftp module has been extended to make use of the modification time field.

File Restart Cache

The file restart cache provides a cache which stays available between restarts of the application to be able to be fast with responses starting from the first request to a newly started instance of an application. The downside was, that this cache didn't recognize, when the application itself changed during development. This was changed with this release, but you have to provide a little hint: Provide the file restart cache with the resource name of a resource which is changed together with the relevant classes of your application - s.g. the base package of your model classes like "org/tangram/example" for the Tangram examples.

Exporting and Importing

The export and import features of Tangram are now strictly symmetrical:

There is a generic XML exporter which exports the whole repository as XML. The XML importer should more or less independent of the storage flavour of Tangram in use be able to import this kind of XML.

The old code exporter, exporting the codes from the repository in a ZIP file with a folder structure resembling the mime types of the code elements, is now accompanied by a ZIP file importer which reads exactly this form of ZIP files and creates or updates code resources.

Fat JARs

Additionally it is now possible to leave out the "war" dependencies since resources like templates can be placed in the respective JARs.

Extended testing

Tangram now for the first time has a decent test coverage. While there still is room for more in depth testing of many functions, we now can put more trust into the single snapshot builds. This was quite important since most Tangram applications not residing on the Google App Engine already migrated to the 1.1 level.

Update Process

If your application has a code dependency in the DefaultServlet or DefaultController you will need to update this. Those two have been refactored into one class, the DefaultHandler. There are no examples for spring specific controllers or Servlet for Google Guice or dinistiq in the
platform itself any more. Of course it is still possible to use those facilities in you own applications.

All Java and Groovy codes need to update the import of org.tangram.view.Link to read org.tangram.link.Link.

Completion Release

Since Tangram reached more than the originally intended features it should now be a 1.0 release. The name Tangram points out that the main objective was to create applications from a fixed set of modules and options which can form nearly any shape you would need. You can start quickly with a limited set of functionality and let the application grow. For many extensions you will not even need a deployment but a change in the data repository forming small and stable cores where the application as whole can be modified to changing requirements quicky, easily and securely.

We provide object oriented templating for objects from JPA, JDO, EBean, and CoreMedia repositories. The core system emphasises dynamic web programming through CSS, JavaScript, Velocity Templates, and Groovy Codes in the repository together with basic CDN support, code minification, and caching support.

The implementation of authentication and authorization now uses the pac4j set of libraries to provide a seamless and easy integration of plain user lists in files or the repository, OAuth providers, OpenID providers, Google App Engine user service and others for the web application and the base system itself.

Except for CoreMedia we provide a generic web editor which is now responsive (there is now separate mobile editor anymore) which can be loaded from the respective cloud locations of the used components (CKEditor, CodeMirror). Also it can be extended with our dynamc web programming facilities.

Appart from the about 40 minor improvements and clean ups following the 0.9 path, this release adds Google Guice support through a module called guicy. It uses Google Guice and Groovy code to reach the same level of dependency injection for the configuration of the applications as provided through the spring module for the springframework and the dinistiq module for the dinistiq minimal DI library.

One real limitation is the older set of JSP/Servlet APIs which need to stay in place to support the Google App Engine. So this is the final release to support the App Engine to be able to move ahead to newer APIs for several areas. This will not be achieved in the 1.0 branch.

The 1.0.1 Patchlevel fixes a few glitches mostly related with the packaging of the artifacts which made some dependent projects fail during build

Completion Release

Since Tangram reached more than the originally intended features it should now be a 1.0 release. The name Tangram points out that the main objective was to create applications from a fixed set of modules and options which can form nearly any shape you would need. You can start quickly with a limited set of functionality and let the application grow. For many extensions you will not even need a deployment but a change in the data repository forming small and stable cores where the application as whole can be modified to changing requirements quicky, easily and securely.

We provide object oriented templating for objects from JPA, JDO, EBean, and CoreMedia repositories. The core system emphasises dynamic web programming through CSS, JavaScript, Velocity Templates, and Groovy Codes in the repository together with basic CDN support, code minification, and caching support.

The implementation of authentication and authorization now uses the pac4j set of libraries to provide a seamless and easy integration of plain user lists in files or the repository, OAuth providers, OpenID providers, Google App Engine user service and others for the web application and the base system itself.

Except for CoreMedia we provide a generic web editor which is now responsive (there is now separate mobile editor anymore) which can be loaded from the respective cloud locations of the used components (CKEditor, CodeMirror). Also it can be extended with our dynamc web programming facilities.

Appart from the about 40 minor improvements and clean ups following the 0.9 path, this release adds Google Guice support through a module called guicy. It uses Google Guice and Groovy code to reach the same level of dependency injection for the configuration of the applications as provided through the spring module for the springframework and the dinistiq module for the dinistiq minimal DI library.

One real limitation is the older set of JSP/Servlet APIs which need to stay in place to support the Google App Engine. So this is the final release to support the App Engine to be able to move ahead to newer APIs for several areas. This will not be achieved in the 1.0 branch.

Modularisation and dynamicalisation

The module layout of version 0.8 turned out to be not optimal to extend tangram to more storage, dependency injection and web integration options. Version 0.9 changed that and was thus able to add more support for dynamic development options meaning it is possible to do more things with Groovy code in the repository - in some flavour even to extend the data model at runtime if necessary.