Re: [xwiki-devs] The problem with the rest services for autosuggestion.

2011/7/27 Marius Dumitru Florea<mariusdumitru.florea(a)xwiki.com> > On 07/27/2011 12:24 PM, 许凌志(Jamesxu) wrote: >> I found that if there is no input for lucene query, no results will be >> returned. But In link suggestion, when user first type "[[", there is

>> queries, so no suggestions will be got, but Marius and I excepted there > is a >> default suggestion results for users, like the recent modified pages,

>> the attachments belong to the current edited pages if exists. >> >> Marius give me wiki page: Panels.Recently Modified, there is an page > object >> for getting the Recently Modeified pages. I have tried to enhance this >> object so that it can return json results which can be used as a web >> service, so I edit the content of the object of this page, the code is >> below: >> {{velocity}} >> *#set($media = "$!request.media")* >> #set ($recentlyModified = $xwiki.searchDocuments('where 1=1 order by >> doc.date desc', 5, 0)) >> #if ($recentlyModified.size()> 0 || $showEmptyPanels) >> *#if($media == 'json') >> $response.setContentType("application/json") >> {'test':'mytest'}* >> #else >> #panelheader($msg.get('panels.recentlyModified.title')) >> #foreach ($docname in $recentlyModified) >> #if ($xwiki.hasAccessLevel('view', $xcontext.getUser(),

>> #set ($rdoc = > $xwiki.getDocument($docname).getTranslatedDocument()) >> #if ($foreach.index> 0) >> (% class="pitemseparator" %) ~| (%%)## >> #end >> (% class="panelitem" %)[[$rdoc.plainTitle>>$rdoc]](%%)## >> #end >> #end >> #end >> #panelfooter() >> #end >> {{/velocity}} >> >> as you can see, I add an parameter named "media", if the media is json, > then >> return the json file, otherwise the default behaviour will be executed.

>> tested the code above, and the json result is not

Yes, I have tried the url:

but still can't get the right result.

> > Hope this helps, > Marius > >> >> On Tue, Jul 26, 2011 at 3:57 PM, Sergiu Dumitriu<sergiu(a)xwiki.com> > wrote: >> >>> >>> >>> On 07/25/2011 05:08 AM, 许凌志(Jamesxu) wrote: >>>> Hi All, how can I query the attachments of a specific page, for

>>>> "Main.testpage" >>>> >>>> I found if I use the query >>>> space:Main AND filename:__INPUT__* AND type:attachment >>>> I can get the attachments only from the Main space. >>>> >>>> but how about a specific page, I have tried >>>> page:Main.testpage AND filename:__INPUT__* AND type:attachment >>>> wikipage:Main.testpage AND filename:__INPUT__* AND type:attachment >>>> but no one can give the right results. >>> >>> To see which fields are indexed, you can look at the Java sources, >>> starting from >>> >>> >

>>> >>> The document name is indexed both as "name", which holds just the

>>> without the space, and "fullname", which contains the space as well -- >>> Space.Document >>> >>>> On Wed, Jul 20, 2011 at 5:56 PM, Eduard Moraru<enygma2002(a)gmail.com> >>> wrote: >>>> >>>>> Hi James, >>>>> >>>>> That's just a query problem. The queries that are used for the

>>>>> suggest are located in XWiki.SearchSuggestConfig. The query for > Document >>>>> Name/Content are not complete. They also need to specify that the > result >>>>> should be a document, and not anything (like attachments for > instance). >>> The >>>>> correct query for searching for documents by document name should

>>>>> >>>>> name:__INPUT__* AND type:wikipage >>>>> >>>>> For attachment name, the correct query should be: >>>>> >>>>> filename:__INPUT__* AND type:attachment >>>>> >>>>> So, for your usecase (quering documents by name or attachments by > name), >>>>> the >>>>> query should be: >>>>> >>>>> (filename:__INPUT__* AND type:attachment) OR (name:__INPUT__* AND >>>>> type:wikipage) >>>>> >>>>> I`ve tested it out by creating a page named "IconTest" and then >>> searching >>>>> for "icon". The results were: >>>>> >>>>> <results> >>>>> <rs id="/xwiki/bin/download/XWiki/RequestsStatus/icon.png" >>>>> info="XWiki.RequestsStatus">icon.png</rs> >>>>> <rs id="/xwiki/bin/download/XWiki/ExtensionManager/icon.png" >>>>> info="XWiki.ExtensionManager">icon.png</rs> >>>>> <rs id="/xwiki/bin/download/Panels/PanelWizard/icon.png" >>>>> info="Panels.PanelWizard">icon.png</rs> >>>>> <rs id="/xwiki/bin/download/XWiki/OfficeImporterAdmin/icon.png" >>>>> info="XWiki.OfficeImporterAdmin">icon.png</rs> >>>>> <rs id="/xwiki/bin/download/XWiki/SearchAdmin/icon.png" >>>>> info="XWiki.SearchAdmin">icon.png</rs> >>>>> <rs id="/xwiki/bin/download/Blog/Categories/icon.png" >>>>> info="Blog.Categories">icon.png</rs> <----------- >>> attachments >>>>> <rs id="/xwiki/bin/view/Main/IconTest" >>>>> info="Main.IconTest">IconTest</rs> <----------- > documents >>>>> </results> >>>>> >>>>> Ignore the fact that the result is in XML, you can make it json, as >>>>> suggested in my previous mail. >>>>> >>>>> Hope that works for you. >>>>> >>>>> Thanks, >>>>> Eduard >>>>> >>>>> 2011/7/20 许凌志(Jamesxu)&lt;lingzhixu326(a)gmail.com&gt; >>>>> >>>>>> Thanks Eduard very much, It is really helpful, today I am trying to > use >>>>>> SuggestLuceneService to test the autosuggestion functions, I found

>>>>>> problem. >>>>>> >>>>>> For example, I create a page named "jamesxu", and upload an > attachment >>>>>> named >>>>>> "autosuggest1.js", then I input the query "jame" to the search box

>>> the >>>>>> top right of the page, the suggestion list shows up, but the

> in >>>>> the >>>>>> "Document Name" and "Document Content" contains both the wiki page >>>>>> "jamesxu" >>>>>> and its attachment "autosuggest1.js", this behaviour is not

> in >>>>> the >>>>>> autosuggestion features of the editor, because when user types > "jame“， >>> he >>>>>> really wants to query the wiki page or attachment begin with or >>> contains >>>>>> "jame", the attachment "autosuggest1.js" does not contains "jame", > it >>>>>> should not be included in the suggestion results. >>>>>> >>>>>> On Tue, Jul 19, 2011 at 10:14 PM, Eduard Moraru<

>>>>>>> wrote: >>>>>> >>>>>>> Hi James, >>>>>>> >>>>>>> I agree with Marius that you should reuse as much as possible what >>>>>> already >>>>>>> exists instead of creating an alternate service that does, in a > great >>>>>>> proportions, the same as an existing one but has one extra

>>>>>>> >>>>>>> So, as I was browsing trough REST's resources, I noticed an >>>>> undocumented >>>>>>> "/wikis/{wikiName}/attachments" [1] resource at the wiki level

> is >>>>>> able >>>>>>> to search for attachments. As you can see from the method's > signature, >>>>> it >>>>>>> accepts parameters to filter your search by attachment name, page, >>>>> space, >>>>>>> author, and type. I will fix the REST API documentation and

>>> it. >>>>>>> >>>>>>> This resource should do the trick for what you need, used in >>>>> conjunction >>>>>>> with the search resource that should handle documents. >>>>>>> >>>>>>> The advantage of this is that you can get json, as you did for the >>>>> search >>>>>>> resource. >>>>>>> The disadvantage of the whole REST API, for your needs, might be > that >>>>> it >>>>>> is >>>>>>> limited at wiki level and can not perform a multi-wiki search in

>>>>>> query >>>>>>> (wihout you having to do a search for each wiki). >>>>>>> >>>>>>> On the other side, the Lucene search does not have this problem >>> because >>>>>> it >>>>>>> indexes all the wikis and can perform searches on all wikis in one >>>>> query >>>>>>> and >>>>>>> it does it much faster than REST (which uses database queries). > Also, >>>>>>> lucene >>>>>>> is used in the search suggest (the one at the top-right corner of > the >>>>>>> screen) and in the main XWiki search as well, so it would be much >>>>> better >>>>>> if >>>>>>> the results were consistent. Besides this, if the lucene system is >>>>>> improved >>>>>>> over time, your results will also be improved as a result. >>>>>>> >>>>>>> So my suggestion is that you modify XWiki.SuggestLuceneService and >>> make >>>>>> it >>>>>>> accept a "media" parameter (or something similar) that should

>>> at >>>>>>> least 2 values: "xml"(default) and "json". Based on this value,

>>> can >>>>>>> wrap >>>>>>> the results of the lucene search into a basic json structure that > you >>>>> can >>>>>>> easily use in your suggest box. You can check [2][3] and [4] for >>>>>> references >>>>>>> of how to use Lucene search in XWiki. >>>>>>> Once you are done with it, you can even do a pull request so that > this >>>>>>> feature gets integrated into XWiki. >>>>>>> >>>>>>> The best and cleanest solution would be that the REST search > resource >>>>>> used >>>>>>> internally lucene instead of a custom database query and that

>>>>> would >>>>>>> be >>>>>>> a single search back-end (preferably configurable in > administration). >>>>>>> Anyway, it's not your job to fix XWiki :) so making >>>>>>> XWiki.SuggestLuceneService return json too is the best way to go > right >>>>>> now, >>>>>>> IMO. >>>>>>> >>>>>>> Thanks, >>>>>>> Eduard >>>>>>> >>>>>>> ----------------- >>>>>>> References: >>>>>>> [1] >>>>>>> >>>>>>> >>>>>> >>>>> >>> >

>>>>>>> [2] >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Lucene+Plugin >>>>>>> [3] >>>>>>> >>>>>>> >>>>>> >>>>> >>> >

>>>>>>> [4] >>>>>>> >>>>>>> >>>>>> >>>>> >>> >

>>>>>>> >>>>>>> >>>>>>> On Tue, Jul 19, 2011 at 8:36 AM, 许凌志(Jamesxu)< > lingzhixu326(a)gmail.com >>>>>>>> wrote: >>>>>>> >>>>>>>> Hi, these days I need to implement the rest services for getting >>>>>>> suggestion >>>>>>>> results for link autosuggestion. In my design, I think the > suggestion >>>>>>>> results should be filtered and ranked by the following

>>>>>>>> (for example user types "[[mytest" in page "xwiki:main.newpage") >>>>>>>> First [[ is triggered, when user keep typing, the page and > attachment >>>>>>>> suggestion results should be filtered and ranked by the following >>>>>> rules: >>>>>>>> 1. Prefix matched (only for page name and attachment name) >>>>>>>> - The pages which are in the same wiki and space of the > document >>>>>>> current >>>>>>>> edited.( Prior A) >>>>>>>> - The pages which are in the same wiki but different space

> the >>>>>>>> document current edited;(Prior B) >>>>>>>> - The pages which are in different wiki and different space

> the >>>>>>>> document current edited; (Prior C); >>>>>>>> 2. Partial matched (only for page name and attachment name) >>>>>>>> - The pages which are in the same wiki and space of the > document >>>>>>> current >>>>>>>> edited.( Prior C) >>>>>>>> - The pages which are in the same wiki but different space

> the >>>>>>>> document current edited;(Prior D) >>>>>>>> - The pages which are in different wiki and different space

> the >>>>>>>> document current edited; (Prior E) >>>>>>>> 3. If no page and attachment matches the above two rules, the >>>>>> suggestion >>>>>>>> box will be disappeared.(eclipse way) >>>>>>>> >>>>>>>> However, sometimes user might insert the space name too, for > example, >>>>>>> user >>>>>>>> will type "[[Main", following the rule 1 and rule 2, the pages > begins >>>>>>> with >>>>>>>> "Main" will be first retrieved as the suggestion results untill > user >>>>>>> types >>>>>>>> "." after "Main", the suggestion result will be retreved from the >>>>> pages >>>>>>>> under the space "Main" only. Filters still obey the above three >>>>> rules. >>>>>>>> And also when user types "attach:", the suggestion result will be >>>>>>> retrieved >>>>>>>> the attachments only following the above three rules. >>>>>>>> And if the link is under the attachment context, when "@" is

>>>>> the >>>>>>>> attachments only will be retrieved following the above three

>>>>>>>> >>>>>>>> In order to do this, I investigated the rest services already >>>>> existed( >>>>>>>>

> ), >>>>>> but >>>>>>> I >>>>>>>> found none is perfect suitable for my needs. So I talk with

>>>>> he >>>>>>>> suggested me to use the existed services which are closed to my > needs >>>>>>>> first, >>>>>>>> and then write the perfect one later. >>>>>>>> >>>>>>>> However, I only found the rest service:/wikis/{wiki}/search is

>>>>>> most >>>>>>>> closed one for the pages suggestion to my needs, there is no >>>>> attachment >>>>>>>> search rest service for attachment suggestion, Marius adviced me

>>>>> use >>>>>> " >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >

> < >

>> >>> < >>> >

>>>> >>>>> < >>>>> >>> >

>>>>>> >>>>>> < >>>>>> >>>>> >>> >

>>>>>>> >>>>>>> < >>>>>>> >>>>>> >>>>> >>> >

>>>>>>>> >>>>>>>> " >>>>>>>> instead, but I found the search result is in xml format(not