Expand my Community achievements bar.

Enhance your AEM Assets & Boost Your Development: [AEM Gems | June 19, 2024] Improving the Developer Experience with New APIs and Events
SOLVED

AEMaaCS asset search

Avatar

Level 2

Is it possible to restrict an asset to appear in search based on a particular metadata field in AEM as a Cloud Service.

 

For example: I have an asset which include multiple metadata fields, also there are some metadata fields that contain numeric values.

So, I want my asset not to appear in search result only if the numeric value is being typed in the navigation search bar and if any other metadata field value is typed it should appear.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

In AEM as a Cloud Service (AEMaaCS), I am pretty sure you are using the Query Builder. Moving forward, if you have a custom search functionality on your website that actually utilizes the Query Builder for its search capabilities, you can exclude specific properties from being searchable in the full-text search results. To achieve this, you can include a new predicate group in your search query to exclude these properties.

 

Here's an example code snippet demonstrating how you can implement this:

 

 

 

import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.resource.ResourceResolver;
import org.apache.sling.api.servlets.SlingAllMethodsServlet;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;

import javax.servlet.Servlet;
import javax.servlet.ServletException;
import java.io.IOException;

@Component(service = Servlet.class, property = {
        "sling.servlet.methods=GET",
        "sling.servlet.paths=/bin/mysearch"
})
public class MySearchServlet extends SlingAllMethodsServlet {

    
    private QueryBuilder queryBuilder;

    
    protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
        ResourceResolver resourceResolver = request.getResourceResolver();

        // Get the search text and excluded property value from the request parameters
        String searchText = request.getParameter("q");
        String excludedProperty = "myProperty";
        String excludedValue = request.getParameter("excludeValue");

        // Perform the search using the QueryBuilder
        SearchResult searchResult = performSearch(searchText, excludedProperty, excludedValue, resourceResolver);

        // Process and return the search result
        // ...

        // Example: Writing the search result as JSON response
        response.setContentType("application/json");
        response.getWriter().write(searchResult.toJSON());
    }

    private SearchResult performSearch(String searchText, String excludedProperty, String excludedValue, ResourceResolver resourceResolver) {
        // Create a new QueryBuilder instance
        QueryBuilder builder = resourceResolver.adaptTo(QueryBuilder.class);

        // Create a new query using the builder
        Query query = builder.createQuery(PredicateGroup.create());

        // Add the full-text search condition to the query
        query.fulltext(searchText);

        // Exclude assets based on the specified property and value
        PredicateGroup excludedPredicateGroup = new PredicateGroup();
        Predicate excludedPredicate = PredicateGroup.createPropertyPredicate(excludedProperty, excludedValue);
        excludedPredicateGroup.add(excludedPredicate);
        query.and(excludedPredicateGroup.setNegated(true));

        // Execute the query and retrieve the search results
        SearchResult result = query.getResult();

        return result;
    }
}

 

 

Too much information, but...

In the context of full-text search, the query parameter `q` is commonly used across best practices as a standard convention for representing the search query. The letter "q" stands for "query" and is often chosen for its simplicity and ease of understanding.

Using a consistent query parameter name like `q` has several benefits:

1. Readability and clarity: By using a common parameter name like `q`, it becomes easier for developers and API consumers to understand the purpose of the parameter and its role in performing a full-text search.

2. Simplicity and convention: Adopting a standard query parameter name simplifies the API design and usage. It becomes intuitive for developers to recognize that `q` represents the search query regardless of the specific API or service being used.

3. Compatibility and interoperability: Many libraries, frameworks, and tools that facilitate API integration and communication expect or recommend the use of `q` as the query parameter for full-text search. By following this convention, you enhance compatibility and interoperability with such tools and ensure consistency across different systems.

While it's important to note that using `q` as the query parameter is not mandatory, it has become a widely accepted convention due to its simplicity and widespread usage in various APIs and services. Adhering to this convention promotes consistency, enhances code readability, and facilitates easier integration with existing tools and frameworks.

View solution in original post

3 Replies

Avatar

Community Advisor

Hello @sanchay1 -

 

Yes, it is possible to restrict an asset from appearing in search based on a particular metadata field in AEM as a Cloud Service.

 

Here's how you can achieve this:

 

1. Open the AEM Assets user interface and navigate to the folder containing the assets you want to restrict from search.

2. Select the asset for which you want to apply the restriction.

3. In the asset properties panel, locate the metadata field that contains the numeric value you want to use for the restriction.

4. Edit the metadata field and add a unique identifier or flag to indicate that the asset should be excluded from search when this value is used.

5. Save the changes to the asset's metadata.

6. Next, you'll need to customize the search component or search functionality in your AEM application to include the restriction logic.

 

- Identify the search component or functionality you are using to perform the search. This could be a custom search component or the out-of-the-box AEM search functionality.

- Modify the search logic to include a check for the metadata field containing the numeric value and exclude assets that have the specific identifier or flag set in that field.

 

- You can use the AEM QueryBuilder API or other search APIs available in AEM to customize the search query and apply the necessary filters based on your metadata field and restriction criteria.

 

Avatar

Correct answer by
Community Advisor

In AEM as a Cloud Service (AEMaaCS), I am pretty sure you are using the Query Builder. Moving forward, if you have a custom search functionality on your website that actually utilizes the Query Builder for its search capabilities, you can exclude specific properties from being searchable in the full-text search results. To achieve this, you can include a new predicate group in your search query to exclude these properties.

 

Here's an example code snippet demonstrating how you can implement this:

 

 

 

import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.resource.ResourceResolver;
import org.apache.sling.api.servlets.SlingAllMethodsServlet;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;

import javax.servlet.Servlet;
import javax.servlet.ServletException;
import java.io.IOException;

@Component(service = Servlet.class, property = {
        "sling.servlet.methods=GET",
        "sling.servlet.paths=/bin/mysearch"
})
public class MySearchServlet extends SlingAllMethodsServlet {

    
    private QueryBuilder queryBuilder;

    
    protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
        ResourceResolver resourceResolver = request.getResourceResolver();

        // Get the search text and excluded property value from the request parameters
        String searchText = request.getParameter("q");
        String excludedProperty = "myProperty";
        String excludedValue = request.getParameter("excludeValue");

        // Perform the search using the QueryBuilder
        SearchResult searchResult = performSearch(searchText, excludedProperty, excludedValue, resourceResolver);

        // Process and return the search result
        // ...

        // Example: Writing the search result as JSON response
        response.setContentType("application/json");
        response.getWriter().write(searchResult.toJSON());
    }

    private SearchResult performSearch(String searchText, String excludedProperty, String excludedValue, ResourceResolver resourceResolver) {
        // Create a new QueryBuilder instance
        QueryBuilder builder = resourceResolver.adaptTo(QueryBuilder.class);

        // Create a new query using the builder
        Query query = builder.createQuery(PredicateGroup.create());

        // Add the full-text search condition to the query
        query.fulltext(searchText);

        // Exclude assets based on the specified property and value
        PredicateGroup excludedPredicateGroup = new PredicateGroup();
        Predicate excludedPredicate = PredicateGroup.createPropertyPredicate(excludedProperty, excludedValue);
        excludedPredicateGroup.add(excludedPredicate);
        query.and(excludedPredicateGroup.setNegated(true));

        // Execute the query and retrieve the search results
        SearchResult result = query.getResult();

        return result;
    }
}

 

 

Too much information, but...

In the context of full-text search, the query parameter `q` is commonly used across best practices as a standard convention for representing the search query. The letter "q" stands for "query" and is often chosen for its simplicity and ease of understanding.

Using a consistent query parameter name like `q` has several benefits:

1. Readability and clarity: By using a common parameter name like `q`, it becomes easier for developers and API consumers to understand the purpose of the parameter and its role in performing a full-text search.

2. Simplicity and convention: Adopting a standard query parameter name simplifies the API design and usage. It becomes intuitive for developers to recognize that `q` represents the search query regardless of the specific API or service being used.

3. Compatibility and interoperability: Many libraries, frameworks, and tools that facilitate API integration and communication expect or recommend the use of `q` as the query parameter for full-text search. By following this convention, you enhance compatibility and interoperability with such tools and ensure consistency across different systems.

While it's important to note that using `q` as the query parameter is not mandatory, it has become a widely accepted convention due to its simplicity and widespread usage in various APIs and services. Adhering to this convention promotes consistency, enhances code readability, and facilitates easier integration with existing tools and frameworks.