Notes

Development Notes and Ideas

Here we collect ideas, notes, and evaluation result from the tangram development.

Tangram 2.0 Notes

Freemarker

The idea to have several languages as templating options was not easy to implement and could be replaced by a migration from velocity to freemarker.

We already have a ticket for that and wait until further need forces us to migrate.

We have other issues which are mor pressing right now until we have projects in production with freemarker in use like we now have to velocity.

Links as Objects

Links e.g. in http hrefs are a special case for Tangram 1.x. They have to be rendered with a special tag instead of being just objects where we can use the normal rendering pipeline.

So it might be a good idea to avoid this special tag and instead use include for link objects.

Change calling pipeline

The generic checks on incoming calls are done via interceptors, filters, and controller hooks. This spread out design should be re-integrated.

This can be achieved if the rendering is split up:

• Call via URL -> parse URL to Target.
• Check Target -> Resulting Action / View / Redirect
• Call View / Action / Redirect

So URLs don't call the views and even some actions directly, but there is always a step in between before we move over.

Editor Clean up

The editor has to be cleaned up to separate actions from views. List and edit are views, the rest are actions. Additionally the rights then can be checked via an Editor Hook.

Dynamic Extension of the Model at Runtime

For some Backends we introduced the possibility to define classes at runtime through Groovy Source Codes which get inserted into the static, Java provided model.

This was first introduced through the DataNucleus enhancer plugged in as a component which scans for relevant classes in the groovy class repository.

Since morphia doesn't need any enhancing and provides the option to add classes to the collection of model classes at runtime, it it also possible to add models at runtime for this backend.

Despite the fact that the DataNucleus enhancer was reasonable easy to handle for the JDO API, we were not able to find a way to include this feature for the JPA case.

The groovy classes are supported through a special classloader at there doesn't seem to be a way to use this for OpenJPA. Also the enhancer onyl issues a new class definition and we can't the code bytes to it to redefined it in the runtime environment for later use as a model class.

While we seem to be able to use the custom classe loader for the groovy based model classes with EclipseLink, we didn't find a way to handle the list of model classes at runtime to extend it.

We did no investigations so far, if it is possible to add dynamic extension of the model for hibernate.

Tangram PHP Port / Version

Tangram/PHP is intended to

• be a lean port of Tangram/J to the PHP "language"
• usea decent and lean framework for DI
• present an OO-Templating layer with PHP in any reasonable avaible templating engine for PHP
• be easy deployable to cheap hosting environments
• support the CoMA extension of Tangram/J to connect PHP-layers to the exising CodeMedia CMS like with CoConAT

Tangram PlInG module

Tangram PlInG is intended as the "PLugin IN Glue" module to let you keep your existing coremedia based code base while changing the underlying implementation alltogether.

To accomplish this should be based on the CoMA Adaptor layer and map it to the original APIs you were using. This way you may use the same code base in both incarnations of the project, resulting in the opportunity to scale your system, have as many instances as you might like without any additional license cost for your original system.

Things you can directly re-use from your source code should include

• content bean implementations
• templates

Things you probably will have to re-invent might include

• Controllers
• Handlers

Left out areas of the API might include

• Searching
• Queries