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
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