Skip to content

Labels in markdown done

Ilya Gulya requested to merge ilyagulya/gitlab-client:task/extend_markdown_support-display_labels into feature/extend_markdown_support

This MR is a part of issue #87.

What's changed:

  1. Added MarkdownDecorator interface for decorating markdown nodes with our custom delimiters to process them later.
  2. Added ExtensionProcessor interface. You can override it to process your own type of Markdown extension. All processors are defined inside MarkDownConverterProvider as arguments to GitlabExtensionsDelimiterProcessor
  3. There are also CompositeMarkdownDecorator and CompositeVisitor which are already used to propagate our custom decorators and visitors to parser.
  4. MarkdownConverterProvider now needs list of available labels to process Markdown.
  5. To make usage of MarkdownConverterProvider more convenient now there is a ProjectMarkdownConverterProvider which downloads labels for project automatically.
  6. Labels are cached inside LabelInteractor for current session. It is made to prevent a lot of requests for labels (for lists, for example).

To be able to parse nodes where first-only delimiter is existent, we are decorating each of such nodes with out custom project-specific extension syntax. Extension syntax looks like this: %%%%%${EXTENSION_TYPE}_${EXTENSION_ARGUMENTS}%%%%% For example: We have label ~single defined in markdown. We are making custom LabelDecorator that replaces such nodes to our custom extension:

%%%%%LABEL_SINGLE_single%%%%%

In this case out LABEL extension provides its own arguments string which have its own syntax:

SINGLE_single

where SINGLE is node type (nodes can be single-word, multi-word and id-based) and single is node name.

After decorating, markdown parser can detect our custom nodes using delimiters %%%%% and launches our GitlabExtensionsDelimiterProcessor

It is detecting type of extension based on substring before the first _ symbol and decides which extension processor to launch, and propagates arguments to it.

Custom extension processor converts current Text node to its own type.

After all, our custom nodes can be processed using Visitor. Visitors are also defined inside MarkdownConverterProvider.

What's not done:

  1. Click handling on labels. Now click leads to log record "Label ${name} clicked"
  2. Spannable cannot set margins in text. It means that we maybe need to control line-height of target TextView to make labels not to meld if they are under each other in separate lines:

Here's a result of this merge request:

Edited by Ilya Gulya

Merge request reports