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.
