Skip to main content ↑ ↓
Modular Approach (born from removing News Fader) Started by Ant59 · · Read 9699 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

Modular Approach (born from removing News Fader)

I was thinking about how many things in Elkarte really ought to be addons and how many addons might do better in the core. We seem to have many things like the News Fader which really ought to be addons rather than core functionality.

Perhaps it would be better to create some official Elkarte addons that could be included with the installation? For example, the News Fader, the Like system, OpenID logins, calendar, etc. from the core. And things like SimplePortal and my external authentication addon from the addons. These things should be a selectable option when downloading Elkarte for installation rather than baked-in functionality or 3rd party addons, since they're not technically "core" functionality to a forum engine, but are important to a lot of people using Elkarte.

Of course, this would mean handing over the code for any volunteering addons to the Elkarte team, which would then fall under the Elkarte license.

Opinions?

Re: Modular Approach (born from removing News Fader)

Reply #1 –

Could be combined with this:
http://www.elkarte.net/community/index.php?topic=1960.0

Nice idea. So you can choose a very simple, small system or the complex package with all you can eat.

Re: Modular Approach (born from removing News Fader)

Reply #2 –

Yeah pretty much. Just choose the components you want to install with the core.

Re: Modular Approach (born from removing News Fader)

Reply #3 –

I'm not so sure about removing them and let the user pick what they want at install (just because I think the "normal" admin just picks the first package he finds and use it, and if it doesn't contain what he wants he goes somewhere else).

Though, I certainly like the modularity approach.
I think I wrote something in that direction as well, suggesting to make any the "non-strictly-forum" feature (calendar, likes, mentions, portals, etc.) isolated entities, attached to Elk using the same hooks/events any addon would use.
That alone would allow updates of the modules without having to update the "core".

Okay, "crazy" idea.
Each module could have the "toggle on/off" inside the core, but then the code is downloaded and installed only when the module is activated, and the download could happen from a github repository (for example).
And new modules could be introduced fetching a feed from github (with a cronjob).

And, yes, the news fader should definitely be something "external" (and it should be pretty easy to separate), and maybe more powerful.

And now I stop, because I'm already flying way too high. LOL
Bugs creator.
Features destroyer.
Template killer.

Re: Modular Approach (born from removing News Fader)

Reply #4 –

Quote from: emanuele – Though, I certainly like the modularity approach.
I think I wrote something in that direction as well, suggesting to make any the "non-strictly-forum" feature (calendar, likes, mentions, portals, etc.) isolated entities, attached to Elk using the same hooks/events any addon would use.
That alone would allow updates of the modules without having to update the "core".

This, this, this. Pretty much exactly. These features should be using the same hooks as addons rather than being heavily integrated. This would allow us to provide a "lite" core package which could be configured with extra features. Almost everything listed on the "Core Features" page of the admin panel should be an external module.

Quote from: emanuele – Okay, "crazy" idea.
Each module could have the "toggle on/off" inside the core, but then the code is downloaded and installed only when the module is activated, and the download could happen from a github repository (for example).
And new modules could be introduced fetching a feed from github (with a cronjob).

It would be fantastic to be able to install these from a Github repo. Much easier for the admin to toggle on and off too, and check if anything needs updating.

Re: Modular Approach (born from removing News Fader)

Reply #5 –

Quote from: emanuele – https://github.com/emanuele45/Dialogo/compare/elkarte:development...emanuele45:playing

In particular:
https://github.com/emanuele45/Dialogo/commit/8795d0de8d16613b467a2592275fd1c1dbefd0af
and an example oh how use it:
https://github.com/emanuele45/Dialogo/commit/c9f93ea2510677fb122928bd943b29f21b54e8ec
Cross-posting because this topic makes much more sense than the other. ;D

Still working on that, today I extracted the polls from the Post controller:
https://github.com/emanuele45/Dialogo/commit/000609c3a96734c99647f76219e04611568144f6
doing so I had to add few more triggers and optimize some stuff.

Next should be the drafts, but here I have a doubt: is it better to put the drafts as a "module" of the posting action, or maybe give them a completely different controller, that calls up some "validation" code from the posting?
Bugs creator.
Features destroyer.
Template killer.

Re: Modular Approach (born from removing News Fader)

Reply #6 –

Certain things like OpenID login which are related to very core functionality should stay in the core. Of course the team should try to avoid WordPressisms (my own word for huge features which are part of the core but are only relevant for 1/20 of the users at all).
-

Re: Modular Approach (born from removing News Fader)

Reply #7 –

Quote from: forumsearch0r – Certain things like OpenID login which are related to very core functionality should stay in the core. Of course the team should try to avoid WordPressisms (my own word for huge features which are part of the core but are only relevant for 1/20 of the users at all).

OpenID logins are certainly not core functionality. A site would function just fine without.

Re: Modular Approach (born from removing News Fader)

Reply #8 –

In that case, I'd say the log in is the "core" functionality.
Then the functionality can have different implementations that can be the "internal" (with user/pwd typical of ElkArte), or the "external" (OpenID, OAtuth, a bridge or whatever).
And OpenID is one of the core implementations of the log in function.
Bugs creator.
Features destroyer.
Template killer.

Re: Modular Approach (born from removing News Fader)

Reply #9 –

And with this:
https://github.com/emanuele45/Dialogo/commit/08741584927c86b4f8b98ee3e23cdbc7c7fd02f4
Post_Controller is down to 1644 from the 1.0 2346 lines!

And there are still other stuff to take care of. :D

ETA: yes, I know I'm only hiding the complexity somewhere else, but re-organization is the first step to understand what exactly is going on and where. ;)
Bugs creator.
Features destroyer.
Template killer.

Re: Modular Approach (born from removing News Fader)

Reply #10 –

Awesome work ema! Couldn't agree more on splitting up complexity.  At work I spent the better part of 1.5 years working on what we called the "blob". A huge project with over a 1000 files in it. I literally pulled over 70 stand alone projects out of this one project.  Now I've been working on removing inter-dependencies between them. Not fun... but soooo worth it now that I've had to alter/change/add code to the smaller projects. lol

You guys are doing so many great things with SMFElkArte that is has needed for so long. Still a long road ahead, just wish I could be more involved in it...

Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Modular Approach (born from removing News Fader)

Reply #11 –

Quote from: IchBin – At work I spent the better part of 1.5 years working on what we called the "blob". A huge project with over a 1000 files in it. I literally pulled over 70 stand alone projects out of this one project.  Now I've been working on removing inter-dependencies between them. Not fun... but soooo worth it now that I've had to alter/change/add code to the smaller projects. lol
That was a hell of a spagetti-code!! LOL
Bugs creator.
Features destroyer.
Template killer.

Re: Modular Approach (born from removing News Fader)

Reply #12 –

I'm going to get carried away pretty badly on this... almost like (or even more) than Norv in certain circumstances LOL.

Just today, I did some more stuff, approaching the admin panel as well, in particular:
https://github.com/emanuele45/Dialogo/commit/9c46316c990e1b6cd8cf0952480573e0c80f1bd9
and:
https://github.com/emanuele45/Dialogo/commit/ab21cb6f91aa1b6f8eb9fbf8b93af31e33aa071e

What do they do?
Instead of adding entries directly to the core features array, for example, the code "autoloads" core features:
https://github.com/emanuele45/Dialogo/commit/9c46316c990e1b6cd8cf0952480573e0c80f1bd9#diff-164bf3b768f714cbe8623c6dc556692eR291
it uses file name pattern and a static method:
https://github.com/emanuele45/Dialogo/commit/9c46316c990e1b6cd8cf0952480573e0c80f1bd9#diff-1f8b3d2604cab5d04aa205c77628f680R35 (this is for the drafts for example)
the same applies for the menu entry:
https://github.com/emanuele45/Dialogo/commit/9c46316c990e1b6cd8cf0952480573e0c80f1bd9#diff-79a5e5f23e833f0d50fc481fd8e59cbbR581
and:
https://github.com/emanuele45/Dialogo/commit/9c46316c990e1b6cd8cf0952480573e0c80f1bd9#diff-1f8b3d2604cab5d04aa205c77628f680R55

What do you think?
And in particular, what would you think to extend this to any other "core feature"? (Renaming the "Core Features" page to "Modules" or something like that.)
Bugs creator.
Features destroyer.
Template killer.

Re: Modular Approach (born from removing News Fader)

Reply #13 –

Holy crap ...

 Spuds marks this as unread as I've had to much wine to comment !  :P

Re: Modular Approach (born from removing News Fader)

Reply #14 –

LOL
Bugs creator.
Features destroyer.
Template killer.