Search code examples
javaliferayliferay-6

How to create default document types and metadata sets in Liferay 6?


I want to create my own default document types and metadata sets in Liferay 6.1.20 EE.

Currently, Liferay implementation creates its own default document types and metadata sets, e.g. Contract, Online Training, etc., which are created in the class AddDefaultDocumentLibraryStructuresAction, which is called from the class AddDefaultDataAction, which is a startup action.

As stated in a Liferay Forum post, in case we want to turn off this creation process, we need to comment out the relevant lines in AddDefaultDataAction or we can add a custom AddDefaultDataAction in the application.startup.events overriding the default one.

Can this be done using a hook to override application.startup.events? And if yes, how can we override AddDefaultDataAction class, as it is a portal-impl.jar class and we don't have access to it from a hook? If not, should an ext plugin be used for this purpose? Or is there a more straight-forward way to implement my own default document types and metadata sets?


Solution

  • If you look at the default configuration, found in portal.properties, there it says

    #
    # Application startup event that runs once for every web site instance of
    # the portal that initializes.
    #
    application.startup.events=com.liferay.portal.events.AddDefaultDataAction,\
         com.liferay.portal.events.AppStartupAction,\
         com.liferay.portal.events.ChannelHubAppStartupAction
    

    So you can remove the default com.liferay.portal.events.AddDefaultDataAction from this list by just stating the others in your portal-ext.properties:

    application.startup.events=com.liferay.portal.events.AppStartupAction,\
         com.liferay.portal.events.ChannelHubAppStartupAction
    

    If you want to do this for all new installations, you'll have to add this change before the first start of the instance. Or you should write an ext plugin that does this out-of-the-box. Why do you need an ext? A hook can only add another StartupAction, not change the existing ones. An ext can change or remove existing startup actions or override their code.

    In an ext plugin you could also implement

    application.startup.events=com.mariaioannidou.MyCustomAddDefaultDataAction,\
         com.liferay.portal.events.AppStartupAction,\
         com.liferay.portal.events.ChannelHubAppStartupAction
    

    and implement MyCustomAddDefaultDataAction as doing the same that the default action does, sans creating the document types.

    On the other hand, a hook could find all of the standard document types that you don't want, check that they are indeed unused, and then delete them. As you can see, AddDefaultDataAction does quite a bit more than just adding the document types, so you might want the rest of the code in the action to run.

    Another alternative is to write an ext plugin that actually changes the implementation of com.liferay.portal.events.AddDefaultDataAction, but there you are again with an ext - if you don't deploy this in every installation before your first startup, you'll end up with the default content anyway and you might want to have some code to delete it automatically.

    My personal recommendation would be with a hook, deleting the unneeded document types (if they're unused) - the reasons are:

    1. Ease of deployment (hot-deployment possible),
    2. if you don't deploy your plugin before the first run, you end up needing to delete the unwanted document types anyway,
    3. maintainability: It's easier to maintain a hook than an ext plugin.