2011/1/21 Pierre Rineau <pierre.rin...@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
