fix docs code tag

src/docs/guide/configuration/accessing_plugin_config.gdoc

@@ -6,13 +6,12 @@ your plugin, automatically namespace for your plugin using the @plugin.<pluginNa
 
 So in a service you can trivially access this config inside a service or controller for example:
 
-{docx}
+{code}
 class MyPluginService {
     def doSomething() {
        if (pluginConfig.enabled) {
           println "It worked!"
        }
     }
 }
-{docx}
-
+{code}

src/docs/guide/configuration/changing_config.gdoc

@@ -7,7 +7,7 @@ The code uses a simple DSL that is identical to normal Config except:
 
 The application Config is loaded first. All the doWithConfig blocks are evaluated and the results merged in.
 
-{docx}
+{code}
 def doWithConfig = { config ->
     platformUi {
         ui.Bootstrap.button.cssClass = 'btn'
@@ -21,6 +21,6 @@ def doWithConfig = { config ->
         grails.x.y = config.p.q == 'something' ? true : false
     }
 }
-{docx}
+{code}
 
 See [doWithConfig|pluginConventions] for more details.

src/docs/guide/configuration/declaring_configuration_options.gdoc

@@ -4,23 +4,23 @@ This allows the platform to warn users when they mistype a config name or supply
 
 Do declare the options your plugin supports, add the @doWithConfigOptions@ closure to your plugin descriptor:
 
-{docx}
+{code}
 def doWithConfigOptions = {
     'organization.name'(type: String, defaultValue: 'My Corp (set plugin.platformCore.organization.name)')
     'site.name'(type: String, defaultValue: 'Our App (set plugin.platformCore.site.name)')
 }
-{docx}
+{code}
 
 This block, from the platform core, defines two configuration values of type String, with a default value.
 
 You can also supply a custom validator:
 
-{docx}
+{code}
 def doWithConfigOptions = {
     'concurrentConnections'(type: Integer, defaultValue: 10,
         validator: { v -> v < 500 ? null : 'concurrent.connections.too.big' }
 }
-{docx}
+{code}
 
 Behaving just like constraint validators, your validator returns null for "ok" or an i18n message string for the error.
 

src/docs/guide/events.gdoc

@@ -20,7 +20,7 @@ and get maximum flexibility when required :
 
 In a nutshell, you will :
 * Send events :
-{docx}
+{code}
 class UserController{
 
    def registration(){
@@ -45,10 +45,10 @@ class UserController{
          }
   }
 }
-{docx}
+{code}
 
 * Write listeners (or event handler, or event reactor or whatever you call it):
-{docx}
+{code}
 class UserService{
 
    //use method name 'mailRegistration' as topic name
@@ -72,4 +72,4 @@ class UserService{
         }
   }
 }
-{docx}
+{code}

src/docs/guide/events/artifact.gdoc

@@ -37,7 +37,7 @@ timeout | Long |  | Default timeout for execution time, throwing a TimeoutExcept
 \* | \* |  | Any attributes can be written to be used by plugins through EventDefinition.othersAttributes
 {table}
 
-{docx}
+{code}
 events = {
     //prevents any events in gorm namespace
     '*' namespace:'gorm', disabled:true
@@ -74,8 +74,8 @@ events = {
     //testTopic9 onError:'anotherTopicErrors', onReply:'anotherTopicReplies'
 
 }
-{docx}
+{code}
 
 h3. Reloading in Development mode
 
-It works.
+It works.

src/docs/guide/events/config.gdoc

@@ -9,7 +9,7 @@ Based on Platform-Core [configuration|guide:configuration] mechanism, the plugin
 {table}
 
 In addition, you can override beans values such as gormTopicSupport
-{docx}
+{code}
 beans{
     gormTopicSupport {
         //transform gorm Events Objects types into topics
@@ -22,4 +22,4 @@ beans{
         ]
     }
 }
-{docx}
+{code}

src/docs/guide/events/gorm.gdoc

@@ -19,7 +19,7 @@ Same listeners behaviors apply, e.g. using EventMessage for the argument type, u
 Because listeners are called if there are *no arguments* or the argument *type is assignable to current event data type*, specifying
 a domain class is the only required step to filter domains events.
 
-{docx}
+{code}
 class SomeService{
 
     @Listener(namespace = 'gorm')
@@ -39,21 +39,21 @@ class SomeService{
     }
 
 }
-{docx}
+{code}
 
 h3. Filtering with Events Artifact
 
 Setting a filter through an Events artifact allows more fined control and efficient selection since it prevents events to be
 propagated :
 
-{docx}
+{code}
 events = {
     'afterInsert' namespace:'gorm', filter:Book
     'afterDelete' namespace:'gorm', filter:{it.id > 5}
     'afterUpdate' namespace:'gorm', filter:{it in Book || it in Author}
     'beforeDelete' namespace:'gorm', disabled:true
 }
-{docx}
+{code}
 
 {note}
 GORM may generate tons of events. Consider using it wisely, combine it with routing filtering.
@@ -71,7 +71,7 @@ If a listener handles one of the _before\*_ topics and returns a boolean value,
 * Returning *false* will cancel the current database write
 * Returning *true* will just let the chain continuing
 
-{docx}
+{code}
 class SomeService{
 
     //veto any Book insert
@@ -80,4 +80,4 @@ class SomeService{
         false
     }
 }
-{docx}
+{code}

src/docs/guide/events/listening.gdoc

@@ -6,7 +6,7 @@ h3. Defining listeners at compile time
 
 Within Grails services you can use the *@Listener* annotation. It takes a *topic* string, but you can omit it and use the *method name* as the topic to listen for:
 
-{docx}
+{code}
 class SomeService{
 
    @grails.events.Listener(topic = 'userLogged')
@@ -18,12 +18,12 @@ class SomeService{
    def mailSent(){
   }
 }
-{docx}
+{code}
 
 Event methods can define a *single argument*, and the value is the object sent with the event. Usually this is the "subject" of the event.
 However an event is carried by an enveloppe called EventMessage which contains several useful metadata like additionnal headers, current topic :
 
-{docx}
+{code}
 class SomeService{
 
    @grails.events.Listener(topic = 'userLogged')
@@ -33,7 +33,7 @@ class SomeService{
     println userMessage.data // displays data
    }
 }
-{docx}
+{code}
 
 If a listener argument type is not assignable to an event data type, the event *silently skips the mismatching listener*. If you want to catch
 every event types, use Object type or if the argument is not necessary, do not declare it.
@@ -47,7 +47,7 @@ h3. Namespacing
 
 Your declared events belongs to the *app* namespace, unless you tune it using the *namespace* argument or the Events DSL we will introduce later.
 
-{docx}
+{code}
 class SomeService{
 
    @grails.events.Listener(topic = 'userLogged', namespace = 'security')
@@ -59,17 +59,17 @@ class SomeService{
    def afterInsert(User user){
   }
 }
-{docx}
+{code}
 
 Remember that you will need to specify the scope when triggering events if you customize it with a different value than *app* :
 
-{docx}
+{code}
 class SomeController{
    def myAction(){
         event for:'security', topic:'userLogged', data:session.user
    }
 }
-{docx}
+{code}
 
 {warning}
 It's mandatory to declare namespace when using events bus from a plugin in order to avoid any conflicts.
@@ -79,7 +79,7 @@ h3. Proxy (AOP) support
 
 By default, listeners try to call the original method (unproxified bean). Using *proxySupport* you can tweak this setting :
 
-{docx}
+{code}
 class SomeService{
 
    static transactional = true
@@ -90,13 +90,13 @@ class SomeService{
    }
 
 }
-{docx}
+{code}
 
 h3. Dynamic listeners
 
 Some edge cases need runtime registration. If you meet this use case, use the injected [on|eventsMethods] method :
 
-{docx}
+{code}
 class SomeController{
 
  def testInlineListener = {
@@ -115,13 +115,13 @@ class SomeController{
         render "$listener registered"
  }
 }
-{docx}
+{code}
 
 h3. Wildcard support
 
 Capturing a wider group of events can be useful, specially for monitoring purposes. It's possible to listen for multiple topics/namespaces in a single shot using *wildcard as the last character*.
 
-{docx}
+{code}
 class SomeService{
 
  @grails.events.Listener(namespace='role-*', topic = 'chat-*')
@@ -130,7 +130,7 @@ class SomeService{
       println userMessage.event
    }
 }
-{docx}
+{code}
 
 {note}
 This feature will probably evolve to a smarter implementation behaving like UrlMappings and authorizing substring captures
@@ -147,7 +147,7 @@ The above square brackets determine each optional part of the sequence id thus a
 This pattern is useful when using *countListeners*, *removeListeners* or *extensions*. For instance, overriding
 a generated *channel* with *events-si* plugin requires to use @namespace://topic@ if _namespace_ is different from "app".
 Another example to count listeners:
-{docx}
+{code}
 //count every listeners subscribed to 'mytopic' inside TestService
 countListeners("mytopic:my.TestService")
 
@@ -156,8 +156,8 @@ countListeners("gorm://*")
 
 //remove every listeners in TestService
 removeListeners("*:my.TestService")
-{docx}
+{code}
 
 h3. Reloading in Development mode
 
-It works.
+It works.

src/docs/guide/events/replying.gdoc

@@ -6,7 +6,7 @@ h3. Simple reply
 
 Replying is a simple matter of returning an object from the listener method :
 
-{docx}
+{code}
 class SomeService{
     @Listener
     def logout(User user){
@@ -17,12 +17,12 @@ class SomeService{
        return disconnectDate
     }
 }
-{docx}
+{code}
 
 If listeners return non null objects, the caller can access them through the EventReply enveloppe returned immediatly
 after calling *event* method. The other option is the use of a *reply handler* :
 
-{docx}
+{code}
 class SomeController{
 
    def logout(){
@@ -41,7 +41,7 @@ class SomeController{
        render reply_future.get(30, TimeUnit.SECONDS)
    }
 }
-{docx}
+{code}
 
 {note}
 Whenever an event is triggered, a task is submitted into the events bus thread pool and a Future returned, wrapped into EventReply.
@@ -55,7 +55,7 @@ Multiple listeners can return values for the same topic/namespace. In this case,
 Remember that a valid result is a non null value, hence why even if 3 handlers have reacted but only 2 did return something, then you will only
 see 2 values in the *EventReply.values*.
 
-{docx}
+{code}
 class SomeController{
 
    def logout(){
@@ -68,7 +68,7 @@ class SomeController{
        render reply.values
    }
 }
-{docx}
+{code}
 
 h3. Exceptions
 
@@ -83,7 +83,7 @@ An *onError* parameter is available and accepts a *Closure{List<Throwable> error
 Exceptions in multiple listeners scenario don't interrupt the execution flow and leave a chance to others listeners to execute as well.
  The return value from a failing listener becomes the raised exception.
 
-{docx}
+{code}
 class SomeController{
 
    def logout(){
@@ -111,15 +111,15 @@ class SomeController{
 
    }
 }
-{docx}
+{code}
 
 h3. Waiting replies
 
 In domains, services and controllers artefacts you can wait for events using "EventReply[] waitFor(EventReply... eventReplies)".
 It accepts as many events replies you want and returns the same array for functiunal programming style.
 EventReply also have a waitFor method for one-line waiting.
 
-{docx}
+{code}
 class SomeController{
 
    def logout(){
@@ -142,4 +142,4 @@ class SomeController{
 
    }
 }
-{docx}
+{code}