Future

  • Revision slug: Tools/GCLI/Customization/Future
  • Revision title: Future
  • Revision id: 236100
  • Created:
  • Creator: joewalker
  • Is current revision? No
  • Comment 26 words added

Revision Content

This section is about future extensibility, it does not document current functionality.

GCLI currently has 3 extension points:

  • Commands
  • Types
  • Fields

Of these, currently only Commands are publicly extensible (through gcli.addCommand() and gcli.removeCommand()). It it likely that we will add extension points for Types and Fields in the future. It can be debated whether these extension points should be available to a mozcmd file.

Allowing Types and Fields in mozcmd files is likely to be problematic for a number of reasons:

  • It can introduce dependencies between mozcmd files
  • It makes the security guarantees harder to enforce (what if one type replaces one of the built in types)
  • Types and Fields have a deeper interaction with other parts of GCLI, so it could be hard to do cleanly.

Should we find it necessary to allow registration of Types and Fields in a mozcmd file in the future, we can to introduce a 'class' property which has the following legal values ['command'|'type'|'field'] with the default being 'command'.

For example:

[
  {
    name: 'c1', // 'command' by default
    exec: function() { return 'This is the c1 command'; }
  },
  {
    name: 'c2',
    class: 'command', // make it explicit
    exec: function() { return 'This is the c1 command'; }
  },
  {
    name: 't1',
    class: 'type',
    stringify: function(data) { return '...'; },
    parse: function(str) { return new Conversion(...); }
  }
]

{{ languages( {"zh-cn": "zh-cn/Tools/GCLI/Customization/Future" } ) }}

Revision Source

<p>This section is about future extensibility, it does not document current functionality.<br> <br> GCLI currently has 3 extension points:</p>
<ul> <li>Commands</li> <li>Types</li> <li>Fields</li>
</ul>
<p>Of these, currently only Commands are publicly extensible (through <code>gcli.addCommand()</code> and <code>gcli.removeCommand()</code>). It it likely that we will add extension points for Types and Fields in the future. It can be debated whether these extension points should be available to a mozcmd file.</p>
<p>Allowing Types and Fields in mozcmd files is likely to be problematic for a number of reasons:</p>
<ul> <li>It can introduce dependencies between mozcmd files</li> <li>It makes the security guarantees harder to enforce (what if one type replaces one of the built in types)</li> <li>Types and Fields have a deeper interaction with other parts of GCLI, so it could be hard to do cleanly.</li>
</ul>
<p>Should we find it necessary to allow registration of Types and Fields in a mozcmd file in the future, we can to introduce a 'class' property which has the following legal values ['command'|'type'|'field'] with the default being 'command'.</p>
<p>For example:</p>
<pre>[
  {
    name: 'c1', // 'command' by default
    exec: function() { return 'This is the c1 command'; }
  },
  {
    name: 'c2',
    class: 'command', // make it explicit
    exec: function() { return 'This is the c1 command'; }
  },
  {
    name: 't1',
    class: 'type',
    stringify: function(data) { return '...'; },
    parse: function(str) { return new Conversion(...); }
  }
]
</pre>
<p>{{ languages( {"zh-cn": "zh-cn/Tools/GCLI/Customization/Future" } ) }}</p>
Revert to this revision