[development] D8: Merge taxonomy, book and node modules?

[Pierre Rineau]

On Fri, 2011-01-21 at 19:24 +0100, Daniel F. Kudwien wrote:
> The missing puzzle piece that prevents this change from happening is what
> we're trying to flesh out in the Relation project:
> http://drupal.org/project/relation - still pre-alpha, still bound to major
> API/design changes, but we're slowly getting there.
> 
> sun

This relation model should belong to entity system itself. Every piece
of content, even images or remote videos (such as youtube or another)
should be a "content" and not "field".

Objects should all respond to a common interface to develop only one UI
to rule them all, only one storage mecanism, only one rendering process.

All objects should have build modes, fields, and such, and should be
taggable. Tagging is a really specific feature and should be part of the
Entity API instead of living as pieces of content, tags are not content,
they only are tags. Plus, the actual implementation is full of nonsense
because they are exceptions (entities without bundles, there is
exceptions in the EFQ code for them, it's written big in the code
comments) while the core taxonomy developer had to denormalized the
schema a create content redundancy in database. It makes the life harder
for developers.

With a more centralized model, Drupal would finally become a CMS (which
he is not since a long time ago) and all WYSIWYG / Views (yuck) / Media
handling / Display / UX would be common and easily maintainable and only
specific rendering or fetching implementation (and some other minor
specific code base) would live with implementations themselves.

The fact that node still have their own forms and save method show that
the actual D7 design is an horrible mess, while the Entity system proves
that some people are trying to make it right and efficient, but the
field and entity systems should be tied together, and should live in the
same API not in twice.

Putting images in field is somehow a really really bad idea where
ideally, to do an efficient UX for users, all images should be content
themselves which should really simplify the process of making galleries
and common WYSIWYG selectors, common input filters, and common
relational model, etc etc.

Users don't really care about what it their data and how they should
display it. They only one to display stuff they find funky or cool, but
if the UI, API, way of handling these stuff is different for each nature
of data we can find, it will really bore them. They won't understand and
they won't enjoy.

This is my dream, you are totally can disagree with me. It's not
critiscism or anything, it's only a point of view.

Pierre.