---------- Forwarded message ----------
From: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
Date: Thu, Apr 3, 2014 at 6:03 PM
Subject: Re: Re[2]: [xwiki-users] SearchSuggest parameters in a new
syntax gives different behaviour
To: Dmitry Bakbardin <haru_mamburu(a)mail.ru>
On Wed, Apr 2, 2014 at 2:03 PM, Dmitry Bakbardin <haru_mamburu(a)mail.ru> wrote:
> Hi, Marius!
>
> See below.
>
>
> Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea
> <mariusdumitru.florea(a)xwiki.com>:
>
> On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea
> <mariusdumitru.florea(a)xwiki.com> wrote:
>> Hi Dmitry,
>>
>> On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin <haru_mamburu(a)mail.ru>
>> wrote:
>>> Hi, all!
>>>
>>> 5.2 -> 5.4.3 Upgrade
>>>
>>> Xwiki.SearchSuggest objects were changed
>>>
>>> It was:
>>> type:OBJECT AND (class:XWiki.BlogPostClass) AND objcontent:(__INPUT__*)
>>>
>>> It is:
>>> fq=type:DOCUMENT
>>> fq=class:Blog.BlogPostClass
>>> qf=object.Blog.BlogPostClass
>>>
>>> The main difference:
>>> - it was "__INPUT__*" query string and
>>> - (as far as I understood) it is "__INPUT__" if parameter "q" is omitted
>>>
>>> The result is Solr Suggest changes it's behaviour and gives only exact
>>> results.
>>> To make Search Suggest running as it was, we have to add: "q=__INPUT__*"
>>>
>>
>>> Is it done by puprpose or it is a bug and I have to "jira" it?
>>
>> On purpose. I did it as part of
>> http://jira.xwiki.org/browse/XWIKI-10051 (check the documentation
>> links). The reason I dropped the * (star) is because:
>>
>> (1) Prefix matching is costly
>
>
> If Search Suggest is too costly, we can turn it off completely :)
Not if there is a way to improve it. My idea was to offer by default
something that performs well, but I agree that it could also be seen
as an optimization.
>
>
>
>> (2) The search suggest is not a filter (in the sense that you have a
>> list of item and you type some text and it filters the items starting
>> with that text). Search is more complex. The search text is analysed,
>> stop words are removed, etc.
>
> (3) It was a fake prefix matching, because if you typed more words,
> only the last word was matched as prefix (not the entire text). All
> the other were analysed.
>
>
> IMHO, suggest means we prefer suggest more than exact search results. What I
> mean, that all languages wich have declensioin are too sensitive to the
> __INPUT__* search.
> Usual use case for such a search is: you enter root of the word and get back
> suggest of ALL forms of the word.
> Even in English, which is much less "declensionable", singular and plural
> is the case.
>
> E.g. "wiki" input will give only exact much and won't show "wikis". Thus, it
> makes Solr Sugges much less relevant.
typing "wiki" (without the quotes) definitely matches "wikis" if the
document (default) language is English. That is not the problem. The
"problem" is if you type "wik".
>
>
>>
>> As you said, you can get back the previous behaviour using "q=__INPUT__*"
>
>
> Yes, it was the firs I did, 'cause nearly to all my search strings Solr gave
> me "no results". It wasn't so "severe" before the upgrade. :)
>
> IMHO, it's better to leave "__INPUT__*" in default settings and amend
> documentation with performance/relevancy issues tricks for Solr Suggest
> tuning. "*" would be useful for most use cases, and would make Suggest
> effective, especially for new users who start playing with XWike.
> I do agree, that in the high load projects it could be essential to tweak
> default behaviour or turn it off at all.
I'd like to hear what others think about this. Do simple users expect
the search suggest to perform a prefix match or a standard match? In
other words, when a user types in the search suggest, does he type the
whole word or just a few letters (a prefix)?
Again, note that the previous behaviour was applying prefix matching
only for the last "word" in the search query, not for all of the words
in the query.
Thanks,
Marius
>
>
>>
>> Let me know what yo think,
>> Marius
>>
>>
>>
>>>
>>>
>>> Kind regards,
>>>
>>> Dmitry
>>> _______________________________________________
>>> users mailing list
>>> users(a)xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/users
>
>
>
> Kind regards,
>
> Dmitry
---------- Forwarded message ----------
From: Dmitry Bakbardin <haru_mamburu(a)mail.ru>
Date: Wed, Apr 2, 2014 at 2:03 PM
Subject: Re[2]: [xwiki-users] SearchSuggest parameters in a new syntax
gives different behaviour
To: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
Hi, Marius!
See below.
Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com>:
On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
> Hi Dmitry,
>
> On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin <haru_mamburu(a)mail.ru> wrote:
>> Hi, all!
>>
>> 5.2 -> 5.4.3 Upgrade
>>
>> Xwiki.SearchSuggest objects were changed
>>
>> It was:
>> type:OBJECT AND (class:XWiki.BlogPostClass) AND objcontent:(__INPUT__*)
>>
>> It is:
>> fq=type:DOCUMENT
>> fq=class:Blog.BlogPostClass
>> qf=object.Blog.BlogPostClass
>>
>> The main difference:
>> - it was "__INPUT__*" query string and
>> - (as far as I understood) it is "__INPUT__" if parameter "q" is omitted
>>
>> The result is Solr Suggest changes it's behaviour and gives only exact results.
>> To make Search Suggest running as it was, we have to add: "q=__INPUT__*"
>>
>
>> Is it done by puprpose or it is a bug and I have to "jira" it?
>
> On purpose. I did it as part of
> http://jira.xwiki.org/browse/XWIKI-10051 (check the documentation
> links). The reason I dropped the * (star) is because:
>
> (1) Prefix matching is costly
If Search Suggest is too costly, we can turn it off completely :)
> (2) The search suggest is not a filter (in the sense that you have a
> list of item and you type some text and it filters the items starting
> with that text). Search is more complex. The search text is analysed,
> stop words are removed, etc.
(3) It was a fake prefix matching, because if you typed more words,
only the last word was matched as prefix (not the entire text). All
the other were analysed.
IMHO, suggest means we prefer suggest more than exact search results.
What I mean, that all languages wich have declensioin are too
sensitive to the __INPUT__* search.
Usual use case for such a search is: you enter root of the word and
get back suggest of ALL forms of the word.
Even in English, which is much less "declensionable", singular and
plural is the case.
E.g. "wiki" input will give only exact much and won't show "wikis".
Thus, it makes Solr Sugges much less relevant.
>
> As you said, you can get back the previous behaviour using "q=__INPUT__*"
Yes, it was the firs I did, 'cause nearly to all my search strings
Solr gave me "no results". It wasn't so "severe" before the upgrade.
:)
IMHO, it's better to leave "__INPUT__*" in default settings and amend
documentation with performance/relevancy issues tricks for Solr
Suggest tuning. "*" would be useful for most use cases, and would make
Suggest effective, especially for new users who start playing with
XWike.
I do agree, that in the high load projects it could be essential to
tweak default behaviour or turn it off at all.
>
> Let me know what yo think,
> Marius
>
>
>
>>
>>
>> Kind regards,
>>
>> Dmitry
>> _______________________________________________
>> users mailing list
>> users(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
Kind regards,
Dmitry
Hi all,
I have followed information given here http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration in order to customize my PDF export (via its CSS).
I succeeded in doing all I wanted, except concerning the table of content: I can’t customize it because I don’t know which component is used to display it (neither <p>, nor <ul>…).
Could you help me please? I would change the font used to display it.
For information I’ve tried to setup the font-family defined for the whole document with
body { font-family: 'Helvetica Neue LT Com’; }
but it crashes at PDF generation time (please see below).
Thanks by advance!
Nicolas
Error number 11015 in 11: Exception while exporting
com.xpn.xwiki.XWikiException: Error number 11015 in 11: Exception while exporting
at com.xpn.xwiki.web.ExportAction.render(ExportAction.java:82)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:294)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:129)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:121)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:126)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:66)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:208)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:111)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:744)
Caused by: com.xpn.xwiki.XWikiException: Error number 12002 in 12: Exception while exporting pdf
at com.xpn.xwiki.pdf.impl.PdfExportImpl.createException(PdfExportImpl.java:569)
at com.xpn.xwiki.pdf.impl.PdfExportImpl.renderXSLFO(PdfExportImpl.java:343)
at com.xpn.xwiki.pdf.impl.PdfExportImpl.exportXHTML(PdfExportImpl.java:271)
at com.xpn.xwiki.pdf.impl.PdfExportImpl.exportHtml(PdfExportImpl.java:224)
at com.xpn.xwiki.pdf.impl.PdfExportImpl.export(PdfExportImpl.java:210)
at com.xpn.xwiki.web.ExportAction.export(ExportAction.java:223)
at com.xpn.xwiki.web.ExportAction.render(ExportAction.java:79)
... 35 more
Caused by: javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: "{http://www.w3.org/1999/XSL/Format}block" is not a valid child of "fo:root"! (See position 1:1604)
at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:502)
at com.xpn.xwiki.pdf.impl.PdfExportImpl.renderXSLFO(PdfExportImpl.java:327)
... 40 more
Caused by: org.apache.fop.fo.ValidationException: "{http://www.w3.org/1999/XSL/Format}block" is not a valid child of "fo:root"! (See position 1:1604)
at org.apache.fop.events.ValidationExceptionFactory.createException(ValidationExceptionFactory.java:38)
at org.apache.fop.events.EventExceptionManager.throwException(EventExceptionManager.java:54)
at org.apache.fop.events.DefaultEventBroadcaster$1.invoke(DefaultEventBroadcaster.java:175)
at com.sun.proxy.$Proxy60.invalidChild(Unknown Source)
at org.apache.fop.fo.FONode.invalidChildError(FONode.java:534)
at org.apache.fop.fo.FONode.invalidChildError(FONode.java:517)
at org.apache.fop.fo.pagination.Root.validateChildNode(Root.java:133)
at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:267)
at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:171)
at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
... 41 more
Good Morning,
Anyone is using the extension Just Map It? I have checked the site and it apparently is offline!
Thank you
Danilo
Grupo Energisa
Danilo Oliveira
Analista Suporte Aplicacao TI - DPTO CORP. DE INFRAESTR. TI
e-mail: danilo.oliveira(a)energisa.com.br | tel: (32) 3429-6342 | cel: (32) 8452-9478
Esta mensagem contém informação confidencial. Se você a recebeu por engano, não divulgue ou copie seu conteúdo. Por favor, avise ao remetente imediatamente e apague-a do computador.
Privileged and confidential. If this message has been received by mistake, do not disclose or copy its contents. Please notify sender and delete immediately.
Hello
I tested newsletter extension 1.0.1 on xwiki 5.4.2 and 6.0RC1.
http://extensions.xwiki.org/xwiki/bin/view/Extension/Newsletter+Application
I followed the instruction, create instance but the scheduler doesn't send mail at users...
(My user subscribe at my newsletter and xwiki.mailsender.sendHtmlMessage work well)
On Xwiki 5.4.2 the scheduler doesn't lauch my test job but on 6.0RC1, the scheduler work well with this test job.
Then, I copy/paste newsletter job code on another page (between {{groovy}}{{/groovy}} and I obtain a lot of errors:
<<Failed to execute the [groovy] macro
org.xwiki.rendering.macro.MacroExecutionException: Failed to evaluate Script Macro for content [
etc...>>
Any ideas of this problem?
thxs
Pascal B
Hello all,
I'll perform an XWiki upgrade of myxwiki.org farm from 5.2 to 5.4.4, to
prevent it from crashing again.
It'll start today at 12:30 CEST (GMT+2) and shouldn't take more than two
hours.
Thank you for your understanding.
Guillaume
Hello,
I used the Menu Application [1] to define a horizontal menu, after page
header, and it's very nice and very user-friendly.
I wonder if it could (easily) be feasible, to have the content ("Menu
Structure") of the menu rendered ? My point would be to put some velocity
scripting in it, to achieve more dynamic menus (display parts depending on
user rights, generate some lists of items, etc).
A bit like the jsx/ssx extensions do.
I had a look but I didn't find where the "magic" operates :)
Thanks,
Jeremie
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Menu+Application
Hi Developers,
i have been trying this the whole time already and decided to ask for help.
I want to create a space, a group and add a member to the group. The space
should only be viewed by this group.
Here is my code till now. The Space is created, the group too and the user
login in is added to the group. I can't figure how to assign the rights.
The CODE:
protected void addUserToGroup(String xwikiname, XWikiContext context)
throws XWikiException{
//
// Create a group and add the user to the newly created group.
BaseClass groupClass = context.getWiki().getGroupClass(context);
// Get document representing group
DocumentReference groupDocumentReference = new DocumentReference(
context.getDatabase(), "myspace",
"Testgroup");
XWikiDocument groupDoc = context.getWiki().getDocument(
groupDocumentReference, context);
BaseClass rightsClass = context.getWiki().getRightsClass(context);
if (groupDoc.isNew()) {
log.error("Creating Test group");
synchronized (groupDoc) {
// Add a member object to document
BaseObject memberObj = groupDoc.newXObject(
groupClass.getDocumentReference(), context);
memberObj.setStringValue("member", xwikiname);
BaseObject rights=
groupDoc.newXObject(rightsClass.getDocumentReference(),context);
rights.setStringValue("groups", "Testgroup");
rights.setStringValue("levels","view");
rights.setStringValue("levels", "edit");
rights.setStringValue("users", "");
rights.setIntValue("allow",1);
//groupDoc.getObject("XWiki.XWikiGlobalRights");
groupDoc.setSyntax(Syntax.XWIKI_2_1);
groupDoc.setContent("{{include
document='XWiki.XWikiGroupSheet' /}}");
// Save modifications
context.getWiki().saveDocument(groupDoc, context);
}
log.error("Added user"+ xwikiname +"to Testgroup");
}
}
Thanks for any help.