In the product cockpit of the backoffice there is a search feature to which you can add some filters , I would like to add some of my own attributes to the filters.
In the my custom backoffice extension in the config.xml i added
<context type="MyProduct" component="pcmbackoffice-fulltext-search" module="pcmbackoffice">
<ful:fulltext-search xmlns:ful="http://www.hybris.com/cockpitng/config/fulltextsearch" xmlns:y="http://www.hybris.com/cockpit/config/hybris">
<ful:field-list>
<ful:field name="MyProduct.Name"/>
<ful:field name="MyProduct.Type"/>
<ful:field name="MyProduct.isActive"/>
</ful:field-list>
<ful:preferred-search-strategy>solr</ful:preferred-search-strategy>
<ful:operator>OR</ful:operator>
</ful:fulltext-search>
</context>
i then ran a clean all and an update from the hac , but the changes are not shown. in the console i see
[DefaultFieldQueryFieldRenderer] Unable to determine field configuration for
field 'MyProduct.Name' in 'pcmbackoffice-collectionBrowser-
fulltextsearch'
I have also tried the config below.
<context type="MyProduct" component="pcmbackoffice-fulltext-search" module="pcmbackoffice">
<ful:fulltext-search xmlns:ful="http://www.hybris.com/cockpitng/config/fulltextsearch" xmlns:y="http://www.hybris.com/cockpit/config/hybris">
<ful:field-list>
<ful:field name="MyProduct.Name"/>
<ful:field name="MyProduct.Type"/>
<ful:field name="MyProduct.isActive"/>
</ful:field-list>
<ful:preferred-search-strategy>solr</ful:preferred-search-strategy>
<ful:operator>OR</ful:operator>
</ful:fulltext-search>
</context>
which does not change the default settings (product).
any help on how to configure the search and filters in the product cockpit would be great
You can follow step which is described in document.
You need to configure your variant for backoffice search solr indexing at System > Search and Navigation > Indexed Types.
Related
I have created my Apache Velocity template under /resources/fileTemplates/internal/myTemplateClass.vm and would like to use it through:
final JavaDirectoryServiceImpl javaDirectoryService = new JavaDirectoryServiceImpl();
javaDirectoryService.createClass(myPsiDirectory,
"MyClassname",
"myTemplateClass");
So I added the following in my plugin.xml:
<extensions defaultExtensionNs="com.intellij">
<!-- Add your extensions here -->
<internalFileTemplate name="myTemplateClass"/>
</extensions>
However when I run my plugin it claims that it did not find a template with the name "myTemplateClass". I assume it is cause I haven't linked to the file perse. Where should I link this?
Thanks
If you have an <internalFileTemplate> with the name of "myTemplateClass" and you want to use it to create a Java class, the template needs to be stored as fileTemplates/internal/myTemplateClass.java.ft. So you need to change the extension of your file.
i need to optimize the CQ5 lucene indexing configuration for my application.
I want to provide a custom search configuration but i struggle to really understand the default configuration.
Source: https://helpx.adobe.com/experience-manager/kb/SearchIndexingConfig.html)
First question:
Are the "include"-tags used in the default configuration correct?
For example:
The default configuration uses the tag "include" to include the Property "jcr:content/jcr:lastModified" for the nt:file-Aggregate
<aggregate primaryType="nt:file">
<include>jcr:content</include>
<include>jcr:content/jcr:lastModified</include>
</aggregate>
Compare this to the Jackrabbit wiki which uses the "include-property" for the exact same case. Source: http://wiki.apache.org/jackrabbit/IndexingConfiguration
<aggregate primaryType="nt:file">
<include>jcr:content</include>
<include-property>jcr:content/jcr:lastModified</include-property>
</aggregate>
I only can assume it doesn't matter but i can't find any source to confirm this.
Second question: for the nodeType "cq:PageContent" all properties of four levels are aggregated.
<aggregate primaryType="cq:PageContent">
<include>*</include>
<include>*/*</include>
<include>*/*/*</include>
<include>*/*/*/*</include>
</aggregate>
I assume that because of the aggregation all properties are indexed which are contained within these 4 levels.
Or do i must consider the index rules for the nodeType nt:base which basicly only includes properties which are matching the pattern ".:.".
<index-rule nodeType="nt:base">
<property nodeScopeIndex="false">analyticsProvider</property>
<property nodeScopeIndex="false">analyticsSnippet</property>
...
<property isRegexp="true">.*:.*</property>
</index-rule>
Best regards
The default configuration is ideed incorrect as confirmed by the Adobe CQ5 Support.
For the aggegate to work correctly properties must be included by the "include-property"-Tag
So the default search configuration (or atleast the documentation) is not correct https://helpx.adobe.com/experience-manager/kb/SearchIndexingConfig.html)
Our TFS 2012 team project was migrated to a new TFS2013 server with all data.
When I now try to activate the new "Portfolio Backlog" feature the following error is presented:
[Error] TF400618: The reporting type of field
'Microsoft.VSTS.Common.StateChangeDate' in work item type 'Feature'
conflicts with the reporting type of the existing field
In Scrum 2.2 the type definitions of SharedStep and TestCase have this field definition
<FIELD name="State Change Date" refname="Microsoft.VSTS.Common.StateChangeDate" type="DateTime">
<WHENCHANGED field="System.State">
<SERVERDEFAULT from="clock" />
</WHENCHANGED>
<WHENNOTCHANGED field="System.State">
<READONLY />
</WHENNOTCHANGED>
</FIELD>
In the Scrum 3.0 additional the Feature has these field.
In the MSDN under TF400618: The reporting type of field '{0}' in work item type '{1}' conflicts with the reporting type of the existing field.
I'm not understanding what I need to do to resolve the issue with the feature field.
Do I need to manually alter the scrum 2.2 process template with the feature work item type , publish the changed process template into the team project and than activate the "Portfolio Backlog"?
Once you've modified your process template, TFS can't automatically install the new updates to it. Here's guidance on how to update it manually: http://msdn.microsoft.com/en-us/library/ms194972(v=vs.120).aspx
I recommend that you instead script your process template changes in a batch file so that when new versions come out, you can easily repeat your changes in the new template rather than going through the 12-step manual process above.
I wasn't able to configure Features after performing all the steps as mentioned in :http://msdn.microsoft.com/en-us/library/ms194972(v=vs.120).aspx
So I updated the Feature.xml such that the "State Change Date" FIELD name as a reportable option set to "dimentions"
After this change I updated the the default template to the one I had customized and was able to configure Features.
Here is how the updated code in Feature.xml looks:
<FIELD name="State Change Date" refname="Microsoft.VSTS.Common.StateChangeDate" type="DateTime" reportable="dimension" >
I would love to add support for Working Sets for my Eclipse plugin that used the Common Navigator framework.
In Eclipse bugzilla there is mention that this is supported
None of the online manuals for the Common Navigator explain how to do it
I do not know where to start even since there is no extension point for it, and the Working Set implementation classes are all "internal". I have a very basic navigator setup showing default project resources and some additional IFileSystem stuff implementing ITreeContentProvider.
You can get the working set manager using:
IWorkingSetManager manager = PlatformUI.getWorkbench().getWorkingSetManager();
and from that get the visible working sets with:
IWorkingSet [] workingSets = manager.getWorkingSets();
the members of a working set can be accessed with:
IAdaptable [] elements = workingSet.getElements();
so you could use the working sets list as the input for the tree viewer and adjust your tree content provider to deal with this.
In retrospect the following is a better solution. Instead of implementing ITreeContentProvider and traversing the working sets ourselves, we can reuse existing standard providers for the same content, which might work better.
You can use them like so:
<extension
point="org.eclipse.ui.navigator.viewer">
<viewerContentBinding
viewerId="rascal.navigator">
<includes>
<contentExtension pattern="org.eclipse.ui.navigator.resourceContent" />
<contentExtension pattern="org.eclipse.ui.navigator.resources.filters.*"/>
<contentExtension pattern="org.eclipse.ui.navigator.resources.linkHelper"/>
<contentExtension pattern="org.eclipse.ui.navigator.resources.workingSets"/>
</includes>
</viewerContentBinding>
In particular the org.eclipse.ui.navigator.resources.workingSets is what adds working sets capabilities to your navigator.
Adding your own content then becomes an issue of adding another content provider which ignores workingsets and projects and other kinds of resources which are already taken care of, e.g. like so:
<extension
point="org.eclipse.ui.navigator.navigatorContent">
<navigatorContent
activeByDefault="true"
contentProvider="org.rascalmpl.eclipse.navigator.NavigatorContentProvider"
id="org.rascalmpl.navigator.searchPathContent"
labelProvider="org.rascalmpl.eclipse.navigator.NavigatorContentLabelProvider"
name="Rascal search path"
priority="normal">
<triggerPoints>
<or>
<instanceof value="org.eclipse.core.resources.IResource"/>
</or>
</triggerPoints>
<possibleChildren>
<or>
<instanceof value="java.lang.Object"/>
</or>
</possibleChildren>
<actionProvider
class="org.rascalmpl.eclipse.navigator.NavigatorActionProvider"
id="org.rascalmpl.navigator.actions">
</actionProvider>
<commonSorter
class="org.rascalmpl.eclipse.navigator.Sorter">
</commonSorter>
</navigatorContent>
<commonWizard
type="new"
wizardId="rascal_eclipse.wizards.NewRascalFile">
<enablement></enablement>
</commonWizard>
<commonWizard
type="new"
wizardId="rascal_eclipse.projectwizard">
<enablement></enablement>
</commonWizard>
</extension>
and in the NavigatorContentProvider class we implement getElements and getChildren but only for our own additional content.
For simplicity, say I have a resource users. The HTTP call GET users/ returns a list of links to concrete users:
<users>
<link rel='user' href='/users/user/1/'/>
<link rel='user' href='/users/user/2/'/>
<link rel='user' href='/users/user/3/'/>
....
</users>
The result representation is described in a specific media type:
application/vnd.company.Users+xml
In our frontends, we want to display a table with all users. This means we need to be able to fetch user information to display, such as the name, gender, friends, ... I would like to avoid that we need a separate request for each user (GET /users/user/x/) to retrieve this information. In addition, some frontends will only display the name, while other frontends will display the name and his/her friends. And so on.
In essence, we are still returning users, but with extentions depending on what the frontend needs.
Which option would you choose? Why?
(1) Make GET users/ customizable via parameters such that the customizations are listed. Depending on the customizations , different media types might be returned, since the syntax of one version/combination might be very different than one of another version/combination:
GET users/ -> application/vnd.company.Users+xml
GET users/?fields=name,gender -> application/vnd.company.Users+xml
GET users/?fields=name,gender,friends -> application/vnd.company.UsersWithFriends+xml
(2) Different resources are created to distinguish different between media types. Parameters are still used for basic customizations covered by the media type. This gives:
GET users?fields=name -> application/vnd.company.Users+xml
GET users?fields=name,gender -> application/vnd.company.Users+xml
GET users_with_friends?fields=gender -> application/vnd.company.UsersWithFriends+xml
(3) The same as (1), but instead of parameters, the desired media type is set by the client in the Accept header. Customizable fields covered by the media type are still set via parameters:
GET users/?fields=name ACCEPT application/vnd.company.Users+xml
GET users/?fields=name,gender ACCEPT application/vnd.company.Users+xml
GET users/?fields=name,gender ACCEPT application/vnd.company.UsersWithFriends+xml
(4) Something else?
To answer my own question, I think that:
Solution (1) is very very wrong. The media type must not be dependant on parameters.
Solution (2) and (3) are more or less equal and up to preferences. I prefer (3) since this would not introduce an explosion of resources to be introduced. In addition, in essence we are still returning users. The only difference is the amount of information, reflected by different media types, that is returned. So one might argue that there is no real need to introduce new resources as done in (2).
Do you agree? What do you think?
(3) is surely the best using strict Media Type, but would require specific HTTP Request client and won't be accessible through basic URL open library or browser.
Why not using solution 1 with another extra parameter : names "expect" or "as".
ie:
users/?fields=name,gender&expect=application/vnd.company.Users+xml
users/?fields=name,gender&expect=application/vnd.company.UsersWithFriends+xml
This would be the same as ACCEPT solution but won't need very custom client library to forge the request.
However you'll have to parse the parameter to provide correct output (the (3) would also have this requirement for parsing the ACCEPT)
Personally, I'm not a fan of using query string parameters to allow clients to pick the data elements they wish to include in a representation. I find it makes it hard to optimize the server and it pollutes the cache with many overlapping variants. Also, you really shouldn't try and use conneg to select between representations that contain different sets of data. Conneg is really just for selecting the serialization format.
With the Hal media type you can approach this problem a bit differently. Consider a service with a root representation that looks like:
<resource rel="self"
href="http://example.org/userservice"
xmlns:us="http://example.org/userservice/rels">
<link rel="us:users" name="users" href="http://example.org/users">
<link rel="us:userswithfriends" href="http://example.org/userswithfriends">
</resource>
When you use hal, instead of using the media type documentation to describe your application domain, you can use link relations. In this case, the us:users link points to a document that contains a list of users. I know the namespace stuff looks a bit wierd, but it is not really being used as an XML namespace, just as way of making a Compact URI (CURIE). When you invent your own rel values, they need to be specified in the form of a URI to try and ensure uniqueness.
The list of users would look something like:
<resource rel="self"
href="http://example.org/users"
xmlns:us="http://example.org/userservice/rels">
<resource rel="us:user" name="1" href="/user/1">
<name>Bob</name>
<age>45</age>
<resource>
<resource rel="us:user" name="2" href="/user/2">
<name>Fred</name>
<age>Bill</age>
<resource>
</resource>
and 'us:userswithfriends' points to a different resource that contains the list of users with each user containing a list of friends.
<resource rel="self"
href="http://example.org/users"
xmlns:us="http://example.org/userservice/rels">
<resource rel="us:user" name="1" href="/user/1">
<name>Bob</name>
<resource rel="us:friend" name="1" href="/user/10">
<name>Sheila</name>
<resource>
<resource rel="us:friend" name="2" href="/user/74">
<name>Robert</name>
<resource>
<resource>
<resource rel="user" name="2" href="/user/2">
<name>Fred</name>
<resource rel="us:friend" name="1" href="/user/14">
<name>Bill</name>
<resource>
<resource rel="us:friend" name="2" href="/user/33">
<name>Margaret</name>
<resource>
<resource>
</resource>
With hal it is the documentation of your rels (us:users, us:friend) that decribes what data elements are allowed to exist in the resource element. You are free to embed all of the data of the resource, or more likely just a subset of the data. If the client wants to access a completely representation of the embedded resource then it can follow the provided link.