soen/conjunction

A Sitecore utility designed to create configurable and personalizable queries for either the Lucene or Solr search engine using Sitecore's ContentSearch API

Conjunction is a utility for Sitecore that solves the issue of creating configurable and personalizable queries for either the Lucene or Solr search engine, using Sitecore's ContentSearch API as the backbone.

Features

Conjunction has some interesting parts that are worth mentioning, as it:

• Enables search query configuration without code changes
• Allows specifying nested search query structures for complex queries
• Allows a search query to either react to values provided dynamically, or by using preset default values
• Makes it possible to vary search queries based on personalization
• Uses the ContentSearch API as the underlying interface for querying search results
• Enables extensibility

Installation instructions

Before installing Conjunction, you'll need a working Sitecore 8.0 (or later) instance running on your machine.

• Install Conjunction binaries. This is as simple as adding the Conjunction.Foundation.Core NuGet package to your project.
• Install Conjunction Sitecore package. You can find the required Sitecore package here, which contains the nessecary Sitecore templates and items required to configure search queries from Sitecore.

Documentation

• Introduction
• Basics
• Advanced
• Troubleshooting
• Glossary
• API Reference
• Change Log

License

This project is licensed under the MIT License.

conjunction's Issues

Add Control Panel for working with search query elements

The control panel should enable the user to:

1. Create new search queries
2. Execute the search queries (or parts of it) to preview results

Add support for facets

Add unit tests

Currently, the core API does not contain any unit tests. This needs to be added.

In terms of unit testing the ContentSearch API specific parts, this can be helpful: https://gist.github.com/aquasonic/ac99844e1771ab3cce80

With respect to keeping the unit tests DRY: http://megakemp.com/2011/12/15/keep-your-unit-tests-dry-with-autofixture-customizations/

Note: Create a unit test for each line in MemberData needs to support serialization, otherwise it won't work: xunit/xunit#429

Move Sitecore specific code out of the Conjunction.Foundation.Core assembly

Do you want to request a feature or report a bug?
Feature/Change.

What is the current behavior?
Currently, the core assembly of Conjunction Conjunction.Foundation.Core contains both abstract interfaces and generic implementation details, as well as Sitecore specific implementation details.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
N/A

What is the expected behavior?
The core assembly should be split into two separate assemblies, whereas the existing Conjunction.Foundation.Core assembly only contains abstract interfaces and generic implementation details. Likewise, a new assembly (could be named Conjunction.Foundation.Sitecore) should exist, which should contain all the concrete implementation details in the context of using Sitecore - this assembly will be dependant on the Conjunction.Foundation.Core assembly.

What is the motivation / use case for changing the behavior?
In its current state, the Conjunction.Foundation.Core assembly is tightly coupled together with Sitecore specific implementation details. This makes it hard to reuse the true "core" parts of the Conjunction.Foundation.Core assembly in a different context.

Which versions of Conjunction is affected by this issue? Did this work in previous versions of Conjunction?
Current production and development version is affected.

Other information (e.g. stacktraces, related issues, suggestions how to fix)
N/A

Write documentation

Currently the only documentation available is the Demo project, that shows the vary basic of the Core API in code. However, there is no information about how you would setup the search query element configuration from within Sitecore, etc.

The documentation should contain:

• A mental model for how the search query element structure is organized (and related)
• A detailed description on how to setup search query roots, groupings and rules
• A description on how to use the API from code (an example is already included in the Demo project)
• How you can extend the different API parts (i.e. the different providers, making you own IndexableEntity, etc.)

In order to create a modern and simple solution to documentation, we'll be using GitBook as the foundation.

Setup continuous integration

Setup continuous integration that builds and tests the solution, possibly also building NuGet packages ready to be deployed.

Add support for having multiple value providers

Do you want to request a feature or report a bug?

Feature.

What is the current behavior?

It is only possible to have a single value provider for all parts of the search query.

What is the expected behavior?

Search query rule elements should be able to specify their value provider through configuration.

What is the motivation / use case for changing the behavior?

Looking the the value providers, Conjunction ships with a built-in one, that allows grabbing dynamic provided values from, say, the query string. However, it was originally designed such that the value provider could be anything really - a web service, the data exchange framework, or such. But one thing that I didn’t plan for, was the need for having more than more source of value provider, and this is something that would be great to extend as well. Imagine that we had some parts of the query that allowed retrieving their values from the query string, then some other parts would grab their values from the data exchange framework, or something else. That way we can truly leverage the power of combining multiple data sources together with searching.

Which versions of Conjunction is affected by this issue? Did this work in previous versions of Conjunction?

Initial version, v1.0.

Other information (e.g. stacktraces, related issues, suggestions how to fix)

N/A

Conjunction template location is a bit off

The location of the module is a bit off compared to what other people use.

I would expect a module to install Items under
/sitecore/templates/Modules/[ModuleName]

/sitecore/templates/Modules/[ModuleName]

To have a common behaviour with the rest of the community projects out there.

It is a "problem" in Conjunction 1.0

Add support for rules on search query rules

Look into the way this is implemented in WFFM, this can also serve as inspiration: http://sitecoreblog.blogspot.dk/2013/03/in-sitecore-one-of-field-you-can-use-is.html?m=1

Add .gitattributes to handling line-ending issues

Add the .gitattributes file to the project, such that we don't have to deal with unwanted line-ending issues.

The following StackOverflow Q/A explains how this should be done:
http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git

Moreover, review the .NET CoreFx version as well for inspiration:
https://github.com/dotnet/corefx/

Refactor Unicorn serialized content to follow Sitecore Helix structure

Do you want to request a feature or report a bug?

Bug/Change

What is the current behavior?

The current Unicorn serialized content doesn't follow the practices described in Helix. Currently, the serialized content lives under a single project named Conjunction.Foundation.Content, which should be separated out into the respective projects. This means that content (settings, templates, etc) related to the Core part of the project, goes into a 'serialization' folder under the Core project.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

N/A

What is the expected behavior?

The serialized items should live under their respective domains, rather then being placed into a single Content project.

What is the motivation / use case for changing the behavior?

The project should adhere to the principles and practices of Helix.

Which versions of Conjunction is affected by this issue? Did this work in previous versions of Conjunction?

Development, has not yet been released.

Other information (e.g. stacktraces, related issues, suggestions how to fix)

The answer provided here should be used as a basis for the restructuring.

Rework the way that indexable entity types are configured and how properties from this is selected on search query rules

Currently, you have to define the indexable entity type by fully qualified namespace on the search query root item. In addition, for each search query rule, you have to specify the property name of the given indexable entity type that you want to perform the rule on. Although this works, this approach is prone to error, since both inputs are defined using a textbox without any kind of validation - the UI should handle this a bit more elegantly.

A solution to this could be to have a dropdown for selecting indexable types enumerate all assemblies in the Sitecore solution, and list all types that inherit from the IndexableEntity type. Then for search query rules, we could also use a dropdown, whereas the source of the property names must come from the configured indexable entity type set on the search query root item.

In terms of getting the correct elements displayed in the dropdown menus, one way would be to override the Sitecore.Pipelines.GetLookupSourceItems pipeline, and implement a specific pipeline for retrieving the types of indexable entity types as well as getting the fields of the selected indexable entity type using reflection. This blog post provides a good starting point for doing this: http://blog.rauljimenez.co.uk/getting-to-the-source/. The other alternative would be to create custom field types for each of the two, but that seems a bit over the top to do.

Add more robust error handling and logging

Currently most of the methods asserts that parameters cannot be null (or empty), but there are still a few places left where this is missing.

Also, there is also not enough error/info/warn logging.

Add support for pagination

Add Azure Search support

Recently, Sitecore added support for Azure Search to the ContentSearch API.

Going through the documentation listed here, it seems that the current codebase should support Azure Search. However, the API needs to be tested fully using Azure Search in order to ensure that nothing breaks.

Add support for sorting search results