xwiki-users April 2014

xwiki-users@xwiki.org

44 participants
76 discussions

[xwiki-users] weblogic and xwiki vfs error

by Brockmeier, Chris S

Hey All, I'm having an issue deploying the xwiki.war into my weblogic container. I am getting a "Cannot create vfs.dir for URL [zipfile:/x/y/z] I saw a posting about this in the reflections project http://code.google.com/p/reflections/issues/detail?id=124&can=1&q=weblogic but was curious as to if anyone else out there had got around this issue? Thanks, Chris

10 years, 7 months

Re: [xwiki-users] Remove activity stream from Tag pages

by MUNOZ, Fabien (DIMENSION DATA FRANCE)

Thanks a lot. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

10 years, 7 months

[xwiki-users] Remove activity stream from Tag pages

by MUNOZ, Fabien (DIMENSION DATA FRANCE)

Hello, How can I remove the activity stream widget from tags pages? I use the default skin, fresh install with last version of Xwiki. Thanks in advance, F The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

10 years, 7 months

[xwiki-users] What is path for icons?

by Bill Vlahos

I changed the hostname of the wiki and the icons no longer appear. Where is that path stored so I can modify it to the new root? XWIKI Enterprise 5.3 Bill Vlahos

10 years, 7 months

[xwiki-users] JsTree Extension

by Danilo Amaral de Oliveira

Hello People, I am trying to customize the jsTree extension because I want to show just the tree of a specific space that arenot blog posts. I have changed the query to avoid to show the posts and it is working well. Ok. I have start to understand the code and I have changed two parts in the code to show just a space: var parsedJson = JSON.parse(data, function (k, v) and $.each(parsedJson, function (i, item) { You can check the code here: http://codeshare.io/sXGil As you can see here: http://www.image-share.com/ipng-2529-45.html I could filter the spaces, however the containers and icons of the other folder still are showing in my page... I don’t know very much of javascript and I don’t know where to attack now, do you have some tip what functions I need to modify? 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.

10 years, 7 months

[xwiki-users] Polemic Security Question

by Danilo Amaral de Oliveira

Hello Community, I would like to do a polemic question... Do you think that is possible to deny the function of PrintScreen on the XWiki application? Thanks 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.

10 years, 8 months

[xwiki-users] launch scheduled job and flamengo skin with table

by Pascal BASTIEN

10 years, 8 months

[xwiki-users] Fwd: ZipExplore

by Saulo S. Bravim

Hi; I'm using the zipexplore to find items in a file that is 20mb, but is experiencing the below error: org.xwiki.rendering.macro.MacroExecutionException: Failed to evaluate Velocity Macro for content [#set($attachment="Contratos.zip") #set($plugin=$xwiki.zipexplorer) #foreach($file in $plugin.getFileTreeList($doc, $attachment)) * [[$file.id>>path:$plugin.getFileLink($doc, $attachment, $file.id)]] #end] at org.xwiki.rendering.internal.macro.velocity.VelocityMacro.evaluateString(VelocityMacro.java:131) at org.xwiki.rendering.internal.macro.velocity.VelocityMacro.evaluateString(VelocityMacro.java:50) at org.xwiki.rendering.macro.script.AbstractScriptMacro.evaluateBlock(AbstractScriptMacro.java:302) at org.xwiki.rendering.macro.script.AbstractScriptMacro.execute(AbstractScriptMacro.java:198) at org.xwiki.rendering.macro.script.AbstractScriptMacro.execute(AbstractScriptMacro.java:59) at org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transformOnce(MacroTransformation.java:191) at org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transform(MacroTransformation.java:132) at org.xwiki.rendering.internal.transformation.DefaultTransformationManager.performTransformations(DefaultTransformationManager.java:87) at org.xwiki.display.internal.DocumentContentDisplayer.display(DocumentContentDisplayer.java:252) at org.xwiki.display.internal.DocumentContentDisplayer.display(DocumentContentDisplayer.java:125) at org.xwiki.display.internal.DocumentContentDisplayer.display(DocumentContentDisplayer.java:55) at org.xwiki.display.internal.DefaultDocumentDisplayer.display(DefaultDocumentDisplayer.java:80) at org.xwiki.display.internal.DefaultDocumentDisplayer.display(DefaultDocumentDisplayer.java:38) at org.xwiki.sheet.internal.SheetDocumentDisplayer.display(SheetDocumentDisplayer.java:113) at org.xwiki.sheet.internal.SheetDocumentDisplayer.display(SheetDocumentDisplayer.java:50) at org.xwiki.display.internal.ConfiguredDocumentDisplayer.display(ConfiguredDocumentDisplayer.java:67) at org.xwiki.display.internal.ConfiguredDocumentDisplayer.display(ConfiguredDocumentDisplayer.java:41) at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:997) at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:976) at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:1007) at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:619) at sun.reflect.GeneratedMethodAccessor422.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567) at org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71) at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:228) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:187) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:105) at com.xpn.xwiki.internal.template.DefaultPrivilegedTemplateRenderer.evaluate(DefaultPrivilegedTemplateRenderer.java:125) at com.xpn.xwiki.internal.template.DefaultPrivilegedTemplateRenderer.evaluateTemplate(DefaultPrivilegedTemplateRenderer.java:75) at com.xpn.xwiki.XWiki.evaluateTemplate(XWiki.java:1687) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1627) at com.xpn.xwiki.api.XWiki.parseTemplate(XWiki.java:918) at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:369) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:216) at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:311) at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:228) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:187) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:105) at com.xpn.xwiki.internal.template.DefaultPrivilegedTemplateRenderer.evaluate(DefaultPrivilegedTemplateRenderer.java:125) at com.xpn.xwiki.internal.template.DefaultPrivilegedTemplateRenderer.evaluateTemplate(DefaultPrivilegedTemplateRenderer.java:75) at com.xpn.xwiki.XWiki.evaluateTemplate(XWiki.java:1687) at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:166) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:304) 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.doGet(ActionServlet.java:449) at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:121) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:126) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:66) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:208) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:111) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at com.googlecode.psiprobe.Tomcat70AgentValve.invoke(Tomcat70AgentValve.java:38) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Caused by: org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id [xwiki:Sigor Contratos.Artefatos] at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:247) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:187) at org.xwiki.rendering.internal.macro.velocity.VelocityMacro.evaluateString(VelocityMacro.java:124) ... 108 more Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getFileTreeList' in class com.xpn.xwiki.plugin.zipexplorer.ZipExplorerPluginAPI threw exception java.lang.IllegalArgumentException at xwiki:Sigor Contratos.Artefatos[line 3, column 27] at org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:243) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:187) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567) at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:318) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:228) ... 110 more Caused by: java.lang.IllegalArgumentException at java.util.zip.ZipInputStream.getUTF8String(ZipInputStream.java:324) at java.util.zip.ZipInputStream.readLOC(ZipInputStream.java:264) at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:91) at com.xpn.xwiki.plugin.zipexplorer.ZipExplorerPlugin.getFileList(ZipExplorerPlugin.java:185) at com.xpn.xwiki.plugin.zipexplorer.ZipExplorerPlugin.getFileTreeList(ZipExplorerPlugin.java:219) at com.xpn.xwiki.plugin.zipexplorer.ZipExplorerPluginAPI.getFileTreeList(ZipExplorerPluginAPI.java:108) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173) ... 116 more When the file is less than 3mb works, anyone know how I can get it working in 20mb file? tks

10 years, 8 months

[xwiki-users] Fwd: Re[4]: SearchSuggest parameters in a new syntax gives different behaviour

by Marius Dumitru Florea

---------- Forwarded message ---------- From: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> Date: Wed, Apr 23, 2014 at 7:23 PM Subject: Re: Re[4]: [xwiki-users] SearchSuggest parameters in a new syntax gives different behaviour To: Dmitry Bakbardin <haru_mamburu(a)mail.ru> No other opinions on this? What do you prefer for search suggest (live search)? prefix matching or full text analysis? Thanks, Marius On Fri, Apr 4, 2014 at 2:19 AM, Dmitry Bakbardin <haru_mamburu(a)mail.ru> wrote: > Hi, Marius! > > See below. > > > Thu, 3 Apr 2014 18:03:50 +0300 от Marius Dumitru Florea > <mariusdumitru.florea(a)xwiki.com>: > > 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". > > > In my use case: > - Default language is Russian > - Search needed for comments > > I didn't find any other solution, besides "__INPUT__*" search. > > > >> >> >>> >>> 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 XWiki. > >> 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)? > > Prefix is more flexible from search point of view. But, sure it would be > interesting to carry out a survey. > > > > > 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. > > IMHO, for Search - yes all words are essential, for suggest, most probably > prefix. It is my way of searching. :) > > > > > 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 > > > > Kind regards, > > Dmitry

10 years, 8 months

[xwiki-users] Fwd: Re[4]: SearchSuggest parameters in a new syntax gives different behaviour

by Marius Dumitru Florea

---------- Forwarded message ---------- From: Dmitry Bakbardin <haru_mamburu(a)mail.ru> Date: Fri, Apr 4, 2014 at 2:19 AM Subject: Re[4]: [xwiki-users] SearchSuggest parameters in a new syntax gives different behaviour To: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> Hi, Marius! See below. Thu, 3 Apr 2014 18:03:50 +0300 от Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>: 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". In my use case: - Default language is Russian - Search needed for comments I didn't find any other solution, besides "__INPUT__*" search. > > >> >> 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 XWiki. > 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)? Prefix is more flexible from search point of view. But, sure it would be interesting to carry out a survey. 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. IMHO, for Search - yes all words are essential, for suggest, most probably prefix. It is my way of searching. :) 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 Kind regards, Dmitry

10 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-users April 2014