The process of creating components in Tridion has always been very different from creating pages. When you create a component you are guided by a schema, which provides strict guidelines. However, when you want to create a page, you start off with a tabula rasa – essentially a blank sheet of paper.
This changes with the introduction of regions and page schemas. Here’s how. Continue reading
The latest version of Tridion (SDL Tridion Sites 9) is now fully supported by DD4T for Microsoft.NET. Read here how easy it is to upgrade.
Whenever you publish a page, component or another type of item in Tridion, the item is first published, then transported and finally deployed. SDL offers various ways to extend or modify this deployment process. All you need to do is write some custom java code. The most commonly used extension points are deployer modules and storage DAOs. You can find more about this here and here.
In this post I’m not going to explain what these extensions are and what you can do with them. Instead, I will focus on how to develop this type of extension effectively. As always with Java (in my experience at least), the code is easy but the environment is hard. But if you follow these instructions, you will be able to run your customizations locally, make sure they get triggered, and even perform step-through debugging on your code. Pure bliss!
These days the standard way to get your java libraries is through Maven. However, sometimes you still need to deal with jar files that aren’t available through Maven at all. Perhaps some software vendor has provided a set of jars, or you have a custom build that you aren’t allowed to publish at all.
If this is the case, you could just reference the jars on the file system, the old school approach. But you can also mavenize them yourself, and store them in your local Maven repository (which can be found in your user profile folder, in the folder .m2). That makes it possible to reference these libraries in a pom.xml or in a build.gradle file, giving you all the advantages of modern dependency management.
On February 12th, SDL released DXA 2.0, the shiny new version of the Digital Experience Accelerator. Part of this new version is a new REST service called the model service, which is able to return content quicker, and in a leaner format. Not only that, the model service is also able to resolve links in the content on the fly. This is an important improvement, because link resolving is one of the most expensive operations in DXA as well as DD4T.
A full migration of your application from DD4T to DXA is far from trivial, at least not with the DXA 2.0 release that is currently out. But there is good news: it is very easy to start using the DXA model service in your DD4T .NET application (it is also possible with a Java DD4T application, but we’ll discuss that some other time). Your application is likely to become faster because of it.
There is one important condition: you have to use SDL Web 8.1 or higher, and DD4T 2.0 or higher, in order to upgrade to the model service.