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

[Pierre Rineau]

On Fri, 2011-01-21 at 22:11 +0100, Fehér János wrote:
> 
> 
> 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.

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