We discussed this issue at the Hackergarten and there's no doubt in my mind that the configuration settings should be defined using annotations when writing a Java (or Groovy)-based extension.

The current approach of using a static block is the case of a "lost in translation" sort of scenario. Ruby doesn't have annotations. Instead, it's common to use assignments that take on a DSL-style appearance. Since Java and Groovy have annotations, we should definitely take advantage of them on the Java side.

This brings us to a design discussion of how to name and arrange these annotations. Here are two possible approaches:

[source,java]
--

@BlockConfig(

  contexts = {":paragraph", ":open"},

  contentModel = ":simple" // <1>
)

public class MyBlockProcessor extends BlockProcessor {
 ...
}

--

<1> We could, of course, use a constant for the content model since that's a closed set.

[source,java]
--

@BlockConfig(

  @BlockOption(name = "contexts", value = {":paragraph", ":open"})

  @BlockOption(name = "content_model", value = ":simple")

)

--

I don't have a preference at the moment.

Having said that, I am still looking closely as to whether the Ruby side needs to be done cleaner. Regardless, I think this is a the right choice for the Java side.

Thoughts?

-Dan

--

Dan Allen | http://google.com/profiles/dan.j.allen

---

If you reply to this email, your message will be added to the discussion below:

http://discuss.asciidoctor.org/Problem-registering-two-times-block-extension-AsciidoctorJ-tp898p980.html

To unsubscribe from Problem registering two times block extension AsciidoctorJ, click here.
NAML