Managing flat and static files using Tridion

Question

We are running SDL Tridion 2011 SP1. I am looking for ideas to move flat files(HTML, class, jsp, jars etc.) to Tridion CM for a consumer base(developers) with no experience in using the Tridion CME. Users will not be using the explorer for creating and editing purposes but will only publish these assets to a delivery server which will serve the content to the Internet. This is for a bunch of existing applications and newer applications will leverage community CD frameworks.

I am aware that there are easier solutions for this purpose out of SDL capabilities and the above is not even recommended with WCM, but we would like to gather some Tridion community advice before concluding. I like Tridion :).

I have tried to use WEBDAV, treating all of the above as binaries, but the allowed and reserved MIME type restriction does not allow me to upload files of all formats. Is there a way we can get around this? Is is possible to extend the Tridion WEBDAV module like DreamWeaver to allow files to be uploaded to the cm database. I am not sure if I might run into the problem described above despite a custom client.

Another option would be to build a custom application which will leverage a framework using the Tridion core service & event system which builds the page and its associated items. Load, performance and other capabilities will have be to debated. I am looking for thoughts and suggestions from the community before completing evaluation of Tridion as a solution.

Answer 1

I agree with all of the other "Don't Do Tt" answers. However, I have had clients which insisted on it.

The only solotion I have seen work well is to create a zipfile of the entire web application, and use a custom target and template code limited for use by Admins only.

This allows you to upload the complete tested application as a package, and then deploy it in one go, which limits the risks of uploading incompatible parts of the application.

I then use a custom TBB to unzip the package into a binary structure which gets deployed to the web application server. I have use such a TBB for deploying an exploaded WAR file and .NET applications.

I still don't like it, but if you must, this solution introduces fewer risks than a system that allows incremental updates.

Answer 2

I know this doesn't answer your question. But pure and simple: DON'T DO IT!!! Maybe you know all the reasons, but here are some good ones, just in case:

1) Content and Applications have different lifecycles

Content is continually created/refined/published - that is why we use a CMS. Applications are developed, tested and released at agreed and controlled moments. Having your application published from your CMS is so wrong - can you be sure that the publisher will publish all related artifacts at the same moment? What happens if the JSP is published before the .jar file? What happens if someone accidentally publishes (or worse un-publishes) something crucial? Application meltdown on your production system, that's what. 500 Server Error Heaven.

2) Tridion is designed to manage content and not applications

Thus the aforementioned issues with certain mime-types, although as mentioned, most binaries can be uploaded into the CMS. Just because you can, doesn't mean you should.

3) Developer Frustration

You need to train your developers to use the CMS. They will quickly become annoyed at what was once a simple xcopy or .war deployment becoming some manual update of multiple multimedia components and then moving to another publication to publish. This is before we even start talking about continuous integration - shoving everything through the CMS as a glorified FTP server will make this kind of thing even harder to accomplish.

Answer 3

Please see below my opinion:

If I am in a CMS Architect shoes, I would not recommend using a CMS as a deployment tool or as a repository for business logics.

Content Management System by definition is meant to manage the Content of a Website where Content could be anything visible on the page but definitely not the compiled classes, jars, dlls or business logic/algorithm.

Nice to hear that you like Tridion very much and I am also crazy about Tridion system as per my knowledge of various CMS System, Tridion is the only CMS which satisfy the basic principle of keeping your Content and its presentation apart; and if you use it as a deployment or repository tool, you are not only defying the Tridion's principle but also of a basic CMS principle as well.

Even though despite of this you want to do, then following could be the option and you may choose per your need:

1. Creating specific multimedia types and defining all these files as Multimedia component and then you may choose to publish them either as a standalone multimedia components or though a CT/PT and Page combination
2. As far as I know, using WebDav you will only be able to upload known multimedia types
3. Write a Thin Client and integrate it with Core Service code to automate the process defined in option 1 above (This may suits best to your need)

Answer 4

Though this question might likely fall under the "can write a book about it" category, I'll attempt an answer from a business analysis and functional perspective.

Like Pankaj, I second the separation between content, design, and code. Though I'm not particular on the specific format--sometimes you might want Tridion outputing something that looks like code, but is really managed functionality in Tridion (e.g. fields in Tridion that eventually publish an XML configuration file).

Author Actions

I'd only recommend putting flat files or any other external item into a Content Management System like Tridion if authors (possibly "dev" authors) need to do anything with them.

This would include:

• Publishing to one or more target (Target Types in Tridion)
• Editing or possibly adding additional information to these
• Referencing, linking, or otherwise configuring these (e.g. reference a "flat file" in page metadata)

Baked Requirement?

And even then, there are easier, more loosely coupled ways to integrate these files with a WCM. Rather than "baking" these into Tridion, consider adding them later during publish, in server-side code, or final rendering (script).

• In 2013, External Content Libraries let authors manage binaries in other systems, but use them as components in Tridion
• In previous Tridion versions, the same can be accomplished through identifiers in component or metadata fields
• Items don't need to be in Tridion to be published by Tridion. See TOM.NET, the "corporate team player." or integrating Tridion with other systems (specifically a PIM, but the approach is the same for any external data).

Technical Debt

I too (three?) love Tridion but consider the following technical debt with this approach.

• Code deployment would be coupled with WCM solution. You don't need to change existing processes, especially if you have a mix of applications and only some use Tridion.
• Versioning based on upload time (which may or may not be an issue for you)
• Source control--you'll likely want to keep a (your existing) solution outside of Tridion.

If you still feel Tridion solves the business problem, see this excellent series of articles from BuildingBlocks on managing code, images, and css.

Answer 5

You also can add a missing MIME type from the Tridion administration section, such as jar or class file type.