Resolve Scope DOM across multiple files

Hi,

I am trying to specify the scope of a DomElement attribute to include searching external files.

For instance the file "firstBlueprint.xml" can have a reference to a BlueprintBean which has been defined within a different file "secondBlueprint.xml".

This is an example of the DomElement which I am currently dealing with. It works great, but only resolves references within the same file.

public interface Method extends DomElement {
    @Resolve
    @NameValue
    @Attribute("bean")
    GenericAttributeValue<BlueprintBean> getBeanReference();


I have tried making use of @Scope and providing a ScopeProvider implementation, but the method getScope only allows one DomElement to be returned.
I have also tried looking at the DomFileDescription methods, but these also have a similiar requirement of needing to return a single DomElement to resolve scope.

I believe I would like to be returning a List<DomElement>, which would point to the different root elements for each blueprint file, IE the two blueprint files in this scenario

It would be great to know if there's a way of doing this :)

Cheers,
Alan

5 comments
Comment actions Permalink

I've added a short paragraph "Models across multiple files" to DOM documentation (http://confluence.jetbrains.com/display/IDEADEV/Accessing+XML+through+IntelliJ+IDEA+DOM) , let me know if you need more information.

0
Comment actions Permalink

Thanks Yann :)

I've now created a BlueprintDomModel and BlueprintModelFactory class. I've been having difficulties getting this code to trigger though, how can I register this class with IntelliJ?
I couldn't see any extensionPoints within the plugin.xml file, nor could I see references to Strut's ModelFactory within its plugin.xml file either.

Is there a naming convention or such that must be followed for IntelliJ to pick this up maybe?

Thanks again for the help

Alan

0
Comment actions Permalink

Those are classes used internally by your plugin's resolve/completion mechanisms, you do not need to register them in your plugin.xml.

They "only" provide the layer for calculating the model/related files to work against (iterating and matching/collecting found elements), you'll have to provide corresponding Converter/PsiReferenceProvider yourself :-)

See com.intellij.struts2.model.constant.contributor.ResultTypeConverter#getReferenceVariants for example, which provides all completion variants for <result-type> found in the current model.

0
Comment actions Permalink

Brilliant, thanks :)

Managed to get everything working; I'm noticing that i'll have to implement my own local inspection class for making sure that all beans have unique IDs across files?
It would've been really nice to have just implemented some sort of resolver method in the dom FileDescription class, which would have let intellij handle all of of the cool stuff it normally does, but just across multiple files!

It's still really nice to see how easy it is to write powerful plugins none the less :)

Alan

0
Comment actions Permalink

Great, looking forward to see your plugin in public soon ;-)

BasicDomElementsInspection uses com.intellij.util.xml.highlighting.DomHighlightingHelperImpl#checkNameIdentity to determine unique @Name values. If that doesn't suit your needs you'll be more flexible using your own (dedicated) inspection.

0

Please sign in to leave a comment.