Can I Query Dynamic Content Beans using Fluent Search API?

Experience Manager (PaaS/OnPrem)
1

I’m working on creating a new Document Type for a specific set of documents for which I will need to query within a custom Java component. Looking the options available in v13 I’ve come across the Fluent Search API as the recommended approach. Additionally after creating the document type I ran the Bean Writer tool but unfortunately this had the result of writing a bunch of beans that I wasn’t interested in tracking (currently running on a locally restored production content repository backup) and it didn’t seem to include a bean at all for my new document type.

Reading a bit more into new behavior as of v13 I notice now that there is built in and default support for Dynamic Content Beans which in some cases I’m betting would greatly simplify working with designing and working with content in general in brXM however I’m not certain how this would be compatible if at all with cases where the document types are typically referenced directly such as within the Java code like my custom component.

So I have essentially two related main questions on how to progress:

  1. Do I need to create a Java bean implementation for my document type either through the bean writer or by hand in order to work with the Fluent Search API?
  2. Does the Bean Writer tool no longer work due to the introduction of Dynamic Content Beans? If so is there there any common troubleshooting for when the Bean Writer is not writing out a bean for a new Document Type?
2

  1. You don’t need to create a bean type for the fluent search api. However, you won’t be able to restrict the query by the Bean type. You can still restrict by node type, so this is not a real limitation.

  2. The Bean writer tool still works. Dynamic content beans are created when there is no bean class, or when there are properties missing from the bean class (so it can enhance existing beans). There are some limitations to the bean writer, but those were there before dynamic content beans.

For simple types there is no longer a need to create a bean class. However, if you need to reference them in code it is still useful to create a bean. Also when you wish to add logic to a bean beyond the simple getter/setter logic.

1 Like
3

Thank you @jasper.floor for your response. Are there any examples that you can point me to or give on how to “restrict by node type” when using dynamic content beans with the Fluent Search API? I can guess at how to get at the properties once I get the resulting beans by peeking at how the generated beans pull data out dynamically using methods like getSingleProperty and such.

4

Instead of restricting by class you use the node type:

 builder.ofTypes("example:document").build() 
 builder.ofPrimaryTypes("example:document").build()

The first line will inculde documents that inherit from “example:document” the second won’t.

retrieving properties would be something like:

            HstQueryResult queryResult = query.execute();
            HippoBeanIterator hippoBeans = queryResult.getHippoBeans();

            while (hippoBeans.hasNext()) {
                HippoBean bean = hippoBeans.nextHippoBean();
                String singleProperty = bean.getSingleProperty("example:singleproperty");
                Long[] multipleProperty = bean.getMultipleProperty("example:multipleproperty");
                HippoBean child = bean.getBean("example:child");
            }

Note that you cannot cast to just any type you want. If the data is Long, you cannot cast to Calendar. Jcr only supports limited types. You can look in the method javadoc for more information. For childbeans (compounds are child beans) you can cast to HippoBean, or a specific bean if you made one for that.

1 Like
5

Thanks for the example @jasper.floor. I’ll evaluate this strategy and see whether it makes sense for us to create a custom Java bean for our document type or to leverage the mechanism shown here. It’s good to have the option either way.