SilverStripe Meetup Presentation 03/03/2011


Published on

This presentation was used for March's SilverStripe meetup event held in London.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

SilverStripe Meetup Presentation 03/03/2011

  1. 1. SilverStripe 3.0 Roadmap SilverStripe UK Meetup, London 3rd March 2011 Jamie Neil <>
  2. 2. Schedule <ul><ul><li>SilverStripe history
  3. 3. Vision for 3.0
  4. 4. Development process
  5. 5. Highlights
  6. 6. Timeline
  7. 7. Questions
  8. 8. Beer </li></ul></ul>
  9. 9. SilverStripe History <ul><ul><li>Originally commercially licensed
  10. 10. First open source version 2.0 released in 2007  </li><ul><li>BSD licence </li></ul><li>New minor release every year since </li><ul><li>ModelAdmin
  11. 11. Modularisation
  12. 12. Caching
  13. 13. i18n </li></ul><li>Current stable version is 2.4.5 </li><ul><li>Management interface is still basically the same as original release </li></ul></ul></ul>
  14. 14. Vision for 3.0 <ul><ul><li>Could you build Twitter on Sapphire? </li><ul><li>Emphasis on Sapphire as a standalone framework </li></ul><li>Improve and stabilise core features
  15. 15. Admin interface facelift, but not a revolution </li><ul><li>Extensive customer feedback
  16. 16. Lots of work on UX </li></ul><li>Facilitate creation of custom user interfaces </li><ul><li>Plans for inline editing as primary method dropped </li></ul></ul></ul>
  17. 17. Development Process <ul><ul><li>Agile </li><ul><li>Being run as an internal project
  18. 18. Short iterations, measurable goals </li></ul><li>Transparency </li><ul><li> Backlog and status will be available on Trac </li><ul><li> </li></ul><li>API drafts published on development mailing list </li><ul><li> </li></ul></ul></ul></ul>
  19. 19. Git <ul><ul><li>Modules and themes have been moved to github </li><ul><li>
  20. 20. Allows decentralised development
  21. 21. Encourage more community contributions to core </li></ul><li>Old subversion repos are now frozen </li><ul><li>Community members are providing svn mirrors </li></ul><li>Git doesn't have externals </li><ul><li>Does have submodules
  22. 22. SilverStripe is recommending piston as a replacement </li><ul><li>Supports links to git and svn </li></ul></ul></ul></ul>
  23. 23. Highlights* <ul><li>Flexible Object Relational Mapper (ORM)
  24. 24. Separating CMS and Sapphire
  25. 25. jQuery UI
  26. 26. Flexible templating
  27. 27. Performance
  28. 28. Configuration
  29. 29. Data integrity
  30. 30. Module management
  31. 31. Versioned assets
  32. 32. Data grid
  33. 33. Social </li></ul>* Many things still being actively discussed, so all subject to changes
  34. 34. Object Relational Mapper (ORM) <ul><ul><li>Core differentiating feature
  35. 35. Move to more expressive object based queries </li><ul><li>Existing ORM exposes too much SQL </li></ul><li>Improve performance </li><ul><li>Optimise database queries
  36. 36. Less joining </li></ul><li>Database abstraction </li><ul><li>PHP Data Objects (PDO)
  37. 37. Non SQL data sources
  38. 38. MySQL to remain core due to module management </li></ul></ul></ul>
  39. 39. Separating CMS and Sapphire <ul><ul><li>Sapphire difficult to use as a stand alone framework </li><ul><li>Admin interface all in CMS
  40. 40. Need to be able to create pageless applications </li></ul><li>Plan is to bundle basic admin framework with Sapphire </li><ul><li>Security
  41. 41. ModelAdmin?
  42. 42. Similar to Django </li></ul></ul></ul>
  43. 43. jQuery <ul><ul><li>jQuery to replace (customised) Prototype </li><ul><li>Already used in places, but admin interface still largely based on Prototype </li></ul><li>jQuery.entwine to replace behavior.js </li><ul><li>Progressive enhancement
  44. 44. </li></ul><li>jQuery UI will provide standard interface library </li><ul><li>Familiar to many developers
  45. 45. Will make custom themes easier to implement </li></ul></ul></ul>
  46. 50. Flexible Templating <ul><ul><li>Regex spaghetti to be replaced with a proper syntax parser </li><ul><li>Will remove arbitrary restrictions on template args </li><ul><li>e.g. More than two args on an <% if %> block </li></ul><li>String quoting
  47. 51. Inclusion
  48. 52. $Up
  49. 53. Negation </li></ul><li>Decouple from SSViewer (AJShort) </li><ul><li>Will allow alternative templating systems </li></ul></ul></ul>
  50. 54. Performance <ul><ul><li>Improvements to startup time </li><ul><li>Will make AJAX calls more responsive </li></ul><li>Efficient queries </li><ul><li>Less joins </li></ul><li>Smaller memory footprint (hopefully) </li></ul></ul>
  51. 55. Configuration <ul><ul><li>Currently very dependent on static variables </li><ul><li>Global state </li></ul><li>Move towards dependency injection </li><ul><li>Control inversion
  52. 56. Reduced coupling
  53. 57. Easier testing
  54. 58. </li></ul><li>Configuration still by code </li><ul><li>No plans for database storage or web interface </li></ul></ul></ul>
  55. 59. Dependency Injection Example <ul>class MyClass { </ul><ul><li>+    public $dataService; // Dependency defined by convention </li></ul><ul>     public function getWidgets() { -         return DataObject::get('Widget'); <li>+         return $this->dataService->get('Widget');
  56. 60.      }
  57. 61. } </li></ul><ul>DataService is registered with the injector (container), which then used to create the object: <li>Injector::inst()->instantiate('MyClass'); </li></ul>
  58. 62. Data Integrity <ul><ul><li>Foreign keys </li><ul><li>Native database FKs not currently used </li></ul><li>Constraints </li><ul><li>Existing arrangement can result in orphaned data </li></ul></ul></ul>
  59. 63. Module Management <ul><ul><li>Addition of metadata to modules
  60. 64. Dependencies </li><ul><li>Currently relies on developer knowledge </li></ul><li>Tools could allow installation of modules along with their dependencies </li><ul><li>Debian APT? </li></ul><li>No plans for web interface </li></ul></ul>
  61. 65. Versioned Assets <ul><ul><li>Files and images are currently not versioned controlled
  62. 66. Aim to provide a workflow similar to SiteTree pages </li><ul><li>Could possibly be extended to relationships (which are also currently not versioned) </li></ul></ul></ul>
  63. 67. Data Grid <ul><ul><li>ComplexTableField needs replacing </li><ul><li>Has evolved organically
  64. 68. Hard for users and developers to use
  65. 69. DataObject Manager has become the defacto choice </li></ul><li>New Data Grid will take advantage of planned improvements to ORM </li><ul><li>Should make it more efficient </li></ul></ul></ul>
  66. 70. Social <ul><ul><li>Integration with popular third party services </li><ul><li>Facebook
  67. 71. Twitter </li></ul><li>Tools to make integration with other data services easier </li></ul></ul>
  68. 72. Other Potential Targets <ul><ul><li>ModelAdmin
  69. 73. Permissions model
  70. 74. Command line tools (sake)
  71. 75. Generic requirements checker for installer </li><ul><li>Can be used after installation </li></ul><li>Static publisher rewrite
  72. 76. Device independence
  73. 77. Better REST api  </li></ul></ul>
  74. 78. Compatibility <ul><ul><li>Backwards compatibility is important </li><ul><li>Good upgrade docs will be needed </li></ul><li>Templating language will have minimal changes </li><ul><li>Edge cases will be documented </li></ul><li>Backwards compatibility layers may be added where appropriate
  75. 79. Some features may be moved to legacy modules </li><ul><li>e.g. ComplexTableField
  76. 80. Avoids bloat </li></ul><li>Code which was deprecated in 2.4 will be removed </li></ul></ul>
  77. 81. Timeline <ul><ul><li>Alpha </li><ul><li>Mid 2011 </li></ul><li>Beta </li><ul><li>Late 2011
  78. 82. API should be stable here </li></ul><li>Stable </li><ul><li>End 2011 </li></ul></ul></ul>
  79. 83. Community <ul><li>Move to github intended to permit greater community participation </li><ul><li>Makes accepting patches to core easier </li></ul><li>How can we help? </li><ul><li>Modules </li><ul><li>Even simple or unpolished ones </li></ul><li>Tickets in Trac </li><ul><li>Easy ones are tagged </li></ul><li>Contribute your opinions on the mailing list
  80. 84. Testing </li><ul><li>Once alphas are released in the summer </li></ul></ul></ul>
  81. 85. Links <ul><li>Wellington presentation </li><ul><li>Video:
  82. 86. Slides: </li></ul><li>Roadmap:
  83. 87. Planning:
  84. 88. Mailing List:
  85. 89. Designs:
  86. 90. These slides (and video) will be uploaded by next week </li><ul><li> </li></ul></ul>