Keep Bolt lightweight & simple

[hansfn]

Hi,

I'm following the development of Bolt and it's progressing nicely. It will definitely be a nice replacement for PivotX (PivotX 2). However, you shouldn't forget the slogan - "Sophisticated, lightweight & simple CMS". He-he.

[bobdenotter]

I've been killing darlings left and right.. ;-)

Anything in particular that you think that has outgrown the 'lightweight & simple' part of our motto?

[hansfn]

No, not really - it's currently more of a feeling than a fact. It also depends what you mean with simple - simple code or simple to use? I mean, an advance feature can be simple to implement in code ... I'll be more specific (if I can) when I have played more with Bolt - it's a month or two since the last time.

[bobdenotter]

Primarily "simple to use", but also "keeping features as simple as possible, while keeping them useable". It's a gray area, though.

You're right: Something complicated (for a user) can be easy to code, just as something simple for a user could be very, very hard to do right in code. If you bump into things that you feel could be simpler, or should be moved to an extension, let me know.

[pvankouteren]

More and more features get 'configurable' and I would like to argue if it's still simple and, more important, clear enough how to configure Bolt.

I have two suggestions I'd like to discuss:

1: Perhaps we should spread out the config over a couple of files. This might make it a little harder to grasp as 'there are so many files I should touch to configure the system', but the files itself are clearer and can be more specific.
Example: a separate config file for debugging options. debugging.yml. This file should only consist of options which allow or disallow debugging of particular parts of the application.

2: Environment configurations. I think the idea of Symfony2 is a nice one: you can have a development configuration, test configuration and a production configuration. This allows a faster deployment procedure and takes away the hassle of reconfiguring before going live (and the possibilities of forgetting one or more options)

[pvankouteren]

Comment of @marcelfw in issue #64:
Another thing for could be to move the feed stuff into a separate extension. It's quite easy to add controllers in an extension and since feeds are not always necessary it keeps Bolt more simple.

[pvankouteren]

I think the point is valid and the extensions could be far more powerful by doing that. As for the project I think we're not yet at the point where we start moving stuff around because the project is stable. I think, for the moment, it's better to focus on getting a stable Bolt 1.0 version and take a closer look on how to restructure stuff for newer version. However, that's my opinion and I'd sure like to hear the thoughts of @bobdenotter on this.

[marcelfw]

I'm working on Bolts' big brother, so I try to keep out of most
discussions. I think extensions can already do more than you and Bob think
at the moment. At least I didn't have any problem creating my own
asynchronous controllers ;-)
(well, that's besides the debugbar inclusion;-)).

If the big brother is beta-released, I'll have more time for Bolt stuff :)

On Thu, Dec 20, 2012 at 1:58 PM, Patrick van Kouteren <
notifications@github.com> wrote:

I think the point is valid and the extensions could be far more powerful
by doing that. As for the project I think we're not yet at the point where
we start moving stuff around because the project is stable. I think, for
the moment, it's better to focus on getting a stable Bolt 1.0 version and
take a closer look on how to restructure stuff for newer version. However,
that's my opinion and I'd sure like to hear the thoughts of @bobdenotterhttps://github.com/bobdenotteron this.

—
Reply to this email directly or view it on GitHubhttps://github.com/bobdenotter/bolt/issues/58#issuecomment-11572443.

[pvankouteren]

As the DI container is passed along to the extensions, you can basically do anything. It's even possible to split Bolt in a couple of parts and create extensions for particular functionalities. I can imagine some great use cases for that and it offers a lot of potential.

But, looking at the current open issues, there's a focus on functionality, most of them being kind of 'core functionality', so I think at this moment it's important to stick to the focus of the product and put a stable first version out. Once that's done, it would be cool to do a reflection on the software and its design to adjust the focus for v2.

From what I've seen, the aim of Bob is to release Bolt v1 in January 2013, so a change in focus might cause the release to be delayed (as is v0.9) even more.

[bobdenotter]

Yes, let's focus on the last few issues for now, and not introduce new stuff before 1.0.

You are both right that extensions can be very powerful and flexible in Silex/Bolt. Let's just keep doing what we're doing now until we hit 1.0. After that, we should discuss the focus, and determine the course for 2.0.
Perhaps we should then decide to split config files, perhaps not. Perhaps feeds should be an extension, perhaps not.

[peterboorsma]

About the 'keep it simple' remarks: I am already sort of a power user, building most of my new sites with Bolt. I talk to Bob a lot about features and my wishes for Bolt. I think you've reached the point that Bolt is powerful enough to use for most small websites and simple/compact enough for non-developers like myself. Just about right form my point of view.

[pvankouteren]

I find the view of @marcelfw very interesting and there sure is a lot of potential in it. One could also strip out the full admin section and provide it as an extension to be able to 'add CMS backend functionality'. This, however, would exceed the aim of Bolt I think. Would it be an idea to determine 'core' functionality' when Bolt 1.0 is released and put more effort in extensions after that?

[bobdenotter]

@pvankouteren Yes, exactly. Let's keep on the current track for 1.0. After 1.0 we will discuss and re-evaluate the direction and scope of Bolt, and go from there. :-)

[pvankouteren]

What should we do with this discussion? It valuable, but at the other hand it pollutes our issue tracker. Can we perhaps put it on the wiki being a discussion on a particular topic? (In this case: how to keep it clean and simple)

[bobdenotter]

Actually, putting it on a wiki-page sounds like a good idea. :-)

Perhaps we should discuss what "our motto" is, and then the scope of the project and preventing feature-creep are aspects of staying true to our motto.

[pvankouteren]

Todo: put discussion on wiki

[pvankouteren]

Added the actual information to this wiki page.
Suggesting to close this issue.

[thedumbtechguy]

This discussion is dear to my heart. As a programmer, I have been searching for something like bolt for a long time. I'll simply post my comment from the blog.

I do hope we don't end the ways of drupal, joomla and wordpress. There is a reason I use bolt, because it gets out of my way when I am designing. It does the hard part of building a site which is the heavy lifting in terms of the content management (just as a real cms should) and gives me all the flexibility when it comes to what I want to do with that content while providing me the right tools and a simple way to access it. Therefore, my sites have a totally custom feel. Boltcms is the cms for a programmer.

[GwendolenLynch]

Documented by @pvankouteren in the wiki, so we'll close as part of autumn cleaning. Please file a new issue if you feel there is new discussion required.