2011/1/21 Pierre Rineau <pierre.rineau@makina-corpus.com>
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.
What is the benefit of interfaces? Currently there's a more or less clear way how an entity could be created and modified. With OOP method, it would be a mess, since the object could be very different in each implementation. In a desktop app this could be tolerated, but in a web app, the resources are more limited, you cannot be such lazy. Again, i'm not against the language structures, but the possible mistakes.
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.
Every country has different visual culture. I don't believe in the "one UI to rule them all". (Imagine Pierre, all of my french clients found the default admin interface of Drupal "isn't enough sexy" for a serious use :)) ). It would be better to make the default UIs (like node form, admin interface) as option and replaceable. I had several projects, where the client had different idea about the UI and admin UI. As a plus, most of the times, the admin UI had to sit on different server (at the editorial intranet).
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.
I disagree. But, you're right, that would be nice to have a widely accepted Image content type (maybe as a "feature"), what has Image field(s) and default derivations. The current (field) solution is much lightweight than a content type.
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.
I have to refuse this. My clients wanted more customizable, more slim, less bloatware Drupal. This can be achieved by smaller building bricks and this can be a benefit for your demands too, because there can be a more unified UI for your clients, and an editorial version for my ones. -- Aries