Great!

So basically the config is really part of the extension contract. They are what allow the extension to make assumptions about the type of content it will be processing. That's why baking it into the definition of the class makes sense.

Of course, the next step is to figure out how this information gets consumed by the Ruby side. Very likely, it needs a more generic way of retrieving this information. That means the registry should be the mediator in getting this information about an extension class. The Java registry then has the freedom to choose how it reads and manages the information.

I will prototype the idea so that I get a better understanding about how viable that approach is. A good Devoxx hacking project. If you have some ideas about how this API will look, I'm definitely interested to hear. Don't feel constrained about what is there today. Propose how you want it to look, then we'll make it work!

Cheers,

-Dan

On Nov 13, 2013 9:49 AM, "asotobu [via Asciidoctor :: Discussion]" <[hidden email]> wrote:

I love the idea of annotations, I think it is more clear and easy for developers. About preference, in my case I don't have a preference , but the first one because it quite simple, adding annotations inside another annotation in my opinion disturbs a bit the readability of the code, in your example you have tabbed correctly the annotations but someone (or autoformatters) could write all of them linley. But as you suggest I have not preference.

But because I don't have the whole picture, I don't see how this could help us in removing static method.

Alex

2013/11/13 mojavelinux [via Asciidoctor :: Discussion] <[hidden email]>

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

--
+----------------------------------------------------------+
  Alex Soto Bueno - Computer Engineer
  www.lordofthejars.com
+----------------------------------------------------------+

---

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-tp898p981.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

---

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-tp898p982.html

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