DrupalCon Prague 2013

El futuro de Drupal pasa por Composer

Kris Vanderwater  · 

Transcripción

Extracto de la transcripción automática del vídeo realizada por YouTube.

this is core conversations composing Drupal's future it's just going to be me Larry and classy exactly awesome all right well we're up against who really awesome sessions right now no there's Angie Angie's doing angie oo quia whatever is

upgrade your module to d8 and there's the B hat lab going on right now as well yeah its front end packet man package management yeah I have no idea are you asking me to justify you leaving my session oh no no no totally not yeah no i don't i don't

think so at all so okay well um i am going to get started then this is a composing Drupal's future look at that it's good stuff in it I probably should have filled in I'm Chris Vander water I'm with Commerce guys I'm a senior developer

there um I am at eclipse GC on twitter i'm also the drupal 8 blocks and layout initiative owner commonly known as scotch i do a little bit of maintaining of CTools whenever i can get around to it and a little bit of maintaining of my own module context

admin you know when i feel like it so those are just some quick about me welcome I want to talk a little bit about the objectives that I have for this conversation because what I'm suggesting here is kind of crazy to a certain degree and kind of sane on

the flip side of that coin but at the same time I think it's good to lay out some objectives that I would like to see both for the conversation and if ultimately we end up doing this for Drupal in general so the things that I really want to hit here are

component ization and what that means to me in terms of Drupal and PHP and general interoperability both with our own components and with other components and then wouldn't what I hope that ultimately leads to which is the ability to give us more influence

in the greater PHP community through Expo exporting our code and our culture to them and ultimately our expertise so let's talk a little bit about component ization here symphony has a definition for this and I looked for a little while to find it and

so I'm just going to read this to you symphonies definition of components is this symphony components implement common features needed to develop websites they are the foundation of symphony full stack frame work but they can also be used standalone even

if you don't use the framework as they don't have any mandatory dependencies that's a very interesting kind of mission statement almost for the code that they're building and so so I looked around then I said well does Drupal have one of these

and I didn't find one at first so I made up my own and so that's why there's ? here i said maybe drupal components provide common features needed from modern CMS they provide the foundation of Drupal but can be used stand alone with limited dependencies

there is actually a definition for this if you go looking within Drupal component which I happen to have open right here so the official Drupal statement of what a component is is this dribble components are independent libraries that do not depend on the

rest of Drupal in order to function that I am reading from a readme in Drupal core by the way what are you doing males telling me I need to be doing stuff probably go away okay that's what I get for not closing everything components may depend on other

components but that is discouraged components may not depend on yeah blah blah blah you can read this it's in here I'll show you where it is it's in core lib Drupal component readme.txt right suffice it to say we have one and of course why me so

I kind of wonder what PHP's definition is for this I couldn't find one but I bet it's something having to do with this work stand alone and you can just use it right because that's what the rest of our good examples here are kind of getting

at so let's talk a little bit about Drupal 7 we've kind of done this before to a certain degree includes we're kind of components some of them were swappable you could write your own include file that had all the exact same function names and then

swap out certain things like say maybe session or there were a few of these password was the more common one I actually wrote a module to do that for you and was very scared when I stopped hatching passwords and just saved them clear text yeah yeah modules

are kind of sort of this idea right you know at least if you think of it in terms of Drupal when you go asking for a module you say I expect this self-contained bit of code it may state that it has some dependencies on other stuff but it's going to slot

into the system that I'm choosing to use and it's just going to work there so this is you know conceptually not that different so to a certain degree we kind of invented this before PHP got around to it and i'll show how PHP's gotten around

to it here in Drupal 8 we have very consciously chosen to begin component izing things and so the real components live in drupal component which was the readme i was just reading from and then there are extensions of those and some more standalone things like

database TNG that live in Drupal core and ultimately I think we can probably start to really seriously component eyes all of these things because what these encapsulate to some degree are a no assumptions feature component of a system like drupal and then

our Drupal core code is basically the Drupal assumptions layered on top of that and that's actually kind of a valuable thing what we haven't done is we haven't really begun replacing it with regard to modules modules are still modules are still

modules we have a dot module file the dot module file can have hooks in it more importantly when you look at a module modules can have classes in them and these classes can be componentized in the exact same way that code within core can be componentized that

problem is is that they aren't abstracted enough to be reused they exist within a drupal module so they are bound to Drupal and as we've shown with a few interesting pieces that have gone into Drupal 8 that doesn't necessarily have to be the case

for example date module doesn't really exist because we have a date component now there may be a module that interfaces it to Drupal I I don't know I think there probably is four fields and those sorts of things but in terms of of really beginning

to adopt with the rest of PHP is doing you look at Symphony and their bundles and and they're not the only people doing this but they're the one we're going to identify with the most Symphony bundles are very very close to being Drupal modules

in many respects only they have some advantages we don't have like being able to generate a class map because all of their bundles are inside of their composure documentation so so I'm standing up here asking a couple of questions and amongst them

is do we even need module files in Drupal 8 the answer is yes because we haven't gotten rid of hooks but in Drupal 9 maybe maybe not so let's talk a little bit about interoperability if we didn't have any modules how do we operate both with ourselves

and with the rest of the world right because we've done this for so long you know that becomes a really important question to answer and so the first step in doing this is to really begin conforming conforming to a namespace space named spec right and

we're doing that in Drupal 8 in fact our modules are doing it now if you open up a class that's inside of a module that class has a full name space based upon that module already in there so views for example if you've ever looked at a views class

of which there are many they will have a name space on them that tells you this came from views right I don't need to get too detailed with that just suffice it to say you can just look at any individual class and have a really good idea where it came

from because they have independent naming mechanisms built in and this is something that was developed outside of Drupal we just adopted it so when I start talking about component ization this is what I'm talking about these things which are already namespace

they can't by design collide with anything that's not just named identical up at that very high level and and there are some interesting things to help you separate that apart too we can leverage symphonies of event dispatcher or something similar

event dispatching is babe basically giving classes the ability to respond to hooks instead of having a dot module file that responds to hugs and that's really compelling on a number of levels especially because it means that every class in your in your

library of classes could potentially respond to a given hook it's not likely that it would and only classes that implement certain interfaces can but what it means is that a collection which we think of as as a module could actually subscribe multiple

times to the same event we cannot do that in hooks right now you have switch statement and you have to follow logic and figure out what's going on and we did a lot of things to mitigate that during the d8 cycle but there's still plenty of it there

and a full-on adoption of the event dispatcher out of symphony gives us the ability to do away with dot module files by and large and it gives us the ability to really begin packaging up our individual software components in such a way that they could be run

[ ... ]

Nota: se han omitido las otras 4.759 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.