Skip to content

Consolidation Release
Compare
Choose a tag to compare
@mgoellnitz mgoellnitz released this 05 May 22:15
· 425 commits to master since this release
1.1.0
4aa945c

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.

Assets 2
Loading