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.

Bug 160984 - add new API method parsing.api.Source.getAllEmbeddings
Summary: add new API method parsing.api.Source.getAllEmbeddings
Status: NEW
Alias: None
Product: editor
Classification: Unclassified
Component: Parsing & Indexing (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: David Konecny
Depends on:
Reported: 2009-03-24 09:29 UTC by David Konecny
Modified: 2009-04-21 23:56 UTC (History)
3 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2009-03-24 09:29:18 UTC
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.
Comment 1 David Konecny 2009-03-24 09:30:25 UTC
Please review/comment. Thanks.
Comment 2 Vitezslav Stejskal 2009-03-24 12:05:12 UTC
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.
Comment 3 Marek Fukala 2009-03-24 16:43:21 UTC
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).

Comment 4 Vitezslav Stejskal 2009-03-24 17:59:42 UTC
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.
Comment 5 Marek Fukala 2009-03-24 20:55:46 UTC
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.
Comment 6 David Konecny 2009-04-21 23:56:44 UTC
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