[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [Dltk-dev] problem with dltk-search
|
Thank you very much, this was very informative. If you could paste
exactly this text into the architecture or tutorial section for the
search it would be great for others as well :)
My ANTLR parsers produces classes that extend FieldDeclaration and
passes them to the ModuleDeclaration. These classes contain the
visit/endvisit Methods for the IElementRequestor. For example:
Scheme48InterfaceDeclaration.java:
@Override
public boolean visit(Stack<ASTNode> fNodes, IElementRequestor fRequestor) {
fNodes.push(this);
ISourceElementRequestor.FieldInfo fi = new
ISourceElementRequestor.FieldInfo();
fi.name = this.getName();
fi.modifiers = this.getModifiers();
fi.type = "interface";
fi.nameSourceStart = this.getNameStart();
fi.nameSourceEnd = this.getNameEnd() - 1;
fi.declarationStart = this.sourceStart();
fRequestor.enterField(fi);
return true;
}
@Override
public boolean endVisit(Stack<ASTNode> fNodes, IElementRequestor fRequestor) {
fRequestor.exitField(this.sourceEnd());
fNodes.pop();
return true;
}
This works well to build the content of the outlineview and to search
for interface-declarations now by using search-for "Field" and
"declarations". My source parser doesn't call IElementRequestor at all
(the PythonSourceParser doesn't either).
I managed to get my stuff partially working with your advice, but
there are still some issues .
When i doubleclick on an element in the outlineview, the selection of
the editor is set correctly to the name of the declaration. This is a
sign that the namestart and nameend fields are set correctly. However,
if i doubleclick on the search results the selection is not set
correctly, altough both systems are using the same information?
Another question would be: How do i implement own types of
Declarations independent from type/method/field declarations? I
figured that this would be very hard, since you have to implement own
Locator classes and extend PatternLocator to override the
patternLocator-Method. Am i right here?
thanks in advance,
Sebastian
2011/9/19 Andrey Sobolev <andrey.sobolev@xxxxxxxxx>:
> Hi Sebastian,
>
> Lets me start from few words about how DLTK search are work:
>
> DLTK are separated in two phases:
>
> 1) Indexing.
>
> In this phase IDE will fill all possible items into disk index.
> Default implementation fill index using structure parser results.
>
> So first you need to be sure all items are going into index.
>
> So please check calls to org.eclipse.dltk.compiler.IElementRequestor class
> from your source parser.
>
> Methods "enterField", "enterMethod", "enterType" and appropriate "exit*"
> methods should be called for declaration items.
> Be sure to call appropriate exit methods, for structure to be correct.
> And methods "acceptMethodReference", "acceptTypeReference",
> "acceptFieldReference" should be called for references.
>
> To check index file consistency you could query index directly using:
> import org.eclipse.dltk.core.search.indexing.*;
> import org.eclipse.dltk.core.*;
> import org.eclipse.dltk.core.search.*;
>
> IProject prj = ... ;
> IndexManager im = ModelManager.getModelManager().getIndexManager();
> Index idx = im.getIndex(prj.getFullPath()); // This is index file for
> project root
> // And then check using
> idx.queryDocumentNames(null);// To check all documents in this index
> // or
> char[][] category = {IIndexConstants.TYPE_DECL};
> idx.query(category, new char[]{'*'}, SearchPattern.R_PATTERN_MATCH);
>
> So before going deep you need to check indexes produced by your parser are
> correct.
>
> 2) Search. Find matches -> Provide search results.
> There is two ways to implement search.
> First is to use DLTK default implementation if you are using DLTK AST,
> it would be OK if your model fit well to:
> Module
> Type
> SubType
> Method
> Field
> Method
> Field
>
> And second is to provide custom IMatchLocator based implementation.
>
> So begin search:
> a) Search for matches
> On every search DLTK will query index for all possible matches and then use
> only required ones.
>
> Using standard MatchLocator
> b) Collect possible matches by using IMatchLocatorParser parser interface
> to process ModuleDeclaration into match'et nodes.
> Please look into
> org.eclipse.dltk.core.search.matching.MatchLocatorParser.parseBodies(ModuleDeclaration)
> method.
> It uses visitor pattern to visit ModuleDeclaration.
> From visitor it calls for
> org.eclipse.dltk.core.search.matching.PatternLocator.match(*) methods to
> match AST node.
> Please refer to FieldLocator, MethodLocator, TypeDeclarationLocator classes
> for appropriate match methods (not all methods are implemented).
>
> After matches are collected we use structure to match some of them to model
> elements, for easy navigation.
> c) Associate matched node to structure model items.
> To work correctly following methods should return correct results:
> ModuleDeclaration:
> - getTypes() - list of top level types in module
> - getFunctions() - list of methods in module
> - getVariables() - list of variables in module
> And TypeDeclaration
> - getTypes() - list of subtypes
> - getMethods() - list of methods
> - getVariables() - list of variables
> By default this methods are using ASTUtil.getTypes(), ASTUtil.getMethods(),
> ASTUtil.getVariables() methods.
> So if your ModuleDeclaration hold custom items you need to override
> provided methods to match nodes to correct structure model items.
>
> Using custom IMatchLocator
> - provide your results into
> org.eclipse.dltk.core.search.SearchRequestor.acceptSearchMatch(*) method
> from
> your IMatchLocator.locateMatches() method.
>
> PS:
> I've updated python example in DLKT cvs:
> org.eclipse.dltk/examples/eclipsecon08/org.eclipse.dltk.examples.python*
> To work with latest DLTK 3.0, and fix issues in search.
> a) PythonSourceElementRequestor is called method
> ISourceElementRequestor.enterMethodRemoveSame() but this methods are not
> implemented in search.
> So please check your code, probable this is reason for method declarations
> are not work for you.
> b) ExamplePythonMatchLocationParser has not passed FieldDeclarations into
> matched nodes, search for fields was not working in sample.
>
> Best regards,
> Andrei Sobolev.
>
>> For my ModuleDeclaration, i subclassed FieldDeclaration several times
>> and filled my ModuleDeclaration with these statements. I tried to
>> implement the search like mentioned in
>> http://wiki.eclipse.org/DLTK_IDE_Guide:Step_3._Towards_an_IDE#Search
>> but it doesn't find anything. I then implemented a subclass of
>> MatchLocatorParser as follows:
>>
>> @Override
>> protected void processStatement(final ASTNode node, final
>> PatternLocator locator) {
>> if (node instanceof MethodDeclaration) {
>> final MethodDeclaration defn = (MethodDeclaration)
>> node;
>> locator.match(defn, getNodeSet());
>> } else if (node instanceof FieldDeclaration) {
>> final FieldDeclaration def = (FieldDeclaration)
>> node;
>> locator.match(def, getNodeSet());
>> }
>> }
>>
>> when i do a method-search (search for "methods") with limit to
>> declarations he visits this method but doesn't match the right things
>> since they are FieldDeclarations (the locator just returns impossible
>> match). But when i do a field-search he doesn't visit this method at
>> all. Digging into the code, what i could find out is that in the
>> BasicSearchEngine in the findMatches method he doesn't find any
>> SearchDocuments (variables like indexMatches and matches are empty).
>> That doesn't happen in the method-search.
>> Any Ideas?
>>
>> thanks in advance,
>>
>
>
--
Sebastian Rheinnecker
Universität Tübingen
