How to create document in folder automatically?

Hi,

I have a usecase where I need exacty one document in a folder. The document should have the same name as the folder.
Therefore I would like to automate this. Thus the creation of the folder and the document should be in one action by the editor.

My first approach was to use an eventhandler but there are no usefull events when a folder is created. (only for adding permissions and setting displayname). It would be usefull for me if an event is triggered after a folder is newly created (and the displayname has been set). Is it possible to add such a event in my project?

The second approach was using querytemplates. But then it is not possible to set a nice displayname for the document. Also my custom eventhandlers are not triggered.

Does anybody have other suggestions for implementing this functionalty?

Thanks in advance,
Ivor

Hey Ivor,

with template queries you can also pass variables to deeper nested content, to make document have the same name as folder. This one should work:

./_node/_node/_name
$name
./_node/_name
$name
./_name
$name
./_node/hippo:name
$name

But name of the document is not pretty, document will be holding a technical node name… So question is still valid.

Ilja

Hey Ivor,

it may be a bit cumbersome, but we can do the following. Once document was created together with folder (by template query prototype), and given document has a specific document type., you can create derived function for that specific document type. It will go up to the folder, take its pretty name and put it in the document.
I think on the official page there is also an explanation how read properties of the parent in derived function. https://www.onehippo.org/library/concepts/content-repository/derived-data.html.

HTH,
Ilja

Hey Ivor :),

My first question would be: why do you actually need this? Since, to me (1) adding a folder in between the root-/parentpath and the document itself and (2) by convention only having one document in that folder, only adds an additional abstraction level. As a suggestion, you might also add/derive this abstraction level in another place than in the actual content repository (e.g. sitemapitemhandler, restful endpoint, etc.).

HTH,

Brian

In some places it makes sense to have a tree structure of documents. It is good for accesibily and SEO if the URL follows that tree structure. Also for the editor it makes sense to have the same tree structure. However , in the CMS, it is not possible to make a tree structure of documents. It is possible to have a tree structure of folders. That’s why, in these cases, I often work with a tree structure of folders and one document in each folder. The we can use standard sitemap logic to display the document in the folder, maybe with a little help from a sitemapitemhandler.

What I’ve done now is let the editor create a document and have an eventhandler move that document to a folder with the same name. This seems to work fine so far. With this, the editor has one action to create a document, the rest is done automatically.

@Ilja, the querytemplates are a good option too. I saw in code that there is a variable localName which has the displayname. It would be a good solution, however I think it’s less maintainable because the document is not created by it’s prototype.
Greets, Ivor

Hi Ivor,

Reading the code, I guess you could receive org.hippoecm.repository.standardworkflow.FolderWorkflowEvent, a subclass of org.hippoecm.repository.impl.HippoWorkflowEvent, on subfolder or document addition on the specific folder. The event is with action being add, handleUuid and subjectId (both should be the same in case of subfolder), category being new-folder for instance, arguments, …
This event is delivered after the action was performed.

Regards,

Woonsan

Refs:

  • org.hippoecm.repository.standardworkflow.FolderWorkflowImpl.add(String, String, Map<String, String>)
  • org.hippoecm.repository.impl.WorkflowManagerImpl.WorkflowInvocationHandler.invoke(Object, Method, Object)
  • org.hippoecm.repository.impl.WorkflowLogger.logWorkflowStep(String, String, String, Object, Object, String, String, String, String, String, String, Throwable)