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

[Fehér János]

2011/1/21 Pierre Rineau <pierre.rineau at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110121/cd877ef7/attachment-0001.html