Problem registering two times block extension AsciidoctorJ

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem registering two times block extension AsciidoctorJ

asotobu
Hi Dan,
do you remember the problem we had with Block extensions and config method which should be static?

http://discuss.asciidoctor.org/Extension-API-in-Java-almost-done-but-I-need-some-help-td637.html

The solution was to create an static Map inside Block processor. And it works fine, until I tried to register two block processors. Because the map of block processor is static, the second extension also receives the parameters of first extension, which makes application crashes. This happens because when Map is converted to RubyHash it is reassigned to that static variable, and the second time a class cast exception is thrown because we expect a native Map but we found a JRuby Hash.

So do you think that removing in the static block the content of config var for each processor is safe? (I think it works correctly but it is a bit ugly solution making developers to remove something at start) Maybe we must think another way to integrate better block extensions with AsciidoctorJ? Changing Ruby part?

WDYT? Do you want I try something?

Reply | Threaded
Open this post in threaded view
|

Re: Problem registering two times block extension AsciidoctorJ

asotobu
I respond to myself, NO it is not safe. So we need to change something in Asciidoctor extensions to allow a better integration with AsciidoctorJ. Maybe related with https://github.com/asciidoctor/asciidoctor-java-integration/issues/100
Reply | Threaded
Open this post in threaded view
|

Re: Problem registering two times block extension AsciidoctorJ

mojavelinux
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: Problem registering two times block extension AsciidoctorJ

asotobu
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



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
+----------------------------------------------------------+
Reply | Threaded
Open this post in threaded view
|

Re: Problem registering two times block extension AsciidoctorJ

mojavelinux
Administrator

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



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
Reply | Threaded
Open this post in threaded view
|

Re: Problem registering two times block extension AsciidoctorJ

asotobu
Well I think that would fit perfectly with Java world if we could do something like next code for registering a block:

[source]
----
Map m = ...
m.put(":paragraph", ":open")

asciidoctorModule.block(YellBlock.class, m); <1>
---- 
<1> asciidcotorModule is the interface proxied to Ruby world, it is a low level class.

Then from the point of view of users can use for example annotations approach. And I will manage the annotations to finally construct the map required by underlying class.

I think it will cover all cases.


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

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



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



--
+----------------------------------------------------------+
  Alex Soto Bueno - Computer Engineer
  www.lordofthejars.com
+----------------------------------------------------------+
Reply | Threaded
Open this post in threaded view
|

Re: Problem registering two times block extension AsciidoctorJ

mojavelinux
Administrator
Yep, I could make that work. The options should be stored in the registry internally inside the Ruby code, not read directly from the class definition. But those are impl details I'll work out once I start shifting things around.

I've filed an issue to track this change: https://github.com/asciidoctor/asciidoctor/issues/817

-Dan


On Wed, Nov 13, 2013 at 6:02 AM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Well I think that would fit perfectly with Java world if we could do something like next code for registering a block:

[source]
----
Map m = ...
m.put(":paragraph", ":open")

asciidoctorModule.block(YellBlock.class, m); <1>
---- 
<1> asciidcotorModule is the interface proxied to Ruby world, it is a low level class.

Then from the point of view of users can use for example annotations approach. And I will manage the annotations to finally construct the map required by underlying class.

I think it will cover all cases.


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

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



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



--
+----------------------------------------------------------+
  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-tp898p983.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--