Hello everyone, After one month, I finally got another big patch (just attached that to the TUSCANY-2552).
Here are some improvements: - the ability to remove and update contributions on the search index was added to the domains search component, but it's still not integrated with the domain manager, I plan to do it this week, should be quick :) - it's possible now to specify where the search index is stored. If it's not specified the search index is held on memory and is gone when the component instance terminates. The user can specify where it is gonna be stored by specifying a property when declaring the domain search component. - added some icons to the search results, so the user can easily differ between the result types. There is a icon for artifact, component and composite. I still want to find out a good one for contribution, any idea? - after some testings, I limited the type of artifacts indexed. They were too many and the results were not so useful with so many indexed artifact. I limited it right now to only .composite and .xml artifact, I will extend it to .wsdl, .bpel, .componentType, .wsdl and .xsd. Any other missing? - Improved the highlighting and how text fragments are presented - when the user queries without specifying a field, it search through all the fields but "parent" - the ability to download artifact, contribution jars and composite files from the results Problems: 1- there is a problem I have seen for a while but just ignored so far, when the results are too long, as I'm using atom binding to send the results back to the html javascript, the result get truncated when it's too long. Should I be using another binding? 2- another problem which is probably related to the atom binding is it seems to not support some special characters. As I'm reading data from documents and indexing it, some strange character might get indexed, and there are some characters which causes some problem with the atom binding. Right now, as a workaround I'm removing every char in my results which is under 40, but I should probably be enconding that. What should I do? Is there any way to encode it, using some kind of escaper or should a switch to another binding technology? 3- this is the last one that I hit this week, when I return the search results to the search-gadget webpage, it's html, and some part of it contains javascript calls to functions declared on search-gadget. However, the functions are not found when the browser tries to execute it, it says the function is not declared. Here is exactly what happens: there is a search.html which contains a iframe that loads search-gadget.html, search-gadget.html has a javascript function called getHighlighted(). When the user searches for something, the results are just html which is loaded into a div in search-gadget.html. This new result html loaded into this div contains a html component that calls getHighighlighted() when clicked, but this function is not found :(...any clue? Next steps: - finish full highlighted artifact display, problem 3 is blocking it - update the search index when a contribution is added, updated or deleted from domain manager - find a good icon for contribution, need ideas for that - add a quick search field to the toolbar Suggestions? Regards, Phillipe Ramalho On Sat, Jul 4, 2009 at 9:19 PM, Phillipe Ramalho <[email protected] > wrote: > Hi, > I just submitted a patch that contains all the search functionality > implemented. It includes query parsing, query execution and results > processing. The results are returned in objects that allow the user to > easily access the results based on how they are related in the domain. The > results may be highlighted or not, there is a argument to specify that. > > Next steps: > > -Allow the user to specify where the search index will be persisted, > preferably using component properties. > > -Finish how the domain manager displays the search results. > > Suggestions? > > Phillipe Ramalho > > On Sat, Jun 6, 2009 at 2:28 AM, Adriano Crestani < > [email protected]> wrote: > >> Hi Phillipe, >> >> Next step is to define how the user will use the Search component to >> execute the search query and what will be returned to the user. It may >> return Lucene Document objects, which are the raw results of a Lucene query. >> Or it may return more specific objects, which represent all the domain >> artifacts included in the results, containing all the relationships, text >> highlighting, etc. I prefer the second option, this way the Search component >> users will not need to know how to deal with Lucene Document objects. >> >> Yes, I agree it's not cool to return Lucene Document objects to the >> component user. It might also return too much info, mainly if you store the >> documents on the Document object, this way you will slow down the >> communication between the component and the user. So, lets keep it simple >> and only return the necessary information ; ) >> >> Best Regards, >> Adriano Crestani Campos >> >> >> On Thu, Jun 4, 2009 at 10:05 PM, Phillipe Ramalho < >> [email protected]> wrote: >> >>> Hi, >>> I was finally able to figure out how to add the new domain search project >>> to the maven and make it dependent of lucene-core library. It seems to be >>> working fine, so I created a patch and attached it to JIRA TUSCANY-2552 [1]. >>> The code is not integrated to domain manager yet, there is a lot of work >>> remaining yet, I will send more patches along my progress. >>> >>> Phillipe Ramalho >>> >>> [1] - http://issues.apache.org/jira/browse/TUSCANY-2552 >>> >>> >>> On Sun, May 31, 2009 at 1:28 AM, Phillipe Ramalho < >>> [email protected]> wrote: >>> >>>> Hi, >>>> These last weeks I have set my dev environment up and started coding >>>> some indexing code. >>>> >>>> My first challenge was to figure out what the user will provide the data >>>> about the SCA Domain to the Search component, so the Search component can >>>> analyze this data and index the relevant information. After some research >>>> and help from Luciano and Adriano I think the best way to collect this >>>> information is from a Contribution object. >>>> >>>> I already did some coding that introspect a Contribution object and >>>> extract the necessary information like components and their references and >>>> services, composites, contribution files, etc. Each one is indexed as a >>>> different document in the Lucene index. >>>> >>>> Next step is to define how the user will use the Search component to >>>> execute the search query and what will be returned to the user. It may >>>> return Lucene Document objects, which are the raw results of a Lucene >>>> query. >>>> Or it may return more specific objects, which represent all the domain >>>> artifacts included in the results, containing all the relationships, text >>>> highlighting, etc. I prefer the second option, this way the Search >>>> component >>>> users will not need to know how to deal with Lucene Document objects. >>>> >>>> I'm intending to send the first patch as soon as possible, I just need >>>> to integrate the new Search component module with maven. >>>> >>>> Regards, >>>> Phillipe Ramalho >>>> >>> >>> >>> >>> -- >>> Phillipe Ramalho >>> >> >> > > > -- > Phillipe Ramalho > -- Phillipe Ramalho
