Skip to main content ↑ ↓
Topic: Blocks or widgets (or something) (Read 3414 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Blocks or widgets (or something)

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, 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).
Bugs creator.
Features destroyer.
Template killer.

Re: Blocks or widgets (or something)

Reply #1 –

Nice thinking..

Re: Blocks or widgets (or something)

Reply #2 –

I think its a good idea.   I was thinking about this a bit when the team page request came up, thats kind of a block in a way and something the portal or portal-like think could do.

Re: Blocks or widgets (or something)

Reply #3 –

Separating the block codes for SimplePortal has been in my list of things to do for years, but I never got around to doing it. I really like what you did with it there. We also wanted to separate the markup and the idea was to allow admins to define custom templates for the blocks they add.

I'm not sure what kind of blocks you want to include in core but having generic functions for loading such data would be very useful. I relied on functions from SSI.php as much as I could in SimplePortal and that made maintaining those blocks a lot easy.

Re: Blocks or widgets (or something)

Reply #4 –

Quote from: [SiNaN] – We also wanted to separate the markup and the idea was to allow admins to define custom templates for the blocks they add.
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:
Code: [Select]
	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
Bugs creator.
Features destroyer.
Template killer.

Re: Blocks or widgets (or something)

Reply #5 –

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.
Bugs creator.
Features destroyer.
Template killer.

Re: Blocks or widgets (or something)

Reply #6 –

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

Re: Blocks or widgets (or something)

Reply #7 –

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

Re: Blocks or widgets (or something)

Reply #8 –

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

Re: Blocks or widgets (or something)

Reply #9 –

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.
Bugs creator.
Features destroyer.
Template killer.

Re: Blocks or widgets (or something)

Reply #10 –

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

Re: Blocks or widgets (or something)

Reply #11 –

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.
Bugs creator.
Features destroyer.
Template killer.

Re: Blocks or widgets (or something)

Reply #12 –

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