Sorry for my bad english, and I did a lot of typo's (that's what happen when we try to write as fast as the brain thinks). One last question, why don't you use interfaces guys? From all the oriented object programming code we could get, this is the only one that would make pattern really clear to anybody and which would give the envy to developers to make data that is really part of the greater. Pierre.

On Fri, 2011-01-21 at 22:11 +0100, Fehér János wrote:

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.

OOP does mean slower. In fact it's all about sharing and mutualising code. In a PHP context where code is interpreted before being executed at each client hit, it can save a lot of CPU time. Interface is not a finality by itself, it's just a way to define in a really clear, clean and minimal design. Using interfaces can show you in a few lines of code the flaws of your own design quite easily. It's all about brain storming and creating clear design before going through the ugly implementations. Still, I can sometime understand why people don't like it. For a lot of compilers it's also a mean to reduce CPU time consumption at compilation time by doing shortcuts and assumptions on the implementation below without having to do the full class hierarchy definition vertical traversal. It's also the base of the SOLID principles aggregation of design patterns. OOP wouldn't be a mess since it's actually becoming a fully oriented OOP code. See the Entity API module which, I think, really goes the right direction. Using a interface in well built code means that you now how it will behave relatively to the API around. It does not mean you are not allowed to read other's developer's code.

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 :)) ).

You are right, never mess up with people culture. But we are talking about code here,. Every developer whatever is its culture sucks when maintaining an software that as thousands of duplicated code in every piece of it. Also, one UI to rule them all doesn't mean you can't theme it differently depending on the context. A form definition is only a form definition. What the form looks like is what the theme layer makes it looking like. And, FYI, I found a lot of things sexy, but not the Drupal administration (I have a real body you know?).

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

Centralization does not mean you cannot override. In fact, using interfaces and override, and using some clean design pattern you can make a robust nevertheless heavily pluggable code, this is not an valid argument to me.

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.

That's true, this is highly discutable, and my proposal here is not the definite solution. It's the reason why this thread exists, because we all have valid opinions on the subject. Having a technical common base does not mean the UI can't differ.

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.

If you need a framework, look at code ignitors or zend framework, and dont forget that Drupal is a CMS, therefore (not today, but will I hope be) a fully featured business software, which primary goal is managing content. If you do radically different implementation for each tiny piece of data you'll manage, you'll reach a phase where you won't be able to maintain it anywhere and where a bug fixed somewhere will always create a new one elsewhere. Don't forget that a common API doesn't mean you can't build a totally depraved or totally awesome and funky UI. It will even be easier with less code behind it.

-- Aries

Thanks for your answers, it's interesting, always looking forward to discuss topics like this one :) Pierre