Tangram Release 1.1

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.

Beyond the App Engine

The sources and release notes can be found on github.com, the binaries again reside on JCenter. This release includes some notable overdue dependency updates like

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

To allow this, it leaves out the Google App Engine support.

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 which is now the preferred container integration and even application packaging option.

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.
Also templates can now be in Markdown syntax whenever appropriate while also here the output is transformed to HTML before passing the templates to the other layers of Tangram.

Taking Care of the Modification Date and Time

If you need to track the modification time of an object through the Tangram editor module or the ftp service, you can now do so and the standard storage backed classes of Tangram now do so.

File Restart Cache

The restart caches used for faster restarting of the application with data which should not be changing between sessions of the application now only have to be cleared manually on error conditions but not on changes of the application any more.

Exporting and Importing

The export and import features of Tangram are now strictly symmetrical: Full content export and import  - more or less independent of the storage flavour in use - and a code exporter and importer for the sources stored in the repository.

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.

Tangram Release 1.0

Since Tangram reached more than the set of features originally intended back in 2009, it was time to call the current state a 1.0 release.

Why?

The name Tangram points out that the main objective was to create web 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. Fixed set in this case only means that you will need e.g. a model implementation but still have a choice, which one you would want to use. Also the glueing together with a Dependency Injections solution provides several options.
Another intention was to provide reasonable defaults for nearly every aspect where this is possible. You don't need to copy tons of files which do things technically necessary, which you didn't think of at that time. You only set up the things you know that you need them, and all the other features stay quiet. At least they should do something reasonable without getting in your way.

Users

Tangram is in production use since 2011 by Provocon, Ponton, Naturinspiriert.org and others.

Dynamic Extendibility

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 quickly, easily and securely.
Apart from the obvious presentation stuff this includes Groovy codes to create and parse URL, extend the business logic, and even the model layer with new model classes.

Core Features

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.

URLs can be formatted in nice, SEO friendly schemes and be easily mapped to actions to provide the result views for users.
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.
This authentication solution is used grant access to the system itself but also to provide support for protected content areas in your applications. You only have to focus on the question, which content needs to be protected by a access granting scheme. Logins can be a generic login page or integrated in you application design.

Generic Editor

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 dynamic web programming facilities.

Glueing Stuff Together

The mentioned default set of configurations and the option to customize this to your needs is achieved by Dependency Injection libraries. Tangram supports the usage of the Spring Framework, Google Guice, and dinistiq. It should be possible to add other solutions as well provided that they offer a decent set of functionality (which is not always the case for smaller DI libs.) including e.g. optional values, overriding of configurations, and deep generics introspection.

Readware

To illustrate the usage and provide a nice starting point, a set of example applications is provided in sync with the releases.
A documentation wiki is now starting.

Where the 1.0 Release Ends

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.

Ein weiterer Tangram Nutzer

Die Ponton GmbH aus Hamburg hat nun seit einiger Zeit auch eine Webanwendung mit Tangram im produktiven Betrieb. Dabei habe ich sie natürlich selbst in diese Richtung geschubst, um schnell Ergebnisse vorweisen zu können, aber weder war ich der einzige Entwickler noch hab es ausreichende Gegenwehr.
Auf dieser Basis wird anscheinend das Projekt auch mit neuen Anforderungen weiterentwickelt.
Als eher konservatives Layout wird hier noch das Springframework genutzt und auf JPA als Persistenzschicht gesetzt. URL-Formate als Groovy-Codes in der Datenbank und dort auch jede Menge Busineslogik waren aber gerade der Gewinner bei der laufenden Anpassung von Kleinigkeiten. Nun ist nicht mehr jedesmal ein Deployment erforderlich wie bei der Vorgängerlösung (in PHP).
Aber insbesondere danke, daß ich das laut sagen darf.

CoreMedia CMS und Gradle - just for the LOLs

Um das tangram-coma Modul wieder mehr in meinen Fokus zu bringen, brauche ich zum Testen immer einen CoreMedia CMS Content Server als backend.

Bisher war dieser Server entsprechend einer Anleitung und mit der Lieferung des Produktes als ZIP-Datei von Hand herzustellen. Das paßt natürlich nicht so richtig in die Tangram Beispiele, die in sich abgeschlossen sein sollten, und die bisher genutzte Version CMS 2008 (5.2) läuft nun unwidderruflich auch aus.

Mit den aktuellen Versionen wird das Produkt handlich in Form von Artefakten in einem Maven-Repository geliefert und es stehen Maven-Module zur Verfügung, daraus komplette Server zu erstellen, zu customizen und zu bestücken.

Leider ist dieser Bereich eben noch mit Maven formuliert und außerdem müßte ich mich dann - und dafür ist es ein wenig früh - vom Minimalbeispiel MenuSite verabschieden.

Also habe ich mich gefragt, ob ich fit genug bin, die Baupläne von CoreMedia mal im ganz kleinen nach gradle zu übersetzen und mir so den Content Management Server mit Build-Script in die Tangram Beispiele zu integrieren. Dabei habe ich natürlich wieder einen Dienst menr aus der Cloud als Entwicklungsunterstützung hinzugezogen, wie es zum Entwicklungsmodell von Tangram am besten paßt: Gut funktionierende Dienste und Komponenten nutzen. Da ich mit CoreMedia in der aktuellen Version hsqldb nicht mehr nutzen kann und nicht mehr wie im bisherigen Beispiel postgresql lokal installieren und nutzen wollte, habe ich mir mal schnell eine Testdatenbank bei DB4Free besorgt, da das "default" Datenbanksystem im CoreMedia CMS derzeit MySQL ist.

Um's kurz zu machen: Das Zusammenstellen eines Content Management Servers geht ganz wunderbar einfach und auch die Maven-Vorlagen sind - für Maven's Verhältnisse - relativ kompakt (d.h. unlesbar, häßlich, langatmig aber nicht lang). Den Prototyp für einen komplett Maven-freien und nicht Tangram-bezogenen Content Management Server gibt's ab heute unter

https://github.com/mgoellnitz/cm-cms-webapp

Und mit diesem Werkzeug gehe ich nun bei Tangram in die nächste Runde. Außerdem sieht man, daß man langsam den Weg weg von Maven (unter Beibehaltung der großartigen Dependency und Repository-Bereitstellung) beschreiten kann hin zu Gradle. Das ist kein harter Schnitt, das ist ein Weg, sodaß ich nun auch im CoreMedia Kontext keinen Neubau mit Maven-Syntax beginnen werde. Gradle verspricht, uns dabei zu unterstützen, da sie die installierte Maven-Basis im Blick haben.

On the Fly: URL Formate dynamisch anpassen

Nachdem nun einmal Groovy Codes jederzeit als Klassendefinitionen in das Tangram System eingefügt werden können, bietet es sich an
Mit Groovy kann man in Tangram neben den Ergänzungen der "Bean Schicht" - des Models - durch Shims sehr einfach URL-Formate schreiben und dynamisch jederzeit anpassen.
Dazu wird wieder Code mit MimeType "application/x-grooy" geschrieben. Die Annotation ist diesmal aber "org.tangram.view.link.LinkScheme" oder gleich der Klassenname der zu erstellenden Klasse.
Diese Klasse muß das Interface org.tangram.view.link.LinkScheme implementieren, d.h. Instanzen müssen sowohl URLs interpretieren können als auch aus Objekten URLs generieren können.
Das Tangram-System bietet dabei neben den URLs zur reinen Ansicht der Inhalte sogenannte Action-URLs, mit denen Aktionen - also Controller-Elemente - angesprochen werden sollten. Am Ende so einer Aktion sollte ein Redirekt auf eine reinen Ansichts-URL erfolgen. (Sonst würde bei "Reload" durch den Benutzer die Aktion erneut ausgeführt)

package org.tangram.solution.web.links;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import org.tangram.Constants;
import org.tangram.content.Content;
import org.tangram.content.BeanFactory;
import org.tangram.controller.DefaultController;
import org.tangram.view.Utils;
import org.tangram.view.TargetDescriptor;
import org.tangram.view.link.Link;
import org.tangram.view.link.LinkScheme;

import org.tangram.solution.web.RootTopic;
import org.tangram.solution.web.Topic;
import org.tangram.solution.web.ImageData;

public class DefaultLinkScheme implements LinkScheme {
 
  private static Log log = LogFactory.getLog(DefaultLinkScheme.class);

  private BeanFactory beanFactory;
 
 
  public void setBeanFactory(BeanFactory factory) {
    beanFactory = factory;
  } // setBeanFactory()
 
 
  public void setDefaultController(DefaultController defaultController) {
    // Automagically set default view
    defaultController.getCustomLinkViews().add(Constants.DEFAULT_VIEW);
  } // setDefaultController ()
 
 
  public Link createLink(HttpServletRequest request, 
                         HttpServletResponse response, Object bean, 
                         String action, String view) {   
      Link result = null;
      if ((action==null)&&(view==null)) {
          if (bean instanceof RootTopic) {
              result = new Link();
              result.setUrl("/");
          } else {
              if ((bean instanceof Topic)||(bean instanceof ImageData)) {
                  String title = "-";
                  String keywords = "-";
                  if (bean instanceof Topic) {
                      try {
                          title = Utils.urlize(((Topic)bean).getTitle());
                          keywords = Utils.urlize(((Topic)bean).getKeywords());
                      } catch (UnsupportedEncodingException uee) {
                          log.error("createLink()", uee);
                      } // try
                  } // if
                  String url = "/"+keywords+"/"+title+
                                    "/"+((Content)bean).getId();
                  result = new Link();
                  result.setUrl(url);
              } // if
          } // if
      } // if
      return result;   
  } // createLink()

 
  private TargetDescriptor rootDescriptor = null;;
 
 
  public TargetDescriptor parseLink(String url, HttpServletResponse response) {
    TargetDescriptor result = null;
    if (url.equals("/")) {
        try {
            if (rootDescriptor==null) {
                List<RootTopic> rs = 
                   beanFactory.listBeans(RootTopic.class, null);
                RootTopic root = null;
                if (rs.size()==1) {
                    root = rs.get(0);
                } else {
                    response.sendError(HttpServletResponse.SC_NOT_FOUND, 
                                "Have "+rs.size()+" RootTopics in data store");
              } // if
                rootDescriptor = new TargetDescriptor(root, null, null);
            } // if
            result = rootDescriptor;
        } catch (Exception e) {
            result = new TargetDescriptor(e, null, null);
        } // try/catch
      } else {
          String id = null;
          Object bean  = null;
          String[] elements = url.split("/");
          for (String element : elements) {
            if (element.indexOf(":") > 0) {
              id = element;
              bean = beanFactory.getBean(element);
            } // if
          } // for
          if (bean != null) {
              result = new TargetDescriptor(bean, null, null);
          } else {
              throw new RuntimeException("no content with id "+id+
                                         " in repository.");
          } // if
      } // if
      return result;
  } // parseLink()
   
} // DefaultLinkScheme

Das Beispiel hier zeigt zum einen das Erzeugen von URLs mit createLink() und das Verarbeiten mit parseLink(). Es ist im Grunde schon gar nicht so simpel sondern erfüllt eine ganze Reihe von Anforderunen:

• Es sind sprechende URLs umgesetzt, die den Title der Objekte benutzen
• Die Startseite wird mit / aufgerufen
• Aktionen laufen auf den DefaultController aus dem System

Nie wieder keinen Shim-mer!

Tangram wie viele Systeme besteht aus zwei Elementen: dem Code, der sowohl das Model als auch das Verhalten (den Controller) beschreibt und der View Schicht mit ihren Templates. Ich nenne das im Moment zwei Element, weil sie mit unterschiedlichen Techniken bedient werden: Code ist bei uns typischerweise in Java geschrieben und die Templates in JSP.
Schnell ist man dabei, Ergänzungen zu den Templates wie CSS und JavaScript im Repository anzulegen, damit man sie schnell und einfach ohne Deployment ändern kann. In Tangram Websites war das nicht dadurch gegeben, daß Deployments ein großer Aufwand sind, sie ware auch für die kleinen Sites und das einfache Deployment mit der Google App Engine, schlicht gelegentlich in dem Moment wo es notwendig war technisch nicht durchführbar.
Wenn man dann die Elemente CSS und JavaScript im Repository hat, will man schnell das Template auch dort haben. Das ist im Tangram mit Apache Velocity umgesetzt und ist schnell zur bevorzugten Technik geworden, sodaß JSP-Templates nur noch für die mitgelieferten Teile wie den Editor eine Rolle spielen, nicht aber für die Webanwendungen selbst.
Beim Schreiben der Templates stößt man dann aber unweigerlich immer wieder an die Limitierung der Implementierungsteile in Java, da diese ja fest im Deployment verankert sind.
Also wurde im Tangram Groovy integriert, daß als dynamische Sprache in die Java Welt integriert ist und somit sehr gut in das Szenario paßt.
Mit Groovy kann man in Tangram sehr einfach Funktionen auf Basis des Models zu den Java-Klassen hinzufügen. Da diese Codes im Repository als kleine Erweiterungen gedacht sind, heißen sie Shims. Diese kleinen Shims können zu jeder Klasse definiert werden, indem man einen Code mit dem MimeType "application/x-grooy" erstellt und als Annotation den Namen der Java-Klasse wählt, zu der dieser Code hinzugefügt werden soll.
Der Code selbst implementiert das Interface Shim oder ViewShim, wobei der Unterschied nur ist, daß ein ViewShim auch mit den Informationen des aktuellen Request versorgt wird und damit in den Bereich fällt, in dem Tangram nicht mehr cachen kann.

package org.tangram.solution.web.shims;

import javax.servlet.http.HttpServletRequest;

import org.tangram.logic.AbstractShim;
import org.tangram.gae.solution.Topic;

public class TopicShim extends AbstractShim<Topic> {

    public TopicShim(Topic topic) {
        super(topic);
    } // TopicShim()
   
    public String getNonsense() {
      return "Hallo";
    } // getNonsense()
   
    public String getReverseTitle() {
      return new StringBuilder(delegate.title).reverse().toString();
    } // getReverseTitle()
   
} // TopicShim

Der Inhalt dieses Shims ist relativ sinnlos, zeigt aber das Wesentliche: Wir muß die Groovy-Klasse aufgebaut sein, und wie greift man über den Delegate auf die jeweilige Instanz der Java-Klasse zu.
Bleibt nur noch eine Frage zu klären: Wie kommt man dann an diesen Code heran? Zusammen mit den Instanzen der Java-Klassen wird in Tangram jeweils eine Instanz der View-Klasse angelegt und unter dem Klassen-Namen ohne Package-Angabe den Templates zur Verfügung gestellt.
Im Apache Velocity Template im Repository - JSP haben wir ja für die Anwendung selbst längst zu den Akten gelegt - sähe das dann so aus:

  <h1>$TopicShim.reverseTitle | $self.title</h1>

Noch mehr funky Groovy - und gradle blues

Rendering war ja nun schon lange nicht mehr mein Problem mit den bequemen Velocity Templates im Repository. Einiges Sites laufes ja schon damit (z.B. themen-geburtstag.de). Die URL-Formate lassen ebenfalls dort definieren, wenn man möchte, was sicherlich ein wenig schwieriger im Coding ist.
Neben dem eigentlichen Datenmodell fehlt nun noch die Action im ganzen, die ich auch gerne in's Repository verlegen würde - zumindest wieder einmal als Option, da das Verhalten doch etwas ist, was man ähnlich oft tunen will, wie das Layout.
Bisher habe ich das mit einem eigenen Satz Controller sauber lösen können, aber eben nicht so agil oder dynamisch wie die Styles und Templates.
Zumindest ist es nicht mehr meine Sicht auf moderne Web-Entwicklung, daß man einen Satz an Funktionalität fest eingebaut hat und nur noch Views darüber legt.
Und da sich am Horizont weitere Projekte abzeichen, die eher Communities als reine Websites werden sollen, bestand wieder einmal Handlungsbedarf.
Also habe ich nun den lange vorhandenen Action-Parameter bei der Link-Generierung einmal zu konsistenterem Leben erweckt (und nicht nur in der simplen Editing-Komponente verwendet) und mit zwei Annotations lassen sich nun in den LinkScheme Instanzen Methoden als Actionen markieren, die direkt über URLs angesprochen werden. Parameter-Übergabe und Resultatseiten Ansteuerung inklusive. Kommentare nach Lektüren der aktuellen Codes bitte gerne an mich.
Leider war eine Entscheidung nicht gerade förderlich (evtl. hatte ich sie deshalb beim letzte Lesen auf gradle.org auch nicht getroffen): Das update auf gradles 1.0 Milestone 7 bremst hier gerade extrem. Gut war es nur, als ich offline im Zug saß :-) Da war diese Version schneller. Ansonsten quält mich diese Version mit ewiglangen Suchaktionen nach den Dependencies. Zum glück kommt gerade Milestone 8 um die Ecke: Downloaden benutzen! Damit fühlt sich gradle wieder so gut an wie vorher :-)