anchor.diff:  |====
   
   
  -== I/O limitations
  -
  -Until the studio integration is complete, it is recommended to limit processors to 1 input.
  -
  -== Handle UI interactions
  -
  -It is also recommended to provide as much information as possible to let the UI work with the data during its edition.
  +==== Limitations
  +
  +Until the studio integration is complete, it is recommended to limit processors to one input.
  +
  +=== Processor components
  +
  +Configuring processor components is simpler than configuring input and output components because it is specific for each component. For example, a mapper takes the mapping between the input and output models:
  +
  +[source,java]
  +----
  +public class MappingConfiguration {
  +    @Option
  +    private Map<String, String> fieldsMapping;
  +
  +    @Option
  +    private boolean ignoreCase;
  +
  +    //...
  +}
  +----
  +
  +
  +
  +== Handling UI interactions
  +
  +It is recommended to provide as much information as possible to let the UI work with the data during its edition.
   
   === Validations
   
   ==== Light validations
   
  -The light validations are all the validations you can execute on the client side. They are listed in the <<documentation.adoc#documentation-ui-hints, UI hint>> part.
  -
  -This is the ones to use first before going with custom validations since they will be more efficient.
  +Light validations are all the validations you can execute on the client side. They are listed in the <<documentation.adoc#documentation-ui-hints, UI hint>> section.
  +
  +Use light validations first before going with custom validations because they are more efficient.
   
   ==== Custom validations
   
  -These ones will enforce custom code to be executed, they are more heavy so try to avoid to use them for simple validations
  -you can do with the previous part.
  -
  -Here you define an action taking some parameters needed for the validation and you link the option you want to validate to this action.
  -Here is an example to validate a dataset. For example for our JDBC driver we could have:
  +Custom validations enforce custom code to be executed, they are more heavy to process, so prefer using light validations when possible.
  +
  +Define an action with the parameters needed for the validation and link the option you want to validate to this action.
  +For example, to validate a dataset for a JDBC driver:
   
   [source,java]
   ----
  
positive.code: }
  ----
  
  === Don't forget the component representation
  
  Each component must have its own icon:
  
  
negative.code: = Talend Component Kit best practices
  :page-partial:
  
  == Organizing your code
  