Make the framework more modular

[Matthew Bonner]

There is a uservoice new feature suggestion titled "Make the framework more modular" which I'm hoping we could discuss here for the following reasons:
1) There isn't an awful lot of engagement regarding this on the uservoice website
2) Will has mentioned moving dev/tasks into a module in another topic within the Google Groups discussion
3) I'm in favour of moving forwards in a more modular structure, and am hoping we can put some plans in place to move this forward by talking about it here in an attempt to get something in motion.

The uservoice new feature suggestion can be read at the following URL:
http://silverstripe.uservoice.com/forums/251266-new-features/suggestions/6254715-make-the-framework-more-modular

In order to make the framework and CMS more modular we have to first establish what is essential (while allowing the essentials to be overloadable) and what should be swappable (ie completely replace, or overload and inject overloaded class).

The essentials to me are:

• A bootstrap to make the framework available
• A runtime that provides the facility to load a web application
• A worker interface which provides the ability to work with any web server
  

The bootstrap should be configurable per website however a default out-the-box implementation should be available.

The runtime should be a very basic class that is easily overloadable.

The request and response classes should be defined by the runtime, which is overloadable allowing you to change the request and response classes and the runtime where required.

The CMS should be a package of modules and should be available by default when downloading SilverStripe (pretty much the same as how we have an option to download the framework or the framework with the CMS).

The session handling should be a module.
The routing should be a module.
The MVC should be a module.
The fields should be a module.
The template engine should be a module.
The tasks should be a module.
And so on.

Modules should be able to define dependencies too.

If we can split everything out like so, it is actually possible to make it easier to maintain each module by delegating out who is responsible for what aspect of SilverStripe.

I think this should be the focus for SilverStripe 4 to adopt such a pattern whereby you are making use of lots of interfaces and modules as this will potentially cause a lot of breaking changes.

There are other benefits of using modules too, such as increasing community engagement, as when one person has a problem and they are able to write a module which doesn't have to rewrite a lot of code already existing in the core, put a pull request together and hope that it is accepted, the person is more likely to tackle the problem which will result in the community growing as more people see the benefits of SilverStripe. This will give the core developers a much easier time when it comes to maintaining SilverStripe.

So I wondered what the thoughts are of those who have the final say in what direction SilverStripe moves, along with any input anyone else has.

[Ingo Schommer]

Hello Matthew, sorry for the radio silence on this one, I think you caught everyone in the end of year project frenzy :)

I agree that decoupling is very important for a sustainable future of SilverStripe. My main driver for modularisation is to gradually swap out existing components with more modern ones, I don't expect many SilverStripe components (view, ORM, etc) to be used as standalone libraries, simply because there's so many good alternatives there already.

At the moment, the state of discussion is fairly big picture: How much effort do we put into modernising and modularising existing components vs. swapping them for other libraries in the first place. Which parts of our codebase are considered a competitive advantage vs. legacy baggage? How do we ensure a smooth upgrade experience when using other libraries?

These questions have been in the heads of many SilverStripers (and the core team) for a long time now, but it looks like 2015 is shaping up to be the year where we can see some decisive movement. Sorry that it's all a bit hand wavy at the moment, it's a big topic. Thanks for raising this and sharing your perspective!

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Ingo Schommer | Solutions Architect
SilverStripe (http://silverstripe.com)
Mobile: 0221601782
Skype: chillu23