This is a re-think of some Drupal things. It's not yet a coherent vision. Coding this would probably require starting from scratch, taking (significant) pieces from Drupal as you go.
Entities and fields. That's the world. There is hardly anything else but entities and fields.
A page is an entity. The default formatter is a HTML page with regions. One bundle of pages have a field named 'content' which is simply an entity reference field. It has several multivalue block-reference fields for fields like sidebar_left, sidebar_first and so on. Noone stops you from changing the formatter. Also, create another bundle as you wish.
When you create, say, a node, an according page entry is auto-created but this is totally optional and configurable which entity types bring pages and which don't.
This totally eliminates the routing system.
Tabs? Tabs were always called 'tasks' so let's name them tasks. You can define tasks on entity types, bundles or specific entities even.
Further ideas forthcoming but I needed to get this out of my head.
sun: Doesn't fully work for me; unless we're talking Panels Everywhere, which only works for a small sub-set of sites. (Again, missing comments on wiki pages.)
Comments
It depends on what we want Drupal to be.
I feel strongly for this idea, but also against.
I think that if Drupal is going to be successful as we move forward, we need to decide and agree on what moving forward means. Do we keep writing code to scratch every new itch? Simply evolve and move our way up the hill? What happens when we find ourselves at the top of this hill, and see the mountains in the distance?
Do we decide what the ideal Drupal would be and attempt to build it? What do we do during the transition period, when the ideal isn't met but we need something to apply to real-world problems?
This idea seems more like the latter to me, and I'd like to say that we should stick to the former (although obviously, there will be compromises). Drupal isn't the most elegant it could be, it's not written in the best language, it's not the most flexible or capable. There are other projects trying to do those things, and I'm not using them because Drupal is more useful and practical in the widest variety of my use cases.
That's not to say that there
That's not to say that there couldn't be enough people that have enough itches that this change won't eventually be necessary. I just don't think it's the case right now.
Concrete example?
Is there something you could not build with this model? What needs to be added? I am trying to simplify Drupal while keeping what's good.
What about this makes the
What about this makes the model easier?
Here are a few
No routing system whatsoever.
And yet, greater flexibility as each page exists as a separate entity and so can be formatted and fielded as needed.
And yet, greater flexibility
That's more or less the point. Since Panels was born, Drupal started to have two entirely different concepts of filling pages:
These are two fundamentally different concepts, which are very hard to intermix. But for the sake of this thread, those panels pages are exactly what you're proposing here: different entities, being able to fill in regions + blocks of the theme.
The main difference is that one needs to presume that every single page entity is fully configured individually, to not only fill the page title and main content of the page, but also all other regions on the page. This mainly works for small brochure sites, or, when considering CTools' Page Manager, it also works for "page classes", i.e., all pages viewing a node of content type "article".
It starts to get blurry when you want to display things/blocks on all pages, including page entities. Because one-time region content needs to be mixed with all-time region content, respecting order/weight, access, and potentially other criteria.
Daniel F. Kudwien
netzstrategen
default values
I presume that we would have default values for the page entity fields and to faciliate displaying stuff across pages.
Note that what I suggest might be close to Panels on a high-level but on an implementation level it reuses most of what we have now.
Routing
How do you plan to choose entity when new request comes to system? Entity URI