Bug 22598

asgeir@dimon.is wrote:
> 
> Hi.
> I was investigating the text-edit code to see how code completion
for XSLT
> might be implemented.  If I want to reuse XMLCompletion and
XMLCompletion
> query, there no way for me to add support for a new GrammarQuery. 
To add
> this support, the following has to be done:
> 
> 1.  Create a new interface: GrammarParser which should be defined
like:
> public interface GrammarParser {
>     GrammarQuery parse(InputSource in);
> }
> 
> DTDParser should implement this interface.  I could create a
> XSLTGrammarParser which implements this interface.  When the parse
method
> of XSLTGrammarParser is called, it will return a XSLTGrammarQuery if
the
> root element in the InputSource XML is <xsl:stylesheet>, otherwise
it will
> return null.

Look at current sources, there is also a need for grammar invalidation
means. It is not probably required by XSLT grammar provider but it is
must for DTD grammar provider. I was not able to generalize it so 
I deferred it (hardcoded the logic) until really needed.
 
Besides basic XSLT completion can be delivered by any XML Schema aware
grammar provider.

> ----
> 
> 2.  Add a static method to XMLCompletionQuery which allows any class
to add
> a GrammarParser:
> public static void addGrammarParser(GrammarParser parser) {
>      ..
> }
> 
> This method should add a GrammarParser to a static list of
GrammarParsers.

Mind dependencies! It is better to use org.openide.util.Lookup style
of
registrations i.e. let providers register themselves at their module
XML
layer and let XMLCompletionQuery lookup for them.
 
> ----
> 
> 3.  Change the XMLCompletion.GrammarCache.loadParser() method to
make it
> look through the list of registered GrammarParser objects.  For each
> GrammarParser object, the parse method is called.  If the method
returns
> non-null GrammarQuery, that particular query will be used.  If all
the
> registered GrammarParser object's parse methods return null, the
DTDParser
> is used (which means unchanged behavior).

Searching a list of registered grammars may be very expensive if
every grammar tries to parse. Well it may return lazy initialized
GrammarQuery (an implementation will finish parsing on the first
request).
 
> -----------
> 
> Do you accept those changes?  If so, I will implement them.

Yes, we need to get rid of hardcoded logic now. It blocks you.
Another interfaces draft:

/**
 * Factory registered in Lookup under Services/XML/text-completion.
 */
public abstract class GrammarManagerFactory {

  GrammarManager createGrammarManager(Document or InputSource ???);
  // identity of InputSource etc,

}

/**
 * Takes care of grammar creating and notifies if it is still
 * able to serve properly.
 */
public interface GrammarManager {

  GrammarQuery getGrammarQuery();

  // it must be able to decide, how???

  final String PROP_VALID;
 
  addPropertyChangeListener(...);
  removePropertyChangeListener();

  boolean isValid();
  
}

I hope you get some idea how to improve them.
 
> Where should I put the XSLTGrammarParser and XSLTGrammarQuery
classes?
> XSLT support is becomming a standard part of most XML editors.  I
would
> thus like to include them in the "xml-text-edit" module in the
package
> "org.netbeans.modules.xml.text.completion.xslt".  Do you agree?

I makes sense to me. Let others speak up (I heard that some people
need very lightweight XML editing support, it probably does not
cover XSLT).

Target milestone was changed from not determined to TBD

Feature positively influences user 
productivity.  

Feature positively influences user 
productivity.  

Duplicate  

*** This issue has been marked as a duplicate of 20421 ***