whats_new.rst 5.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177
  1. .. _whats_new:
  2. What's New
  3. ==========
  4. New Features in Cement 2.8
  5. --------------------------
  6. ArgparseController
  7. ^^^^^^^^^^^^^^^^^^
  8. Work has finally begun, and is mostly complete on the refactoring of
  9. ``CementBaseController``. The new
  10. :class:`cement.ext.ext_argparse.ArgparseController` introduces the following
  11. improvements:
  12. * Cleaner, and more direct use of ``Argparse``
  13. * Does not hijack ``Argparse`` usage in any way.
  14. * Provides an accessible ``sub-parser`` for every nested controller,
  15. allowing the developer direct access to perform more advanced actions
  16. (argument grouping, mutually exclusive groups, etc).
  17. * Provides the ability to define arguments at both the controller level,
  18. as well as the sub-command level
  19. (i.e. ``myapp controller sub-command {options}``).
  20. * Supports argument handling throughout the entire CLI chain
  21. (i.e. ``myapp {options} controller {options} sub-command {options}``)
  22. The ``ArgparseController`` will become the default in Cement 3, however
  23. ``CementBaseController`` will remain the default in Cement 2.x. Developers
  24. are encouraged to begin porting to ``ArgparseController`` as soon possible,
  25. as ``CementBaseController`` will be removed in Cement 3 completely.
  26. Related:
  27. * :issue:`205`
  28. Extensions
  29. ^^^^^^^^^^
  30. * :ref:`Argcomplete <cement.ext.ext_argcomplete>` - Provides the
  31. ability to magically perform BASH autocompletion by simply loading the
  32. ``argcomplete`` extension. (Requires ``ArgparseArgumentHandler`` and
  33. ``ArgparseController`` to function).
  34. * :ref:`Tabulate <cement.ext.ext_tabulate>` - Provides tabularized output
  35. familiar to users of MySQL, PGSQL, Etc.
  36. * :ref:`Alarm <cement.ext.ext_alarm>` - Provides quick access to
  37. setting an application alarm to easily handling timing out long running
  38. operations.
  39. * :ref:`Memcached <cement.ext.ext_memcached>` - Now supported on Python 3.
  40. Misc Enhancements
  41. ^^^^^^^^^^^^^^^^^
  42. * Cement now supports the ability to reload runtime within the current
  43. process via ``app.reload()``. This will enable future refactoring of
  44. the ``ext_reload_config`` extension that is intended to handle
  45. reloading runtime after configuration files are modified. This
  46. affectively adds ``SIGHUP`` support.
  47. New Features in Cement 2.6
  48. --------------------------
  49. Extensions
  50. ^^^^^^^^^^
  51. * :ref:`Reload Config <cement.ext.ext_reload_config>` - Provides the
  52. ability to automatically reload ``app.config`` any time configuration
  53. files are modified.
  54. * :ref:`ColorLog <cement.ext.ext_reload_config>` - Provides colorized
  55. logging to console (based on standard logging module).
  56. Python With Statement Support
  57. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  58. Using the ``with`` statement makes setting up, running, and closing Cement apps
  59. easier and cleaner. The following is the recommended way of creating, and
  60. running Cement apps:
  61. .. code-block:: python
  62. from cement.core.foundation import CementApp
  63. with CementApp('myapp') as app:
  64. app.run()
  65. Or a more complete example:
  66. .. code-block:: python
  67. from cement.core.foundation import CementApp
  68. class MyApp(CementApp):
  69. class Meta:
  70. label = 'myapp'
  71. with MyApp() as app:
  72. try:
  73. app.run()
  74. except Exception as e:
  75. # handle all your exceptions... this is just an example
  76. print('Caught Exception: %s' % e)
  77. When the ``with`` statement is initialized, the ``app`` object is created, and then right away ``app.setup()`` is called before entering the block. When
  78. the ``with`` block is exited ``app.close()`` is also called. This offers a
  79. much cleaner approach, while still ensuring that the essential pieces are run
  80. appropriately. If you require more control over how/when ``app.setup()`` and
  81. ``app.close()`` are run, you can still do this the old way:
  82. .. code-block:: python
  83. from cement.core.foundation import CementApp
  84. app = CementApp('myapp')
  85. app.setup()
  86. app.run()
  87. app.close()
  88. But doesn't that just feel clunky?
  89. **Related:**
  90. * :issue:`281`
  91. Defining and Registering Hooks and Handlers from CementApp.Meta
  92. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  93. Another improvement that lends itself nicely to code-cleanliness is the
  94. ability to define and register hooks and handlers from within
  95. ``CementApp.Meta``. An example using application controllers and a simple
  96. ``pre_run`` hook looks like:
  97. .. code-block:: python
  98. from cement.core.foundation import CementApp
  99. from cement.core.controller import CementBaseController, expose
  100. def my_example_hook(app):
  101. pass
  102. class BaseController(CementBaseController):
  103. class Meta:
  104. label = 'base'
  105. class SecondController(CementBaseController):
  106. class Meta:
  107. label = 'second'
  108. class MyApp(CementApp):
  109. class Meta:
  110. label = 'myapp'
  111. hooks = [
  112. ('pre_run', my_example_hook),
  113. ]
  114. handlers = [
  115. BaseController,
  116. SecondController,
  117. ]
  118. **Related:**
  119. * :issue:`282`