#217 - Major jump in the number of addons, split things up

This is a spacer post for a website comment topic. The content this topic relates to: #217 - Major jump in the number of addons, split things up
To give some context to this...

Nothing here is 'important'. However if it is all done, then something happens -- Composr becomes a very light CMS. That would open up a lot of opportunities for implement lightweight custom projects using Composr as a base framework.
I like the idea of a lightweight base framework on which to build. I was just startled at the number of addons I would need to employ to get back to what I currently use. But then, the greater granularity will allow people to build sites as they wish with much less bloat.
Note that there are still cases in the code that are non modular. For example, in the block wizard, the special support for fancy definition of certain blocks is hard-coded (e.g. how the banner blocks allow selecting a banner type from a dropdown). In the ideal world all this would be achieved via hooks - i.e. block GUI hooks could be written.

It's irrelevant for practical purposes, but I suppose if someone wanted to make an Composr distribution with addons not normally bundled, and want perfect interfaces for block adding, it could be an issue. That could be sorted at an opportune point.
At this point the stuff remaining above is very minor, and trying to force that kind of stuff out of the core would make for a lot of extra plumbing code - effectively defeating the core aims. The sites Composr is targeted for aren't getting simpler, and inevitably I think we need to accept Composr is going to have quite a lot in the core just to do core web activities - and the best approach is to allow config options to turn things on/off or the addon split we currently have.
0 guests and 0 members have recently viewed this.