Content Project - Project Service

[GlennRicaud]

Epic #7280 To be PullRequested in branch "epic-project"

• Create a class com.enonic.xp.project.Project (core-api) with the following fields:
  • name: ProjectName //Regexp: [a-z0-9\-][a-z0-9\-_]*
  • displayName: String
  • description: String
  • icon: Attachment
• Create an interface com.enonic.xp.project.ProjectService (core-api) with the following methods:
  • list
  • get
  • create
  • modify
  • delete
• Create its implementation com.enonic.xp.core.impl.project.ProjectServiceImpl (core-content)
  • "Create" will create and initialize a CMS repository
  • The name of the repository will be: "com.enonic.cms." + [Project Name]
  • For the creation and initialization, look at what is done by ContentInitializer
  • It should pass the displayName, description and icon as data when creating the repository
  • "Get" will return com.enonic.xp.project.ProjectService by unserializing the node "/project".
  • "Modify" will only modify the data of the repository entry (no renaming of repository)
  • Note: You cannot modify the name, only: displayName, description and icon.
  • "Delete" will delete the repository
  • Note: You cannot delete the default project
  • "List"
  • Will retrieve all the projects

[rymsha]

In addition it should also store the node representation of the project in master at the node path "/project"

In which repository?

[sigdestad]

Hmmm.. I thought we would only create a repo i.e. com.enonic.cms., and that was it? Apparently we will need more metadata. There will also be some level of access control as well.

There are two solution imho: A) create a com.enonic.cms repo and store the info there, or B) extend the node repo creation api with more support for fields and metadata

I think option B sounds best in relation to dumping and loding isolated repos, No need for special project api on that level.

We have a similar issue in regards to layers, there we will have to create a branch dedicated to metadata.

[GlennRicaud]

Hehe. Already discussed with @rymsha. Already on it: https://github.com/enonic/xp/issues/7362

[sigdestad]

Alternative C is to store this info in the root node of the repo, that could be a more practical and flexible solution.

[sigdestad]

This could then only be exposed in the repo, and project APIs