This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Details to come ...
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.
Duplicate *** This issue has been marked as a duplicate of 20421 ***