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.
