Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-26225

Mobile support for 3rd party macros

XMLWordPrintable

    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      Allow Macro's to have a specific 'mobile' output for use in Confluence Mobile.

      To follow will be a prioritised list of our own Macros to create mobile views for.

            [CONFSERVER-26225] Mobile support for 3rd party macros

            John Masson added a comment -

            brett.ryan if you've had a chance to start looking at 'mobilising' any of your macros and have any feedback on the documentation Paul linked to feel free to email me - jmasson at atlassian dot com.

            John Masson added a comment - brett.ryan if you've had a chance to start looking at 'mobilising' any of your macros and have any feedback on the documentation Paul linked to feel free to email me - jmasson at atlassian dot com.

            Paul Curren added a comment - - edited

            Converting your macro to render on mobile is documented here.

            Paul Curren added a comment - - edited Converting your macro to render on mobile is documented here .

            Brett Ryan added a comment -

            Would it be easier to support different environments through annotations?

            @Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface MacroRender {
    boolean desktop() default true;
    boolean mobile() default false;
}

            This would allow you to introspect and see if the class should be skipped depending on the context. Then, add another member to ConversionContext to determine the mode (mobile/desktop).

            This would be easy for us to write macros, easy for you to implement, keep backwards compatibility and allow support for emerging platforms; i.e. maybe mobile might be supported but not tablet?

            Decisions can then be made inside execute(Map<String, String>, String, ConversionContext) by looking at the context if there is any difference for output.

            For most macros which are simple which don't have any difference for the mobile version it would be a simple matter of annotating the class:

            @MacroRender(mobile=true)
public class MyMacro extends BaseMacro {

            Since desktop defaults to true it does not need to be explicitly set.

            Brett Ryan added a comment - Would it be easier to support different environments through annotations? @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) public @ interface MacroRender { boolean desktop() default true ; boolean mobile() default false ; } This would allow you to introspect and see if the class should be skipped depending on the context. Then, add another member to ConversionContext to determine the mode (mobile/desktop). This would be easy for us to write macros, easy for you to implement, keep backwards compatibility and allow support for emerging platforms; i.e. maybe mobile might be supported but not tablet? Decisions can then be made inside execute(Map<String, String>, String, ConversionContext) by looking at the context if there is any difference for output. For most macros which are simple which don't have any difference for the mobile version it would be a simple matter of annotating the class: @MacroRender(mobile= true ) public class MyMacro extends BaseMacro { Since desktop defaults to true it does not need to be explicitly set.

              pcurren Paul Curren
              jmasson@atlassian.com John Masson
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: