ElkArte Community

Few days ago I was staring at SimplePortal PortalBlocks.subs.php and its 2800+ lines of code and I realized I wanted to split it up.
So I thought about it a bit and pushed this "demo" commit (https://bitbucket.org/emanuele45/elk_simpleportal/src/718f2ee101042781233b6c35cb27065e2f256919/subs/spblocks/UserInfo.block.php?at=running_wild), where each block is a file and there is a bit of separation between logic and template (you know, re-use and stuff like this :P).

Yesterday evening, then, I started thinking "hmm... maybe a sidebar could be interesting and useful after all", and so I started coding a quick addon for it (I'll push the code later today, it's very basic, it doesn't even have (yet) the admin panel). Writing this addon I faced mostly the same problem: I needed blocks.

And here it comes the proposal: blocks as part of the core.
But why would we need blocks in the core? Good question, I'm not sure yet. An example would be to provide a sidebar and some blocks to begin with.
The general idea, though, it's to provide a common (very simple) interface to blocks, so that they can be shared among different components. For example: SP and the sidebar, or two different portals, or... anything else.

And what does it mean "blocks as part of the core"? Well, nothing too complicated. Just an interface and/or an abstract class to define the basic needs of a block "version 1.0" (in the example above it would be an interface that defines three methods: settings, setup, render, I have in mind other things that may be handy) and a place where "drop" the blocks (that would be a directory in subs).

Yep, I was thinking something like this as well.
While writing the sidebar code I ended up (but it was late at night) with something like this:

	foreach ($context['sidebar'] as $object)
	{
		if (isset($object->template) && function_exists($object->template))
		{
			$function = $object->template;
			$function($object);
		}
		else
			$object->render();
	}

The main idea would be:

• provide a default rendering method inside the block itself (the render method),
• if the block defines a possible template (property $object->template), and the theme provides it, then use it to render the block (passing the object because I was being lazy and anyway I added a getter. :P).

The reason behind keep a rendering method within the object with a default view of the block is to keep it simple and self-contained, so that if people just want to write their own block they don't have to mess around adding at least two files for it (class and template).
As a plus, having the default as a method avoids any function names conflict. :D

Another random thought on that one: two already existing spots that may benefit from this are the info center and the statistics page.
In both cases, each "block" can become a stand alone widget with a way to decide what should be active and what not.

Too much free time, Emanuele? What about the project "changing image BCC after relaunch for use without aeva media gallery"?  ;)

I posted a package and didn't get any feedback either good or bad, so I got carried away by other stuff. ;)

Oh, really? Oops, sorry! I lost track of it too.  :-[ :D

Back for a second on this one, today I had the crazy idea to touch SSI and experiment how to move those functions to a block-like-class-based approach, similar to the SP blocks (coding-wise, not really presentation-wise), and the outcome is https://github.com/elkarte/Elkarte/compare/development...emanuele45:SSI?expand=1

First thing to say: it doesn't work (I didn't configure the autoloading, so it won't find the classes to load, but that's easy to fix if needed).

At the moment the intention would just be to convert SSI to something like SP blocks (let's remember that at some point, SSI will become just a "demo" of how to use bootstrap.php, that will be the "right way" to do integration), not really create any widget-like stuff.

Breaking down SSI to manageable chunks which can be easily be added to, certainly has it merits :D

To be fair, it's a little overly complicated for SSI, though, having a structure that can be shared with something else to me is worth the little more complexity.

Of course my will to update the portal again is weak !