Easier cloning of WIKI portlet (using className variants)

[12年前 に Jan Tošovský によって更新されました。]

Dear All,

I want to use WIKI for both product documentation and training materials. In search results there is a single item for them - WIKI document type - besides blogs and message boards (6.1 - faceted search). For me it would be ideal to get separate top level branches in search results for them.
I've tried to just post-process the search index of each kind differently and to override the className just for the search index, but it failed in the next step because of the missing permission settings for that new className (actually no corresponding indexer was found).

Wouldn't be possible to add support for className variants? I mean something like ...model.WikiPage.customUsage1 or ...model.WikiPage.customUsage2. Almost everything would be processed using the base className (WikiPage) and that variant would be used just for indexing. The corresponding variant would be set directly in the portlet and any further details could be specified in the portal-ext.properties file.

From my point of view the only solution now for me is to clone WIKI portlet and change the className and all the relevant stuff so that I am able to index this content separately.

I think this className feature could be generalized to any portlet - e.g. Web Content (which is also too general in some cases).

Another approach would be employing a special 'search top level group' option for the given portet. The className would be kept, but these top levels would be build not from classNames, but from the special defined top level groups.

Regards,
Jan

[12年前 に David H Nebinger によって更新されました。]

Hmm, isn't that what tags and categories are for?

[11年前 に Jan Tošovský によって更新されました。]

We have product documentation, training materials, documetation to PSO projects and other types are in consideration. In Liferay, all this stuff is provided as wiki pages. But we would like to display every type differently (layout, navigation) and also distinguish them clearly in the serach results (different item type label). As all this stuff share the same classname, it is problematic to process it differently. Now I partly use a special category for this, but I would prefer a more general solution for these cases.