Terminology of block regarding the WSCCI initiative

One of the main reasons I've been using "blocks" is that I can't keep track of all the different nouns that Panels uses (content type? pane? content pane? I'm always confused by them), but people know what "block" means. We're just making SmartBlocks(tm). :-)

@DjebbZ

I'm sort of on the same page as Crell here, I don't think that it's problematic that the concept of what a given Drupalism is might change from version to version (hopefully incrementally and for the better). That being said, I don't hate "fragment" but I do wonder if it might have some confusion associated with it as well in the long term as a high level conceptual Drupal component.

Eclipse

While I understand the confusion that might arise when talking about blocks and requiring some mental re-contextualization depending on the Drupal version at hand, I concur that 'block' (in it's new, smart flavor) correctly describes what WSCCI is aiming to achieve with the new system. However, I personally do not dislike 'fragment'.

JSON and other non-HTML things are not blocks. "Thing that responds to a request with a response" are called "Controllers". A Controller whose response is an HTML fragment is called a block. node/1 application/json = the JSON Node *controller*, not a block.

I expect that Block will probably be a literal subclass of Controller by the time we're done.

Does that make it clearer?

Uh, no, it just confused me even more. :-)

class Controller { 
  public function returnResponse() {
    // Could be anything, but should be wrapped in a Response object.
  }
}

class Block extends Controller { 
  public function returnResponse() {
    // Could be an HTML string, but should be wrapped in a Response object.
  }
}

class JsonController extends Controller {
  public function returnResponse() {
    // Some JSON string, but should be wrapped in a Response object.
  }
}

I don't see why there's a need to introduce the word Fragment anywhere. The one and only case where we actually return a fragment of something is a fragment of HTML, and "blocks" is already adequately clear there.

"Block" doesn't make too much sense currently.

But with the change proposals for D8, "block" will make much more sense.

"Block" is also superior to any other term, especially if you imagine the not so uncommon case of talking to your customer, where you need to use some sort of understandable linguistic subject that the Average Joe is able to relate to.

E.g., "That block of links below the logo..." doesn't necessarily make technical sense right now, but will make perfect technical sense in D8.

This issue won't fix for me.

The only other nouns I've seen used elsewhere, IIRC, are "widget" (which is already taken in Drupal) and "gadget" (which no one used except for Google). So, yeah, I'm also inclined to won't fix.

I've got a question about the future of Drupal layout.

I've read all three reports and listened to Crell on the Modules Unraveled podcast. I also just came from an EXCELLENT HDUG Meetup where the speaker was discussing his use of Panels.

For someone (like me!) learning more about D7, would learning more about how to use Panels and the theory behind it be beneficial re: being prepared conceptually for D8? Because it seems that D8 layout is going to be moving away from the approach used by what we currently call Blocks and looking more (at least conceptually...I heard Crell when he said the code would be very different) like what we currently call Panels. So, to my mind, it seems like groking Panels NOW (especially conceptually) would be a wise investment.

Is that accurate or am I missing something?

Transition: At a conceptual level, yes, learn how to use Panels and Panels Everywhere.

The implementation will be (hopefully) much cleaner with a much much better UI by the time we're done, but the 50,000 foot concepts are similar. Symfony2 is built on similar concepts, too, abstracted even further.

At the risk of sounding totally naive... You two keep referring to this new block as SuperBlock to clarify. So, why not just call it that? I don't know about new folks but I think when you say "block" in a Drupal context to anyone who's been around a while, it conjures up a certain image. A new name for a new thing would be nice and this retains the "block" idea but makes it clear that it's not your father's block... :)

If not SuperBlock maybe FlexiBlock? *ducks flying rotten vegetables*

Michelle

I think calling it "superblocks" either colloquially or as an initiative name makes perfect sense, but from a "terminology I actually want committed to drupal core" perspective "Block" continues to work just fine for me. Just because we rebuild the foundation of nodes and user and comments to all be entities doesn't mean we renamed those components. This is a foundational change for blocks and block positioning, and I think we should just be really honest about the fact that this is still blocks, even if they'll be comparatively awesome.

Also, on the topic of non-block responses, chances are when dealing with ESI or similar solutions we'll end up referring to "Block Responses" as the natural language for individual block... well responses. Similarly json response, atom responses etc seems quite straight forward to me and very descriptive of what we're getting. At the end of the day, the goal is that it all be various responses.

Eclipse

It's a little more complicated then that, but not much.

Entities contain content.
Blocks display output.
Output can be content (context) sensitive.

The important thing to note here is that not all output is content. The "powered by drupal" block is arguably NOT content (nor an entity) but it is output. Best to keep the separation as clear as possible, but hopefully this is not too convoluted.

I think "block" is fine, we'll just have to get used to the idea that a D8 block != D7 block.

By the way, let's not forget that fragment already means "the part of the URL after the # character". It could get confusing if people assume that URL fragments and block-fragments are somehow related.

The small problem I see with fragment is that it doesn't sound like a complete/whole object, but only part of it. It sounds "jagged" or broken, not complete. Explaining this to a newbie may sound like:

"The module will return a HTML fragment."
Newbie, "I don't want a fragment. I want the whole thing."

It may make sense in relation to the page, a page is composed of multiple fragments. But, when all you want is a JSON response, then just returning a JSON fragment sounds incomplete.

Yeah, it sounds like "fragment" is dead. So...

I've seen other systems refer to "boxes of stuff on the page" as modules more often than anything else (at least in the UI). Attached is a screenshot of the youtube dashboard. I started collecting screenshots of other systems use of the word "modules" to mean what drupal calls "blocks" in an effort to rename modules in Drupal to something more like plug-ins add-ons or extensions, (I'm not recommending we rename blocks to modules!).

People do relate "blocks" to "building blocks" which will be more true in D8 than ever before.

Also, as an update to this, while I still support "Block" the other obvious competitor to the name that has emerged is "Component". We'll see what happens as we go forward, but I just wanted to toss that out there.

I like "blocks" because it fits with the whole "Drupal = Legos" thing. "Component" has an advantage, to me, though, in that it has a slightly different connotation that is perhaps more important. I tend to think of "blocks" like atoms. They are single "thing" not made up of anything. One Lego block/brick is a basic unit of building. Components, on the other hand, sound as though they could be more complex building blocks. Take a little Lego person (one "block"), add a hard-hat (another "block"), add a shovel (another "block") and you have a construction worker "component" that can be fitted together with a truck component (made up of blocks) and other components to make the whole scene.

In Drupal's case, a block (in the more generic sense not tied to block module specifically) can be a very simple basic building block but, more often, is made up of smaller blocks such as a title and a view (which is further made up of smaller blocks with fields, etc).

I would stay away from "module" even if other software uses it. Yes, I understand we want to make Drupal easier to use for outsiders but, in this case, I think the "hardship" of outsiders having to learn a new word is better than the hundreds of thousands of existing users suddenly having to retrain themselves about what a module is. The term is just too ingrained in our culture to suddenly switch it to mean something completely different. And, then, we have a whole new bikeshed on what to call the Thing Formally Known as a Module. ;)

Michelle

Resisting the urge to quote Phil Karlton here.