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.
I would like to add following new method to Source class which provides access to Embeddings collected for a given source. Embeddings can be (re-)used by other code and not only for purpose of parsing. In my case I would be using the Embeddings from source code indentation engines. /** * Returns all Embeddings collected for this <code>Source</code>. * Only embeddings provided by <code>EmbeddingProvider</code> are returned. */ public Iterable<Embedding> getAllEmbeddings () { return SourceAccessor.getINSTANCE().getCache(this).getAllEmbeddings(); } There seems to exist also ParserBasedEmbeddingProvider class but it is not referenced by any code so I have no idea what is it for. The proposed API method will not return any Embeddings provided by ParserBasedEmbeddingProvider.
Please review/comment. Thanks.
I object. Embeddings can be hierarchically nested and your method will only return first level embeddings, which IMO is wrong from API point of view. If we want to give an explicit access to embeddings then we should give access to the whole hierarchy. The api already provides access to embeddings through ResultIterator. I assume your motivation is to be able to use embeddings without having to parse the sources. In which case I would suggest using lexer. Would that be acceptable? Lexer and Parser embeddings should always map 1-1. Also see issue #157036.
I belive the motivation here was to be able to utililize the virtual sources generated by EmbeddingProviders. Lexer is not enought here since the EP may do fixes of the code broken by templatings for example. I am not sure if the ResultIterator.getEmbeddings() requires parsing of the sources and if it does that now (assuming there isn't any ParserBasedEmbeddingProvider).
I see. As far as I understand RI.getEmbeddings() does not parse the Snapshot. And so it could probably be used for what David needs. IMO the embbeddings hierarchy can safely be traversed using RI without any parsing as long as you don't call RI.getParseResult methods. But obviously Hanz is the one who knows. Also Hanzi what is the story with ParserBasedEmbeddingProvider. If it's not used in the infrastructure and nobody is missing it then I vote for removing it from the API.
I would prefer keeping the ParserBasedEmbeddingProvider since it is a regular usecase. For example, once JSP parser is migrated to the parsing api, there might be a real usecase - embedded html source depends on set of custom tags prefixes supplied by the jsp parser. It is not possible to generate the *proper* virtual source without the parser info. I am not saying I'll do it exactly this way, but I would like to have it in the api.
I'm withdrawing this request for now. I was not aware of embeddings hierarchy - where and how exactly that one is built in Parsing API? By hierarchy you mean that HTML is first extracted from JSP and later CSS is extracted from HTML extract etc?