Syntax Registry concept

Development
#21

After reading the thread, I’m -1 for Initializer which I agree does not convey the actual role of the class.
I don’t see the harm of using Provider since it is parametrized.
I wouldn’t object for a List<Syntax> getSyntax() method though.

#22

Your example is a bit misleading since there would not really be any SyntaxProvider intermediary class anymore, it would be more something like:

@Component
@Named("mysyntax/5.4")
public class MySyntaxProvider implements Provider<List<Syntax>>
{
    List<Syntax> get() {...}
}

I can actually think of one critical benefit of going through the Provider API: it becomes possible to implement it in all the contrib extensions without depending on a more recent version of XWiki. That was not possible with the previous proposal while contrib extensions are actually the main target of this API.

So +1 to use javax.inject.Provider<List<Syntax>> when you want to declare syntaxes that should end up in the registry.

#23

I might be wrong but I’ve the feeling that we’re mixing two usecases in the thread:

  1. we want to be able to register new syntaxes and to allow contributors to add syntaxes to the registry when they contribute to extensions
  2. we want to be able to retrieve all the syntaxes currently registered

I’m completely +1 to use a javax.inject.Provider<List<Syntax>> for usecase 2, but I find it a bit weird to use it as a way to register syntaxes for developers.
IMO it would be better to not mix those two usecases, so to have:

  1. a SyntaxRegistrator component with register/unregister methods (which could take list of syntaxes if needed)
  2. a javax.inject.Provider<List<Syntax>> if we want it which would return all syntaxes (but that could be also another method of SyntaxRegistrator IMO)
#24

For this, you would use SyntaxRegistry#getSyntaxes(). What’s wrong with that?

I may not have understood your point though.

For me what we’re discussing is only for UC1 (" 1. we want to be able to register new syntaxes and to allow contributors to add syntaxes to the registry when they contribute to extensions").

#25

Nothing wrong with that.

Well I aparently read a bit too fast the thread, since I thought the discussion with using javax.inject.Provider<List<Syntax>> was for UC1, but IMO it also shows that the name is maybe not that good.
It looks like the usual issue for naming: taking the POV of the user of the API, or the contributor of the API. Most of the time we use Provider to get something injected in our code, and in XWiki codebase we very rarely contribute to the API with a new Provider to register or declare something.

So I’d be -0 for using javax.inject.Provider<List<Syntax>> to register a new syntax, since I don’t find it natural in the context of XWiki, even if I see your point when you say that the name indicates it provides something.
I’m +1 with Marius suggestion to have a component with register/unregister methods, since I find it more explicit.

#26

So it’s not related to syntax registration. It’s a component to declare provided syntaxes by a component located in a JAR/module.

It just happens that the Syntax Registry uses that to initialize the known syntaxes, but it can be used for other use cases.

#27

hmm I must have missed this suggestion from Marius. Could you point to it? I’d like to know more since that feels like a major pain to use.

#28

talking about this.

#29

@surli from what I understand @mflorea was not suggesting to drop the providers concept. He was just commenting on having only one registerSyntax instead of several in @vmassol proposal.

#30

Yes, I replied here: Syntax Registry concept - #18 by vmassol

#31

Ok sorry for the noise, what I actually misread was the original JIRA issue, so there was actually different usecases discussed in there, I thought that the proposed Provider would be the only mechanism to register a Syntax which was the reason why I wasn’t a big fan of it. Now AFAIU it’s just another way to register it more easily.

So with that in mind ok I’m +1 with the Provider idea.

#32

Cool, we’re progressing :slight_smile: Thx

#33

I hadn’t thought about this one :slight_smile: Interesting indeed.