<br><br><div class="gmail_quote">2011/1/21 Pierre Rineau <span dir="ltr">&lt;<a href="mailto:pierre.rineau@makina-corpus.com">pierre.rineau@makina-corpus.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, 2011-01-21 at 19:24 +0100, Daniel F. Kudwien wrote:<br>
&gt; The missing puzzle piece that prevents this change from happening is what<br>
&gt; we&#39;re trying to flesh out in the Relation project:<br>
&gt; <a href="http://drupal.org/project/relation" target="_blank">http://drupal.org/project/relation</a> - still pre-alpha, still bound to major<br>
&gt; API/design changes, but we&#39;re slowly getting there.<br>
&gt;<br>
&gt; sun<br>
<br>
</div>This relation model should belong to entity system itself. Every piece<br>
of content, even images or remote videos (such as youtube or another)<br>
should be a &quot;content&quot; and not &quot;field&quot;.<br>
<br>
Objects should all respond to a common interface to develop only one UI<br>
to rule them all, only one storage mecanism, only one rendering process.<br></blockquote><div><br></div><div>What is the benefit of interfaces? Currently there&#39;s a more or less clear way how</div><div>an entity could be created and modified. With OOP method, it would be a mess, since</div>
<div>the object could be very different in each implementation. In a desktop app this could be</div><div>tolerated, but in a web app, the resources are more limited, you cannot be such lazy. Again,</div><div>i&#39;m not against the language structures, but the possible mistakes.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
With a more centralized model, Drupal would finally become a CMS (which<br>
he is not since a long time ago) and all WYSIWYG / Views (yuck) / Media<br>
handling / Display / UX would be common and easily maintainable and only<br>
specific rendering or fetching implementation (and some other minor<br> specific code base) would live with implementations themselves.<br></blockquote><div><br></div><div>Every country has different visual culture. I don&#39;t believe in the &quot;one UI to rule them all&quot;.</div>
<div>(Imagine Pierre, all of my french clients found the default admin interface of Drupal &quot;isn&#39;t</div><div>enough sexy&quot; for a serious use :)) ).</div><div><br></div><div><div>It would be better to make the default UIs (like node form, admin interface) as option and</div>
<div>replaceable. I had several projects, where the client had different idea about the UI and admin UI. As</div><div>a plus, most of the times, the admin UI had to sit on different server (at the editorial intranet).</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Putting images in field is somehow a really really bad idea where<br>
ideally, to do an efficient UX for users, all images should be content<br>
themselves which should really simplify the process of making galleries<br>
and common WYSIWYG selectors, common input filters, and common<br>
relational model, etc etc.<br></blockquote><div><br></div><div>I disagree. But, you&#39;re right, that would be nice to have a widely accepted Image</div><div>content type (maybe as a &quot;feature&quot;), what has Image field(s) and default derivations.</div>
<div>The current (field) solution is much lightweight than a content type. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Users don&#39;t really care about what it their data and how they should<br>
display it. They only one to display stuff they find funky or cool, but<br>
if the UI, API, way of handling these stuff is different for each nature<br>
of data we can find, it will really bore them. They won&#39;t understand and<br>
they won&#39;t enjoy.<br></blockquote><div><br></div><div>I have to refuse this. My clients wanted more customizable, more slim, less bloatware Drupal.</div><div>This can be achieved by smaller building bricks and this can be a benefit for your demands</div>
<div>too, because there can be a more unified UI for your clients, and an editorial version for my ones.</div><div><br></div><div>--</div><div>Aries</div></div>