 Hello, do you hear me? Hello everybody? Okay So welcome to my session to about to realize your data use entities My name is wolf could see girl. You might know me as Fargo as my nickname. I'm trouble Don't work. I'm a triple developer from Vienna, Austria And I've started there at the technical University at Vienna I started computer science and I'm doing triple since 2005 You might know me from some country projects. I'm maintaining Like the rules module field collection over to or the entity by module and I'm also one of the maintenance of the form API and entity API cross up system subsystems Yes, today, I'm going to talk about the entity API in 2.7 and I'll start with a short introduction about entities and then I'll show you how you can interact with entities and I'll also show you how you can provide a new entity type based on on the database and how you Can use the entity pie to expose non database based and data as entities to the system and At the very last I will have a short outlook in to the future and see What's going on in triple 8 and how the entity pay is going to evolve there? Okay So in triple 7 I think really the the main major shift Has been that we can use fields. We are basically everywhere So with that there has been The introduction of a new foundational object, which is basically What I entered is now? the foundation objects that are field able our own entities, so Every Object you can put fields on is an entity, but there are also entities that are not field able So you can still use the entity private fit you can save it load it and so on but it can't put fields on it So fields are optional So in in triple 7 in addition to entities. There's also that concept of bundles. So a bundle is basically I would say the subtype of an entity type It's best explained if we compare have to look at the analogy Of nodes so in the case of the entity type node The bundles are the node types So really the bundles that the mine the fields you can put on a certain entity or on a certain node Well, if we have a look at another entity type At taxonomy terms here that vocabulary at terms belong to that the mines the bundle so Also, they vocabulary that the mines which fields you can use on the term and Another example would be the user accounts in triple 7 Which don't have different bundles. So there's Just one set of fields you can put on different user accounts Yes, that's it. So in in Drupal Corp. We have Multiple entity types. So we have comments. We have nodes or the user accounts entities as well as taxonomy terms vocabularies and fields But not all of those are field able so vocabulary and files aren't field able in in Drupal Corp itself but In addition to that Contrib modules can define new entity types and a lot of modules make use of that possibility like Drupal commerce which extends a bunch of It's a bunch of entity types like products orders and so on also organic groups or makes use of entities for example give me ads and Membership entity for storing organic group membership information Then there's the profile to module. I'm also maintained off which implements user profiles as separate entities And the heartbeat and message modules are used entities to store activity stream and tries or general messages as separate entities and Lastly the file entity module doesn't really introduce a new entity type But it changes the existing entity type which is in core the file entity and Makes it field able So as we see there are kind of different modules that add father entity types to the system but There's even more there are lots of modules that build on the concept of entities without Providing a new entity type. So I would say since triple seven There's really a big shift which goes on if we if you think about Triple six and beyond most content modules you download it Basically worked with nodes. So if you download it for example give me a voting module You would expect it to work on a node, but with triple seven There's quickly there's really now the shift from node centric modules the entity centric modules If you download a content module in triple seven you ideally expected to work with basically every entity or at least every field able entity and Really expected to continue and that's the future. I think for Drupal So you might wonder what you can use the entity API for now So it's basically a unified way to access the data of Drupal so all the data that Drupal has is exposed as an entity and that way modules can make use of it easily the following diagram Shows how the relationship is so on the on the right side. We basically see a solution modules like A model which explain implements a search functionality or voting or grouping like the organic groups module There's also an entity reference module which makes it possible to reference arbitrary entity types Just like you know it from no references. What is the rules module which also? supports dealing with Every entity type and all of the of those modules work generally with entities There's an entity can be and basically any data type that is Exposed as entity to Drupal so there are users nodes comments, but also profiles and products So the extended entity types that country modules provide work the various and way and this is very neat because we don't have to write integration between each of those but the solution modules can concentrate on Doing the integration for entities and the data providing modules just have to make sure that they probably provide the data as an entity And then they will automatically gain the functionality of all the solution modules So how can you do this? How can you do a solution module that works with any entity type? For this the contrap entity by module is a great help I'm also the maintainer of this one and The contrap entity appear module basically assist you well with interacting with entities and also with Providing a new entity type so we'll start with the first one and This is basically an overview over all the functions or the helper functions that are available around entities and in the inner circle Drupal core we see in core we have mostly a way to Define entity information so to define To declare metadata about the entity and a way to load entities There are also some other helper functions like way to get the label and the UI, but that's basically it So in Drupal core you have the functionality to load an entity, but the entity appear module Cares about extending that to full crowd functionality. So there are helpers To create an entity of an epithelial type also to delete Those entities auto-save them Then there are helper functions like entity view and entity access Which allow you to render an entity or to check Access information for it and there's the function which is called entity get property info Which tells you which properties an entity type has and This functionality is also used by the entity made the data weppers which Graded with the entity made the data web of function and these weapons are basically helper objects that Make it easier to interact with entities and make it easier to make use of all of that Functionality by wrapping the entity object into another object and basically Works the way that way as we seen in the first line you Create the wrapper by using the entity meter that the wrapper function Tell the function which entity type you want to wrap and you pass to it The entity ID or the the full entity object and you will get a wrapper and you can work just with the wrapper For example given if you have a wrapped node as in this example You can easily access the node orders mail address just like by just like by accessing the entity properties Directly and by accessing the entity property will receive another Wrapper which wraps the entity property so we can chain through and The wrapper of the of the node of the user of the node offer the user account supports also as It's a wrapper you can just use it the same way and get the mail wrapper and from the mail wrapper And finally you just call value to get the wrapped value, which is the mail address The very same way you you can just use the wrappers to update entity properties like in this example And what is also very neat is that it's works exactly the same way for entity properties and for feeds So it abstracts the difficulties that you have With dealing with fields for you So you don't have to care about the language that the field is stored by default The system takes care of that for you But still if you need a specific translation you you can access that by by call like this one Also, the system takes care about loading reference entities for you So as in this example, it uses the term reference field field tags, which references multiple term entities So what we will get back here is actually an array of term objects So multiple fields are And generally Data that is multiple and as multiple entries is so represented as an array of data items And you can just use the array syntax to access the first item or to append an item like that Additionally the entity property info system provides some media data about all properties and you can use the wrapper to access it So in this example, it's used to just to access the options list Which declares basically the options a user can choose when he inputs the value Also, there's a label method Which gets the human readable label of a value if this one So if you have an options list, it gets you the human readable value of the options list what also supports getting an entity label and Also, there's an access method which helps you to check access and it automatically will Incorporate field access for you as well as entity access So it's very useful if you need some sample some simple access checks you So this would be an example for the entity property info which is needed for all that entity made a data wrapper system to work so for the wrapper to Allow accessing a property like the mail property we used in the example the system needs information declaration as we see here This is also necessary for fields But in the case of fields is automatically generated by the system for you as long as there's support for the field type so When we have a look at the code we see basically the information adds human readable label and the description for for all of the properties but also in data type And also there's some information that tells the system to how to update the data How to validate the new values which need to you want to set? It tells the system better. It's actually in a required property for and given entity type How it can check access on it and schema field finally denotes the relation to a database schema which So if you have it's declared in hook schema to declare database schema field You can just add the schema field to add the relation to it So you might wonder what's all that the property info for now, but basically it Allows you to make use of the all the entity data in a general way Without the entity property info you wouldn't know What kind of properties an entity has and of which data type it would be so you won't be able to use it generally And also it enables you to validate data automatically Or to check access on it So if we have a look at how modules use this there are some different ways modules make use of this actually I would say that the simplest way modules use it is indirectly by the entity made of other weapons and this mostly do modules like to pull commers or few spark operations or organic groups which Rely on the entity made of the rapper a lot just to make To make it easier to work a lot with entities and field values So they just benefit from from the simpler API But then there are also modules like rules and the search API which really rely on the entity property information system a lot So rules really builds builds up in the system forgetting data but also for for writing data in entities and search API also makes use of the system to read The properties out of the entities in order to be able to index them Then there's the micro data module which basically annotates micro data mapping based on the entity property information and There are also some web service related modules Which are called SWS if it is the server side module It it's basically an alternative module to the services module and it's working generally and based Just on the entity information So if you declare a new entity type at the property information, it will automatically work for new entity type The WS client is the web service client module It doesn't directly make use of that information But it makes use of the same way to describe Data as the entity property information and it uses that way to describe the data That is necessary in order to invoke a web service or when it gets the results back Exposes then the data to the system Then with the entity API module that already at the entity tokens module included Which basically ensures that there is a token available for each entity property that is known to the system So it's very useful if you implement the entity property info API You don't have to implement the token API again Then it's just available when you turn on the entity token module Yeah, and also in the entity API module. There are some generic fuse fields Which make it possible to to make fuse that lists data Not based on a database query you run But it just makes use of entity load to load entities and then displace the data Directly out of the entity objects This is also used by the search API for example when it when you use its use integration Okay, so Let's have a look at how you can provide a new entity type based on the database Basically, you need to do three simple steps First you have to implement hook entity info to declare a new entity type Then you specify your controller class you wish to use there and you implement hook schema to define your database table In court as a controller class Which you can use and if you use that one you basically get entity loading Then the entity API module provides another controller You can make use of and if you use that one you will receive full grad functionality so for example given This code here, which is from the profile to module will automatically work also for your new entity type If once you use the entity API module provided controller so you use so you can use the entity create function to create a new entity and What's also very nice with it is that you can actually make use of entity classes so we can have classed object and you can Define methods on it and can use some default methods on it like saving an entity or deleting an entity and You can also make use of All the helper functions that are available like entity delete multiple in the entity by Okay, so let's have a look on how you can integrate your newly provided entity type with all of a country What a great thing is that the entity API module actually helps you a lot with that. It has quite some additional controller classes which take over Integrating your entity type with a certain country for example given there's a dedicated fuse Controller, which cares about integrating your entity type with use That way you can easily customize all the integration the module provides provides You just extend the default controller class Customize it as you as you need and specify your own class Okay, so to start you Have to provide the entity information the grad controller and the schema as already said and Then automatically the field API will be invoked and attached for you So the so the entity API controller cares about that. You don't have to do anything if you want to make use of fields just Activate fields in hook entity info and you are done Then entity property information is also automatically generated out of the database schema But it's not very complete and you really should complement it For example, give them if you have an integer the system really cannot know whether it's an entity reference It whether it's references a node or a user or whether it's just a timestamp So you have to tell him that you can specify it That the data represents a node or a date and then it will Automatically know how to work with it And this is also what the fuse integration controller really makes use of so The fuse automation at the fuse integration controller automatically provides really fully working fuse integration for you And once you have specified all the entity references correctly in your property information It will also generate automatically Relationships and reverse reverse relationships to the other entities for you then there's the entity tokens module which basically you just have to enable and you get all tokens for free and You will also get the rules events automatically for your new entity type and rules automatically has support for for saving and loading entities anyway and The very same way like that you will receive integration For every contract module, which just adds support based upon all the available information For example, give them the search API does so so if you install the search API It will just work with your entity type and just like that I hope more and more module will come up and evolve to work. There's a very same way Then in addition to that there's the possibility to make an entity exportable So you might know the concept of exportables from C tools exportables It's basically a way to manage configuration so that you can save it in a database but still Export it into code put it into your module and actually use Versioning stuff like it and so on with it. Yeah, it's really great for for managing configuration and with the entity API you can easily make use of Exportables you just have to make define a different entity API controller and basically that's all And your entity is automatically exportable It should be noted. This is Kind of Controversal topic because some people of the community don't like exposing configuration as an entity to the system I would say that there's no really a functional cause for that. It's more a matter of preference I really like to do it because it helps you a lot and it Gives you a lot of integration a lot of great functionality for free So I would say it's just up to you whether you want to use it or not so everybody can just decide on its own Yeah So what are the advantages compared for example given to the C tools exportables implementation? So it has the unified grad interface as you know it from entities. So you it's really Easy and seamless to work with but it also has a slightly different approach as the entities are synced to the database so each time you have an entity exporting into code and it's In a module it will be automatically imported in the database and This also enables a really important thing what? The regular grad hooks so you will get the regular insert update and deletion hooks also for your configuration entities Even if they are exported in code what makes it really easy to react upon configuration changes and The very same way as we have already seen it you will also receive Fuse integration tokens stuff like that for your exportable entity and in addition to that In particular for the exportables There's features integration and also the entity pair helps you with integrating with the it and then the Internet visualization module. Let's do this Okay, let's have a look how you can integrate your exportable entity with the system So it starts the very same way you provide entity info you specify your grad controller implement the schema and Then you will get the property information generated which you should complement again. Nothing new. It's really the same Then features integration will just work out of the box. You have don't have anything to do there Fuse integration. It's the same. It will just work For it in and you have to complement a little bit of code But it's it's not hard to do you can just look at the example module cope it over Basically, the entity API has some helpers which do most of the work for you already and In addition to that there's also the token support you can just enable and there's an Administration UI which you can just enable via a controller class and the entity API module basically provides a nice usable management UI for adding and managing Your configuration and what you have to do for this to work is basically you'll have to implement the Entity-aided form yourself and the rest is taken care of Well, this is an example how the Generated UI would look like this is actually the user interface of profile 2 for managing profile types so in in profile 2 you can have multiple different types of profiles like Community profile or a customer profile stuff like that and this is the administration UI for it It's really just Admin UI as it is provided by the entity API So let's stay a little bit at the example of profile 2 our profile 2 is Really good example module for the entity API module because it makes use of most of its features and As I already mentioned it implements the profiles as entities but it also has profile types which are also implemented as an entity type and The profile types are exportable. So it's an exportable entity type And you can make use of features and stuff like that on it Also, the profile types declared to be the bundle of the profiles What tells the field API that With adding a new profile type you can also specify different fields for this kind of profile and Usually you also have to take care about Invoking field API attaches for that to correctly to work But in that case also the entity API module takes care of that for you So if you have a look at all the components of the profile 2 module Basically, what it has is a system for storage. It has grad system a field API it implements some permissions in the access system it has a Custom profile form and the display of the profiles. It makes use of the admin UI and the internet Analyzation into the integration of the entity API module and it has fuse integration C tools integration supports rules tokens features and it also works well with the search API and If you have a look at that basically most of it is provided by the entity API module But what's not provided is the permission access system which is implemented separately And also the entity form and the display of the entity has to be written yourself So it's really your job to take care of that. I Think actually it makes sense that you have to take care of that because stuff like the the former where the form is displayed And we are the entity the rendered entity actually is displayed It's really specific to your modules on so no API can take care of that for you But still it yeah, it might be useful to have some some general defaults for it that you could build up But yeah, at least I think it's already great and we have already a lot of Module integration generated for free which you can build up So I think we have our homework done and it's really time to embrace that and to enjoy it So all that here works for database based entities But we can also make use most of it for non database based entities As we have the entity system we have Now separated the storage in an controller class and we can easily exchange that so we can exchange the controller White our own controller so you could do easily and no SQL controller implement support for no SQL databases implement support for doctrine or PHP CR which are PHP libraries and Or you could implement remote entities such that if you have a two Drupal sites you could use that system to implement remote entities in one system to Display actually the data from the remote site on another one and the very same way you can use that generally for data integration and Just integrate any data of remote systems in Drupal Basically, you just have to write your own storage controller over its methods implement the ground functionality and it will work But you might wonder how does it relate to the field API? So if you have that non database based entities You could enable fields, but fields are really Stores separately currently in Drupal. There's a separated storage system for it So by default your fields are going to be stored in the local database So it's not that easy to write a new field API storage controller But you can do it in order to gain full support in For example given for no SQL databases, but if you just want to implement Remote entity or integrate some remote data It's probably won't be a good idea because you usually won't be able to add fields to that data anyway So in that case you really just have To stay with a non-field able entities with an entity that just has properties So once you're providing non database based entities, it's basically works the same way you declare entity info You specify your grad controller your customly written grad controller, but instead of Declaring the database schema. You just specified entity property information Up in which then the system and the contributed modules can work so just like as we had before all the Module integrations or the modules that work based up in the entity property information would stay working So you will get still working fuel support You will get full support for rules and tokens as well as for all the other modules which work based up in the information So if we have a closer look at what that buyers, I think it's also very neat that you easily get a class grad API then for your remote data which has the usual unique interface But also which are statically Caches the data so if you access the remote data multiple times in a page So it will be statically cashed and accessed only once and you could also enable Modules like the entity cash module which is a separate contributed module and supports caching entities in the Cache system of Drupal so you can install memcache and cash your entities in there also you receive the General grad hooks so you will have all the usual insert update and delete hooks so modules could even extend and customize your remote entities You will get the regular tokens based up in the entity property information And you will be able to make use of all the the modules that work generally with entities Like you could use the entity reference module just to to reference your remote data The very same way rules will just work with the remote entities Just as well as the rules link module the rules link module is a small module Which basically is similar to the flag module, but it doesn't have the possibility to toggle a link It just has the possibility to click a link and to fire basically some rule rule actions When your users are clicking it Then what also very neat I think is that you can use the search API on remote entities So you can just index the remote entities and Build a full featured faceted search on them But what you have to take care of is about the time when your remote entities should be indexed because Usually when you are working with remote entity you won't receive any notifications when the remote entity changes So you basically will have to implement a ground-based mechanism or so to re-index Your entities or you do it manually via the user interface You will also get fuse integration for your remote entities, but by default it's of course a bit limited as there is no way to filter So you will be able to list your remote entities as you have implemented a way to load them But as the system doesn't know how to filter for them You won't have that possibility by default. So you would have to add custom filters yourself The rest of us module would work out of the box so you will you would also get support for that and Hopefully also for more modules that work based a bit on the general concept of entities So I think that's pretty cool, so let's go ahead and Drupalize more data and expose your data as entities to Drupal and make it work with Drupal and all with the great contract modules and To show how this works like I've also done a small example. I've done an prototype module which Exposes Google Picasso photos and albums as entities to Drupal At that URL you'll find the code. It's in a sandbox and you can just Enable the module try it out and have a look at the code and see how it's implemented It's really not that difficult as said basically what you have to do is to provide your own controller in the controller There's a query method you overwrite it and in the query method You just have to load the data and to return it. That's it basically So this is a screenshot of the example module It's actually a few It lists the Picasso photos and it as you see you can see the images the images Loaded directly from Google so they are not locally and As all the data is just loaded on demand from Google on the right side you can see the album which is a Separated entity and in this case the fuse integration just loads the entity label On the left where you can see the image. This is the fully rendered entity as it's pretty easy to Implement the API to have entity few support for your entity I've done so and just output the image there Which is pretty neat because you will have a regular template for that and you will have few more support for that So females can work with that as they are used to they can use the template overwrite it Few more specific and so on Yes, then I've also done another display of the few in a table. You see the is support for Using all of the different properties that are defined as fuse field automatically you can just add them in and Also the album which is a referenced entity Automatically is exposed as fuse relationship. So on the on the photo entity. There's actually a defined entity property which references the album and The fuse integration automatically makes use of that and once you add the relationship in fuse you can also access The properties of the album in fuse And as you see on the left We have a pretty long ad for for the Google because of photos. It's the full URL This is because we really need a unique identifier for being able to expose data as entities to the system because data need to be able to look it up and in the case of the Google because of API There were no simple integer ID or so because the the simple integer ID is also is only unique Inserting an album. So we had to use the full URL or at least any other unique combination in the case of the album There's a simple integer ID, which we were able to use So you might wonder whether it's required for entities to have integer ID Actually, it's not it's only required if the entity is field able and As our entity isn't feel able it's fine to have a non integer ID, but some con drip modules Assume that your entity ID will be an integer. So if you have an Remote entity implemented which has a non integer ID You might run into some bugs with some modules. So hopefully we'll get them sorted out really soon Okay, as always there's some room for improvements What I would like to see is better view support based up in the entity field query There's already a module for that which is as of now a bit outdated that needs to be updated to work again but once we have that you could also a Implement filter support and sorting support in fuse rather easily just by making sure that your entity Works fine with entity field query Then also, there's no read-only mode. It's it's Possible for an entity to be read-only. It's rather simple Just leave out The safe great and the leaf methods basically usually I also add an exception Into the methods if a module cosets so it's notified that this doesn't work And it's not supposed to work But there's no no way in the system currently to denote that an entity type is really read-only So modules cannot know that generically. So this was a room for improvement And as I already mentioned in profit to it was be awesome nice if the API could provide some saying Default generated display or some default generated any form which would just work based up in the entity property information Yeah, that's not there yet So, okay, let's have a short look at Drupal 8 entity API and what's going on there so for Drupal 8 there's Quite some work which has to be done and some of it has already done We have already Entity API in Drupal 8 which works with classed entity objects So once you have an entity then you will have methods on it based on up my defined interface So you can easily get the entity type of it. You can get the idea of it stuff like that And we have a full grad storage controller in core. So once you define a new entity type you can easily have it Working with full grad like it's possible already in Drupal 7 with the entity API module Currently this is in Drupal core only implemented for for comments all the other entity types Still have to be ported. So this is really work in progress This is how you can already work with comments in Drupal 8 It might look familiar to you because it's really similar to the way the entity API module works in Drupal 7 So you you basically when you create a new comment in Drupal 8, you have to use entity grade because it's not going to be Very to have a standard class comment object anymore If you want a comment object, you have to use entity grade so you get the classed object And but once you have the classed object you can make use of all of the methods on it like saving Getting the identifier of it deleting it and also we have helper functions like entity delete multiple Which allow it to delete multiple entities at once that's already in core and For that to work. We basically have classes like that. We have a custom Comment storage controller in Drupal core, which implements the comment module specific bits And we have an entity database storage controller, which is the generic full grads Storage controller you can make use in Drupal 8 then to implement a new entity type and you will receive Full grad functionality based up in that Then we have a comment class Which extends the general entity class the entity class really is just a helper class which implements the useful methods and the methods are defined in the entity interface So every entity has to have this method and the entity Class just implements it for you. So you don't have to do it every time you are implementing a new entity and The comment class then implements again comment specific bits in particular it or it defines the properties a comment has like the ID subject Stuff like that Okay, that's my presentation. So are there any questions? If you have any questions, please stand up and come to the microphone so that everybody can hear you Big fan in the API. Maybe my life is easier Okay for Drupal 8 other talk of like a forum a forum a forum controller to help control some of the you know Somebody form out of the box function. I guess you can have your submit deletion functions in a class rather than There are no specific plans for that yet, but It kind of is planned to do something like that to have a controller that is cares about Generating the form for an entity. So that is going to be easier But that's still on the on the road and work hasn't started in that area yet But if I did it, it would be accepted though if I submit a patch Probably right that's it's a concept though. You want to do right? Yeah Yeah, it's something that I would like to see yeah, it's just a question that it's going to To make it into Drupal 8 where we have enough time to get there Yeah, but still if you haven't I think it's something where we could work on and contribute to as far as The basic architecture is in core. Okay. Thank you Hi For your Picasso demo that you did was that a non DB entity example? Exactly. Yeah, that were Entities that were directly loaded from the web service from Google because of and just listed on your site Is there a way to conserve API calls for like things like sorting? So so that you don't have to refetch the list if you're just going to let the view be sortable Or does it refetch the list every time as of now? It has no support for for sorting at all because for that you would Need an API for it like entity query or you'd directly do it yourself in the fuse integration So that's really something you have to take care of manually as of now So the view can't so the view can't just do sorting with its built-in sorting No, yeah, you could implement a Fuse handler that do it for you which just sort the object in memory that would work. Okay. Thank you. Yeah Is there any plan to implement revision support in triple 8 in for entities? Yes, there's the plan to do it and we have already revisions in nodes and the plan is to abstract that and to make it General functionality, which is implemented in the controller so that it can be easily implemented and enabled forever entity Okay, if there aren't any questions anymore, then thank you and please don't forget to take this survey and tell you what you think about the session