Programmatically create documents from content within another document

[tony.h...@gmail.com]

Hi,

Im a newbie to Hippo and maybe I am going about this in entirely the wrong way so any advice is appreciated.

I have created a "parent" Document Type which contains an embedded List of Custom Compound Types corresponding to videos. (i.e. properties including title, introduction and url for each video). In addition, each of the videos may include taxonomy keys.

What I want to do when the parent  document is published, is copy the embedded Videos to a separate document in a dedicated "videos" folder to enable them to be separately searchable and independently retrieved. From a usability perspective, my client does not want to create the Video document separately in the CMS and "link" them to the parent.

The simplistic approach I have taken so far is to register an implementation of the DaemonModule and listen for publication events for the parent document, and then try and manually create a new Video document for each of the embedded videos. However this can't be the correct way to achieve this as I have no idea how to populate the various hippo-related properties, so I suspect I need to submit the raw document to some sort of workflow.

Can anyone provide some guidance or pointers please?

Thanks

Tony

[Jasper Floor]

I think I would look into creating a custom workflow [1]. Or you could look into creating some kind of document wizard, see [2] for inspiration. Your DaemonModule can also make use of workflows, though this will have to be a cms only daemon module most likely. In any case you want to be hooking into the workflows. 

You could also file an improvement issue to have a native compound type with which you can directly upload to the assets folder. This does introduce some issues however and I cannot guarantee such an improvement would be accepted. Even if it was it would not be available quickly. 

[1]https://www.onehippo.org/library/concepts/workflow/workflow.html

[2]https://www.onehippo.org/library/concepts/plugins/dashboard-document-wizard/about.html

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-community@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-community+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

[Minos Chatzidakis]

Hi Tony,

On Mon, Jun 12, 2017 at 10:18 AM, Jasper Floor <jasper...@bloomreach.com> wrote:

I think I would look into creating a custom workflow [1]. Or you could look into creating some kind of document wizard, see [2] for inspiration. Your DaemonModule can also make use of workflows, though this will have to be a cms only daemon module most likely. In any case you want to be hooking into the workflows. 

You could also file an improvement issue to have a native compound type with which you can directly upload to the assets folder. This does introduce some issues however and I cannot guarantee such an improvement would be accepted. Even if it was it would not be available quickly. 

[1]https://www.onehippo.org/library/concepts/workflow/workflow.html

[2]https://www.onehippo.org/library/concepts/plugins/dashboard-document-wizard/about.html

On Fri, Jun 9, 2017 at 3:04 AM, <tony.h...@gmail.com> wrote:

Hi,

Im a newbie to Hippo and maybe I am going about this in entirely the wrong way so any advice is appreciated.

I have created a "parent" Document Type which contains an embedded List of Custom Compound Types corresponding to videos. (i.e. properties including title, introduction and url for each video). In addition, each of the videos may include taxonomy keys.

So the "video" is quite a rich entity in your project, so I begin by saying that making a compound sounds wrong. Instead, it sounds right to make a document type for it and allow for the reusability of videos (in multiple documents), which you lose if you go with compounds.

 

What I want to do when the parent  document is published, is copy the embedded Videos to a separate document in a dedicated "videos" folder to enable them to be separately searchable and independently retrieved.

What do you mean "copy"? As you mentioned a video is essentially just a url. So what exactly do you wanna copy? The string url? Or download the video and store it in the CMS? (Not recommended). And what does "searchable video" mean? 

 

From a usability perspective, my client does not want to create the Video document separately in the CMS and "link" them to the parent.

Really? So what happens if I use the same video url in 2 separate "parent" documents? Will you copy it twice? 

 

The simplistic approach I have taken so far is to register an implementation of the DaemonModule and listen for publication events for the parent document, and then try and manually create a new Video document for each of the embedded videos. However this can't be the correct way to achieve this as I have no idea how to populate the various hippo-related properties, so I suspect I need to submit the raw document to some sort of workflow.

This is the way, and you can use the built-in FolderWorkflow to create new VideoDocuments and populate any properties you need afterwards, your code more or less will look like this:

WorkspaceDecorator workspaceDecorator = (WorkspaceDecorator) session.getWorkspace();

FolderWorkflow folderWorkflow = (FolderWorkflow) workspaceDecorator.getWorkflowManager().getWorkflow("threepane", session.getNode("/content/documents/myhippoproject/folderYouWantYourNewVideoDocumentIn"));

String docPath = folderWorkflow.add("new-video-document-template", "myhippoproject:videodocument", "nameOfYourNewDocument");

//... get the node of the new document and set your propeties

Note that a daemon module uses a different session, so the new video documents will be not be created by the user who initially made the "parent" document. You need to use SCXML for that.

In my opinion you're deviating a lot from the ootb workflow, sacrificing reusability on the way and ending with custom code that can make your upgrades and maintenance hard. If you're new to Hippo then I would suggest you don't go this route, but instead try to convince your client otherwise or ask for more official support from a Bloomreach consultant (contact sales).

Hth!

Minos

-- 

Can anyone provide some guidance or pointers please?

Thanks

Tony

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-community@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-community+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-community@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-community+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

--

Minos Chatzidakis

Product consultant

p. e.

+31 20 522 44 66  minos.chatzidakis@bloomreach.com

_________________________________________________________________________________

[Jasper Floor]

On Mon, Jun 12, 2017 at 11:37 AM, Minos Chatzidakis <minos.ch...@bloomreach.com> wrote:

Hi Tony,

On Mon, Jun 12, 2017 at 10:18 AM, Jasper Floor <jasper...@bloomreach.com> wrote:

I think I would look into creating a custom workflow [1]. Or you could look into creating some kind of document wizard, see [2] for inspiration. Your DaemonModule can also make use of workflows, though this will have to be a cms only daemon module most likely. In any case you want to be hooking into the workflows. 

You could also file an improvement issue to have a native compound type with which you can directly upload to the assets folder. This does introduce some issues however and I cannot guarantee such an improvement would be accepted. Even if it was it would not be available quickly. 

[1]https://www.onehippo.org/library/concepts/workflow/workflow.html

[2]https://www.onehippo.org/library/concepts/plugins/dashboard-document-wizard/about.html

On Fri, Jun 9, 2017 at 3:04 AM, <tony.h...@gmail.com> wrote:

Hi,

Im a newbie to Hippo and maybe I am going about this in entirely the wrong way so any advice is appreciated.

I have created a "parent" Document Type which contains an embedded List of Custom Compound Types corresponding to videos. (i.e. properties including title, introduction and url for each video). In addition, each of the videos may include taxonomy keys.

So the "video" is quite a rich entity in your project, so I begin by saying that making a compound sounds wrong. Instead, it sounds right to make a document type for it and allow for the reusability of videos (in multiple documents), which you lose if you go with compounds.

I agree with you 100%, but I think this is exactly the workflow he is looking to avoid. 

 

 

What I want to do when the parent  document is published, is copy the embedded Videos to a separate document in a dedicated "videos" folder to enable them to be separately searchable and independently retrieved.

What do you mean "copy"? As you mentioned a video is essentially just a url. So what exactly do you wanna copy? The string url? Or download the video and store it in the CMS? (Not recommended). And what does "searchable video" mean? 

 

From a usability perspective, my client does not want to create the Video document separately in the CMS and "link" them to the parent.

Really? So what happens if I use the same video url in 2 separate "parent" documents? Will you copy it twice? 

 

The simplistic approach I have taken so far is to register an implementation of the DaemonModule and listen for publication events for the parent document, and then try and manually create a new Video document for each of the embedded videos. However this can't be the correct way to achieve this as I have no idea how to populate the various hippo-related properties, so I suspect I need to submit the raw document to some sort of workflow.

This is the way, and you can use the built-in FolderWorkflow to create new VideoDocuments and populate any properties you need afterwards, your code more or less will look like this:

WorkspaceDecorator workspaceDecorator = (WorkspaceDecorator) session.getWorkspace();

FolderWorkflow folderWorkflow = (FolderWorkflow) workspaceDecorator.getWorkflowManager().getWorkflow("threepane", session.getNode("/content/documents/myhippoproject/folderYouWantYourNewVideoDocumentIn"));

String docPath = folderWorkflow.add("new-video-document-template", "myhippoproject:videodocument", "nameOfYourNewDocument");

//... get the node of the new document and set your propeties

Note that a daemon module uses a different session, so the new video documents will be not be created by the user who initially made the "parent" document. You need to use SCXML for that.

In my opinion you're deviating a lot from the ootb workflow, sacrificing reusability on the way and ending with custom code that can make your upgrades and maintenance hard. If you're new to Hippo then I would suggest you don't go this route, but instead try to convince your client otherwise or ask for more official support from a Bloomreach consultant (contact sales).

Most likely some form of document wizard would fit the usecase best. But listen to Minos, he knows things. 

mvg,

Jasper

[Minos Chatzidakis]

On Mon, Jun 12, 2017 at 11:45 AM, Jasper Floor <jasper...@bloomreach.com> wrote:

On Mon, Jun 12, 2017 at 11:37 AM, Minos Chatzidakis <minos.chatzidakis@bloomreach.com> wrote:

Hi Tony,

On Mon, Jun 12, 2017 at 10:18 AM, Jasper Floor <jasper...@bloomreach.com> wrote:

I think I would look into creating a custom workflow [1]. Or you could look into creating some kind of document wizard, see [2] for inspiration. Your DaemonModule can also make use of workflows, though this will have to be a cms only daemon module most likely. In any case you want to be hooking into the workflows. 

You could also file an improvement issue to have a native compound type with which you can directly upload to the assets folder. This does introduce some issues however and I cannot guarantee such an improvement would be accepted. Even if it was it would not be available quickly. 

[1]https://www.onehippo.org/library/concepts/workflow/workflow.html

[2]https://www.onehippo.org/library/concepts/plugins/dashboard-document-wizard/about.html

On Fri, Jun 9, 2017 at 3:04 AM, <tony.h...@gmail.com> wrote:

Hi,

Im a newbie to Hippo and maybe I am going about this in entirely the wrong way so any advice is appreciated.

I have created a "parent" Document Type which contains an embedded List of Custom Compound Types corresponding to videos. (i.e. properties including title, introduction and url for each video). In addition, each of the videos may include taxonomy keys.

So the "video" is quite a rich entity in your project, so I begin by saying that making a compound sounds wrong. Instead, it sounds right to make a document type for it and allow for the reusability of videos (in multiple documents), which you lose if you go with compounds.

I agree with you 100%, but I think this is exactly the workflow he is looking to avoid. 

He is looking to avoid this workflow because the client said "no". I would like to know why the client said no and whether they've thought about the limitations and impact this decision is causing. There's large impact on usability, upgradability, maintainability and support from Bloomreach.

 

 

 

What I want to do when the parent  document is published, is copy the embedded Videos to a separate document in a dedicated "videos" folder to enable them to be separately searchable and independently retrieved.

What do you mean "copy"? As you mentioned a video is essentially just a url. So what exactly do you wanna copy? The string url? Or download the video and store it in the CMS? (Not recommended). And what does "searchable video" mean? 

 

From a usability perspective, my client does not want to create the Video document separately in the CMS and "link" them to the parent.

Really? So what happens if I use the same video url in 2 separate "parent" documents? Will you copy it twice? 

 

The simplistic approach I have taken so far is to register an implementation of the DaemonModule and listen for publication events for the parent document, and then try and manually create a new Video document for each of the embedded videos. However this can't be the correct way to achieve this as I have no idea how to populate the various hippo-related properties, so I suspect I need to submit the raw document to some sort of workflow.

This is the way, and you can use the built-in FolderWorkflow to create new VideoDocuments and populate any properties you need afterwards, your code more or less will look like this:

WorkspaceDecorator workspaceDecorator = (WorkspaceDecorator) session.getWorkspace();

FolderWorkflow folderWorkflow = (FolderWorkflow) workspaceDecorator.getWorkflowManager().getWorkflow("threepane", session.getNode("/content/documents/myhippoproject/folderYouWantYourNewVideoDocumentIn"));

String docPath = folderWorkflow.add("new-video-document-template", "myhippoproject:videodocument", "nameOfYourNewDocument");

//... get the node of the new document and set your propeties

Note that a daemon module uses a different session, so the new video documents will be not be created by the user who initially made the "parent" document. You need to use SCXML for that.

In my opinion you're deviating a lot from the ootb workflow, sacrificing reusability on the way and ending with custom code that can make your upgrades and maintenance hard. If you're new to Hippo then I would suggest you don't go this route, but instead try to convince your client otherwise or ask for more official support from a Bloomreach consultant (contact sales).

Most likely some form of document wizard would fit the usecase best. But listen to Minos, he knows things. 

DocumentWizard could indeed also do this post action after a "parent" has been created. And then the right session is used too. The document wizards are full of worfklow code by the way, so more or less the code needed will be the same regardless if called from the wizard, a daemon module or scxml.

cheers,

Minos

--

--

p. e.

minos.ch...@bloomreach.com

_________________________________________________________________________________

[tony.h...@gmail.com]

Hi all,

Thanks a lot for all your responses and appreciate your patience with a Hippo newbie. ;-)

I certainly don't want to go down any paths that deviate from accepted best practice.

Let me explain a little more about the use case, maybe there is a better solution here.

My client's is equally concerned with the CMS user (create, author & edit) role, as well as the end-user role (i.e. the person that uses the web site that the CMS supports). Usability is a key requirement and differentiator.

Architecturally, the solution will integrate static content managed through Hippo CMS, and control elements implemented using an Angular JS framework communicating with an AWS hosted Spring Boot micro service environment (for those interested, this will be implemented using Netflix OSS components supporting service discovery, routing etc).

 The Application Domain relates to the "Internet of Things" (IoT) and includes  a "support" component, which is where the CMS comes in to play.

A typically "support" use case, might be,  for example, to learn how to configure Device A  to control  Device B. (device A may be an Amazon/Google controller and device B may be a wifi enabled light)

The user of CMS will create documents (a document type called "device") for each of the A and B devices. This document type includes the usual properties such as Title, Introduction, Description, Keywords (from a hippo taxonomy), images, a list of links to external videos (YouTube, vimeo etc) [1] , and a list of links to external websites (e.g. the OEM websites own support content, FAQs etc). [2]

Now (1) and (2) are implemented as custom compound types. For example, (1) includes Title, Introduction, Video Url and keywords from the taxonomy. As the CMS author/editor creates the document for Device A, they want to be able to add any videos or external references  in a seamless manner, not needing to navigate through multiple tabs for example, to first create the Video document and then link it to the Device document.

The "support" user (i.e. the end user of the website served by Hippo), may need to retrieve a list of documents which contain certain taxonomy keywords (e.g. Wifi AND Device A AND troubleshooting) and these documents may be videos, web references or devices. This sort of search is simple if these types of documents are stored separately and "linked" to each other, but if they are "embedded" I am not sure how easy it will be to extract videos and website references independent of the "parent".

Anyhow, I am working with the client to try and convince them that the embedded solution has problems, even though from a usability perspective it is pretty seamless and smooth.

Best Regards

Tony

[Minos Chatzidakis]

Hi,

So this seems like a case where ease and speed of creating these device documents is more important than reusability. I personally wouldn't have a problem with that but I just hope that the customer understands following implications:

• When an editor needs the same video in multiple device documents, they need to enter the same data in each of those documents
  
• And for each of those entries, a new video document is automatically created, meaning you end up with duplicates
  
• You'll get all of these duplicates in your search results, which is wrong
  
• What happens with versioning? Do you create new video documents when the device document is changed? Or keep track of all video documents created in the past from this device, and update them when the device doc changes? How exactly will you do that?
• Any correction that needs to happen later to a video entry, needs to be applied to all devices with this video, and to all video documents that may have been created from those compounds. How does one find all those documents in the CMS? 

In my opinion this is a more complicated workflow and the editors will have a harder time maintaining this; some fewer clicks now will cause way more clicks later. 

In any case, if you indeed decide to do this you can use either the built-in document workflow (scxml) or event listeners to register a listener on device documents, then iterate over the document's compounds and use FolderWorkflow to create new Video documents.

hth!

Minos

--

--

Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-community@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-community+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

[Jasper Floor]

You could also see it as a customization of UI. A document wizard will only help on document creation, not editing. You want your document to only contain a link another document, but the UI top support more. This should be achievable with a customization of the plugin class that renders that node. On edit you could display a modal dialogue which is actually a document editor. You would have to write most of the UI code, but could certainly leverage the existing workflows. I wouldn't call it trivial however.

mvg,

Jasper

--

p. e.

minos.chatzidakis@bloomreach.com

_________________________________________________________________________________