 All right, it's 1 p.m. So we'll get started My name is Carl Weederman. This is markup ain't easy how I and hopefully you Will love a object-oriented render API This is a very kind of future-looking talk about What I think we would like to do or what I would like to see in core in the future and There's gonna be some demo. There's gonna be some code There's a few proofs of concept and hopefully We can get people excited about this and hopefully start discussing it more so Oh my slide telling me who I am is gone. Well, I'm Carl. I'm C4r all on Drupal.org. I'm a developer, themeer and trainer and I was giving a Training once at George Washington University. It was teaching people how to theme in Drupal. This is Drupal 7 this was about three years ago and I was Trying to Duplicate a layout that they had and they had made this layout instead of HTML And they had like a menu that was fixed in a in an area and they want to know well How do I how do I theme a menu myself? How do I actually like get the menu and then? Spit it out in the template and that example Sounds easy It was not easy. It was not easy to do It was really hard to do and I could see the phases of the people in the class Feeling like theming. This is really hard. It. This is tough. This is really hard and really since that moment Theming is hard theming in Drupal 7 is much harder than it was in Drupal 6. There's a lot more concepts Things have Things have not really been getting easier for people This is a common thing. We've talked about a lot. I think it's hard because the render system, which is Kind of this larger component that does the theming is complicated And this is one of my favorite graphics that perhaps you've seen That John Wilkins made of the Drupal 7 theme system And it's not even well understood by people who work on core Things are getting better since then. We've made a lot of improvements. We have this thing called twig, which is very cool Everybody's probably at least seen some examples of that and gone to probably some twig talks But the rendering hasn't changed very much rendering as It exists in a function called Drupal render And really the reason this is complicated is because of its implementation and that implementation isn't very well hidden What twig aspires to do Are things like this where we have a variable and we wish to kind of drill into that variable We have the Image this is what this would be like a node. We have an image field on a content Variable we want to dig into the first image in that variable and then give the source of that build our own image tag Right, this is what twig kind of aspires to do is what we want to do We actually cannot do this in Drupal 8 Because we don't have an API for Render arrays render arrays or arrays and arrays don't have an API. They're just sitting there The real technical reason here is because source is in template prepossess image Which happens after template preprocess node. So the node template which is where this lives Has no access to that variable Because we run or we want to render these things on the fly, right? We want to lately process them That's what the render function is Which is a good aspiration, but arrays aren't smart so as much as you want to do this you're going to get a heinous error and The things that you thought you might have due to a preprocessor won't exist So drill ability, which is kind of what twig wants to do. We can't do we just can't and this I've kind of discovered this in the middle of Drupal con portland and Had this awful kind of sinking feeling that like we had done a lot of work But really hadn't solved a really fundamental problem so instead of An API we have Drupal render Which you might call array PI instead or AP may think might stand for anti-pattern if you want How does it work? Well, we create a big array of stuff we eat it up and Then there's a string that just comes from somewhere and sometimes it's a theme function. Sometimes that's a theme function. That's wrapped in something else Sometimes there's wrappers There's other processors. It's pretty convoluted It's one of the longest procedural functions in core It's 185 lines on its own and now it's the only function that calls theme And theme it is 244 lines The only functions that are longer than these are things that like to return like a list of countries Or like a list of mime types stuff like that It's called a lot It recurses many many times if you from an empty cache Single node view with one image field one taxonomy term. It's called over 200 times In one request So when you have that many lines of code that are so convoluted. It's hard to follow This is a quote from someone who works on core a lot Jesse Beach In an issue about render cache and She was working on this for a while and running into some difficulty and Said this I'm not convinced that this proposed change will give us the performance increase that will justify the complexity We'll have to introduce and that has kind of been this the story of Drupal render for a while Is that every single time we want to put something a new feature on Drupal render? That function gets bigger and we have new properties that go into that array So while a lot of 8.x is saying arrays are going away Drupal render is still using arrays and you can create as much dependency injection and fanciness and Components as you want and you can have as much fanciness on the theme layer as you would like Fundamentally, there's this array in between those things that is holding everything together Okay, that's the complaining part of the session I don't know if anyone is going to defend a raise outright I think there's some reasons that we haven't done these changes because it's a lot of work to do I'm not saying that this is anything that we can do for Drupal 8, so At least not 8.0 So this is maybe Drupal 9. This is kind of what this could look like a lot of the discussion that we've had about Improving the render system improving the theme system have been like well let's introduce another pound property into the render array and that kind of discussion I find kind of dissuasive because It's kind of bolting onto this thing that we've been using a long time that fundamentally has Problems is just not well-designed So I'm going to talk conceptually about rendering and I'm going to show some code that I've written to proof of concept It's not actually in Drupal yet. It's in Sylex. It's kind of staying on its own But I think maybe offer some promise for this and then we can talk about what would be the next steps Is this a good idea? Is it not a good idea? etc so Conceptually what is what what is rendering itself? What do we need? I think we need two things I think we need an abstracted alterable consistent model of structured content Render arrays are these structural things that will be turned into HTML pages But there's a structure there And it's it's abstracted it not necessarily HTML. It could be something else Could be sent to like google glass and maybe they use something other to else render it could be sent to some other kind of device I think we need a sensible accessible api for this model to get into those things And to pull them out. I think a really good example Of something that does this is think about jQuery How often when you're using jQuery, do you like dump the jQuery object to the screen to look around and get inside of it? You don't Because it has methods. It has ways to get at the things you need Um render arrays we have to dump them out. We have to inspect them. We have to dig through them Uh, as Larry said in his talk this morning arrays are not apis So this is not something new It's new in the sense of Drupal the Drupal render world though So do we have an api? No, we have arrays all right The part we've all been waiting for objects um This is some code that I've written that's on github right now. It's not yet Um Really part of Drupal yet. I've I've done some things to kind of emulate Drupal I actually have a file called fake Drupal that pretends it's Drupal and kind of does some things that Drupal does Um Mostly this is just a demo. This is just to try to communicate some of the principles that I think um could work um And it's it's at a phase now where I would love input from other people and um, maybe getting a proof of concept that would run in In a core sandbox So i'm just going to show some code And some examples of what this would look like Okay so um This is the github project when you check it out. You get this stuff. Uh, it looks kind of like Drupal It's not Drupal. In fact, if you go in core there's something called fake Drupal Which pretends it's Drupal. It kind of does the things that Drupal does in terms of like loading modules and stuff like that um The index file Is running Sylex uh Sylex is just basically a route handler Um, and I've got some stuff in here that I'll explain When you load this in a browser This is just going to show you some very simple examples of things that I've done um using The architecture here. So first thing I have is um a node All right, so if we open this up and look at the source This is just a you know a very basic template here If we look in Sylex Here's the code for what this returns if you've used Sylex before basically Sylex says at some route What am I going to do? So What is this doing? Is this generating it's generating something that's called a renderable builder Um, that takes two arguments. It takes an argument that wants to know what is the renderable itself What's the type of thing that I'm doing? This is similar to like the theme function or the theme callback Um, and then it takes an array of arguments. So for example, um, this one is is something that I'm calling theme node Um, it's taking node as an as an argument Um, this will correspondingly have a a class that is associated with it and a template that's associated with it So in my fake Drupal, I've kind of faked out and node module Um, it's not connecting to a database not really doing anything. It's just loading up some, you know, a very simple piece of data um Inside of theme, uh, instead of the the node theme. Here's here's the class that this is going to build Um, and I'll get to this in a second but what I want people to see is that This right here, let's see Um, I think render arrays should turn into a builder pattern for those of you who are familiar with object-oriented design patterns Builder is similar to a factory. It's something that makes other things Um, but the actual creation is delegated to a kind of later step So we're going to kind of build something up and then create that thing Um, so when we think of renderable arrays, yes, we're kind of building up this big structure And then we're going to theme that structure. So that seems like a builder to me um That's what this build thing is This syntax is actually really similar like doesn't this looks very similar to like this Right, it's not that different from what we've seen in Drupal before The difference is it's returning an object and not a string Um, so this is going to create a builder That builder has a class that's associated with it. So here's the theme node class um And right now it really has just kind of one method that we would concern ourselves with which is a prepare method And it's got a template name associated with it and you know in my in my fig node module My templates director. Here's my node.html.twig. This is what we saw on the browser And so the the prepare method is basically what uh template preprocess functions do like when you have the your base template preprocess function It's going to do some things And so here you can see that our node theme extends an abstract renderable that has getters and setters That's how we're going to get it variables and set variables instead of an array of stuff We're going to use methods Methods are useful methods give us lots of power So I pass it a node and I'm actually going to set something called title I'm going to set something called content in my node theme. I'm going to have title and content um, I could do something like set foo to bar I didn't sleep very well last night. So I may make some typos Okay, so getters and setters living there Um in my fake drupal. So that's fine for like core Um, like defining your own theme function. What about themes themes override things We have like preprocessors modules can preprocess things themes can preprocess things. So in my fake drupal I have a theme down here called austin Um, I also have a module called I think I put it down in the modules right this is not drupal This is fake drupal, right? I'm just kind of pretending i'm drupal I have a module called colorado. That's where i'm from And here I have um two things Um that are going to preprocess things and you'll see that these are classes One is called colorado full node decorator. One is called austin full node decorator and This I believe is how preprocessor should work Um, is it should move to a decorator pattern. So what happens in conventional drupal is we have this array of arguments Then we pass it out to preprocessors. It's sending an array by reference It's adding things to that array. That's basically a decorator Uh decorator pattern is behaviors added to an object dynamically at runtime without affecting other objects of the same class So, um, I can I can add things on to my Um renderable As I please So let me actually enable one of my modules. So let me go to my colorado full node decorator. What i'm going to do Is i'm going to um Change the title variable Uh, we could you know, we could use annotations here to say like what is this actually doing this should actually I changed the names of these very recently. So this was called theme full node, but um you get the point But I could um what i'm doing is i'm saying, okay I actually want to i'm going to do the parent prepare And then i'm going to set the title to this the title node and it's going to say from colorado So in my fake drupal, this is how I enable modules I uncomment them so What what what is that doing that is just decorating the um Theme node class. It's simply running the first prepare and it's running the other prepare as a decorator on the original class If I enable my um austin theme It also has a node Decorator as well. It's actually setting in a new variable. There are a subtitle and it's also providing a new Uh template That is that is going to print out subtitle. So i'll show that in a second Um, let me show it another example. Here's what maybe a These are some very simple examples to start with. Here's like what an item list looks like right Theme item list provide an array of items as first second third So if I go to I put I believe just for the sake of demo. I put this in system um, here's my theme item list class Has a template name has a prepare method Um, and it's basically like oh if you haven't put a type variable. It's going to default the type to ul Um, so that's basically what theme item list does at this point and then team item list In my twig Does this kind of thing this is basically it's not at the exact, you know, it's basically what we're doing now in core So if I go back to my example And here's the item list And I could you know this Set items I could change that to something else if I wanted to using the set parameter. Don't forget your semi colon um Builders can have parameters that are other builders So here's a more. Um, here's a more complicated example I'm calling something fancy Let me go back to what this is So, um this render api create function can accept an array of builders or you can accept one builder or um, or sorry one It can it can create one builder it can create an array of other builders here. So here what I'm doing is I'm like Loading up three like an array of three nodes This second parameter here is a weight So I'm adjusting the weight of how these would appear and I'm putting an item list and that also has a weight So the item list has a weight of negative one This also has negative one zero and three So we should see the item list first Then node 123 Then node 79 then node 456 that's what we see here. So I could change these around I could make this negative two And it should move to the top So these can have weights associated with them weight is actually a method on a builder So you can say set the weight to this etc Here's kind of a further example that that I think will Show like what a what a page would look like. So here we say we're going to create Theme page. We're going to have an array of these parameters If I look at like a page dot html dot twig Here's my page And then here are the parameters for that page um, and in my index p.index.php you can see that Um, I'm loading a node. I have a sidebar that's going to have some nodes in it Let's actually go ahead and look at this example Here's a sample page Oh Well, I have a very small browser Oh, it's because There we go. Okay. Um So I've got some header value some sidebar value. It's got some other builders in it um So on and so forth now What we can do Is because we have getter methods Because these are objects is we can get to some of those variables that we couldn't get to in twig. So for example I'm going to enable my austin theme So we'll see what this looks like in the austin theme Which is my fake drupal how I enable a theme Here's the austin theme So as we Dig into the austin theme we see that um austin full node decorator Sorry about the size of my screen folks We're going to create a new variable called subtitle. It's going to say here's the subtitle for Node it's going to get the title from the builder itself Not the node. So that means it's going to uh It's going to say here's the subtitle for node node one two three from colorado That's what the module decorator did is another decorator further decorating this renderable um and Because we have accessor methods what we can do is I can go to my austin page template And say in my header Is I can start to do this drilling that we couldn't do before so let's say I want to say the subtitle of the second Node in the sidebar is That would be basically, you know, I can I can just start to look at what these are so I can say sidebar first And I'm just going to print out the nodes So this is printing out both the nodes. I want maybe the that would be the first node. There's the second node save refresh Uh subtitle Save refresh So this is accessing a variable from a parent template That is given by a decorator That exists for a template below it the reason this works is because twigs template class can be extended Uh in my fake drupal. I've done a very crude implementation of this Here's fake drupal Abstract fake drupal twig template that php. That's what it's called right now, but obviously this would be better There's a function that they have called git attribute. That's what that dot thing is doing in the compiled template And what i'm doing is if this is um running a renderable builder interface it's running a function called find What find does is it looks for the variable if it doesn't find it it creates the renderable It then looks for the variable in the renderable in the in the um In the prepared values So I won't dig too much into the code here of all these You know, um attributes and classes what this means is that if this if something like this gets in the core um Then this issue Is fixed potentially So that would be a very nice thing. I think it would be a big win for front end templating in general um the third principle that I want to uh communicate here is building and decoration isn't invoked until the builder is cast to a string um So this means that the builder just sits there It's just sitting there the moment it's cast to a string It will then find the child class build an instance of that Run the prepare methods Then look up the theme engine and do those kinds of things. That's what it's doing right now. This is a very simple example It's not, you know fit for a drupal quite yet But this uses the two string magic method and this is another nice thing about Uh objects is they can be an object until you you cast them to something in this case the the string um This process looks i'm just going to jump ahead Uh, i'm just going to run. I'll just let's just try to get this conceptually, but basically we create the builder when you run the two string method it's going to Create the renderable itself based on some class name parameter It's going to decorate that with all your preprocessors And then it casts that to a string So it's this Kind of two step process here um I have a few more slides and then people can ask questions And things like that But I think this is this is where I'd really like to see this go um I think there's Some challenges here. Um, it's it's it's definitely a lot of work to do. It's not something I think that we can do for eight Um, but for nine I would I would really like to to see it So at this point, this is a core conversations where we chat about things Um, I can show more examples of this Oh, I remember one thing I forgot to show let me let me actually show one one more thing and then we'll we'll chat um So I was giving this talk version of this talk in prog and um, I think it was jesse beach who asked So if we have An api for structure can that api be presented as a rest endpoint? Um, and so I I kind of thought about and I decided well, yeah, I could so I have um One thing I have in my examples Oh, I overwrote item theme item list hold on a second Is you can actually get those variables, um as json Responses So here i'm loading up node one two three and I have a parameter called like render var um, and so I could say render var node dot nid or in this case, it's um Well, let me actually look at a different example Here's the page template as json, so I could say um sidebar first Sidebar first dot, you know do the same thing I did before Or that's dot nodes Dot one So right there is the I could look at nodes. I could drill into this Uh using a url Style thing I have another thing in here where it's um Yeah, yeah, not bad Here's there's also a um another git parameter. I add to this where it actually runs the prepare So, you know, I could actually get the the prepared things too. This is actually going into the renderable running the prepare statements um So I think this this we we talked about this like this has implications for like front-end templating um, these things could be cached obviously um, but this this would be really useful for um Services that are that are like trying to alter things on a page But you you don't want to write a separate service to do it the variables are already there. You just want to get at the variables um You know, so I I think I think that could be useful, you know, there's an example of this. Um, has anybody ever used, um Mobify did people know what that is? It's basically a service that does like a big jQuery Parsing of your site and like turns it into like a mobile site Um, this would be really useful for like a service like that. It's like actually no I'll just I'll just um put a parameter as a get request and get those separately Um, it may seem silly to go through the whole bootstrap process just to get like, you know her, um nodes one I was making commits to this today, so Well, something something's the matter um but The point is that these are the kinds of things you can do when you have an api into a renderable structure um And that I think I think is is where I'd like to see this go um So that's kind of the last part that I wanted to show everybody um So I think the to-do like today is like and maybe at the sprint and just Now is kind of re-engaged re-engaged discussion. Uh, there are some issues on d.do about like Drillables and render api and these kinds of things But I was kind of I kind of wanted just to work on this kind of to get my concepts fleshed out to see that It was maybe possible And then from just the code perspective is just like proof of concept in an in an 8.x sandbox I actually tried to get that Working a little bit In fact, I got it loaded. I actually like sim linked um Sim linked my projects um, and was able to like Get it, you know running. I mean, that's just like psr4, but You know, it can it can get in there It's separated out so that it it can be added As a separate namespace um So anyway That's about it. I think so please evaluate the session node 26 18 if you have time but uh, We can talk about this more people can have ask questions if they want But uh, this is this is where I'd like to see you go. All right. Thank you Thank you Yes, sir So I like the general direction you're going I have one critique and one question cool Early on you said and you're describing what's you know a renderable thingy should be yes, um You presented it as though you were looking at it being for an arbitrary output format. Mm-hmm. That's what render apis in Jubil were intended to do right and I think they failed miserably at that because If you're outputting something in You know how format you want to use a completely different builder than this in the first place Right. Um, so I think it's actually better to Confine an api like this too. This is an api for building up HTML output There's different builders and different apis that deal with howl or adam or whatever just let those be different Builder apis. I think that's a better way to go. Absolutely narrowing this to the intended output as html. I think we'll Save us a lot of pain. Absolutely Um And then the question how are you handling? What drupal render arrays call attached so css javascript meta tags? links caching information all of this other Stuff that makes render arrays currently really really hard. Yeah, because otherwise you're just wrapping objects around The simple stuff, but it's not hard stuff that makes render apis sucks so much to work with So how would you address those kind of things? I'm particularly interested in that because I'm dealing with that right now. Yeah. Yeah, that's that's definitely I would say that's uh, maybe left off this slide. There's definitely a to-do But I think just in a general principle like Doing that in object-oriented code is doing is easier to do that in a big Clunky array. I completely agree with that. Yeah, so I'm not sure I'd love to talk about it more at this conference Like every conference is like kind of like A new a new step here. So I think maybe this is the next step to think about. All right. Thanks. Thank you Yes, sir, uh, so I'm wondering about What you want that training experience to be like you talked about how A lot of a lot of your thoughts here are motivated by the difficulty you had training someone to be able to theme in drupal and a lot of what you've shown is how The deep internals of drupal might change so that the theming experience could be different. Um, I'm curious What that end goal Is exactly or or how will you know that you've succeeded? and This refactoring based on how that training could be different or by some other measurement totally Um, I think the less people have to dump Things to the screen and dig through them, which is exactly what we had to do in order to figure out Oh, what is this menu thing look like? Um, the less we the less we have to do that and the more we have methods and getters and an api um, I think is is A good thing, you know, I would love to say like, oh call this function to get the things Call this To do these things instead of like, oh, well, I can see that this array is coming from here And if I I can tell this is coming from Common.ink and let me go to menu.ink to see how that oh that's built this way, you know Having to do less of that stuff I think is a better direction to to be in so I that's kind of vague but okay more more better tools less Pulling things apart more more tools um, so one process that I I'm seeing get played out in the movement towards going towards Uh static prototyping or in browser prototyping is identifying design objects First which may not use the language of Drupal necessarily Um on a project I'm working on right now the designer has an illustrated list item Which I know will translate to the teaser view of three different node types Um, but illustrated list item is the thing that he is designing Um Is is the ultimate goal to make nodes turn into design objects that are a defined Thing in a in another template Um Does the fact that it's a node Is that the important part or are you turning a node into something else that is a front end only concept? I see um I don't think so. I think data should remain data. You know one thing you'll see like In this thing is like here's the node Its title is still this the the thing that we set in the um In the decorator has changed So I think you know, let's let's leave data as is and have you know This is essentially like presenter that wraps it and that's the thing that we're going to pass around Okay, I don't know if that does that answer your question. I think it does the idea that we have the data And we have this separate we know that something looks like A design and we're inserting the data into the design rather than The other way around uh-huh I think we're an agree. Yeah. I mean this this isn't like I don't know if this is a new concept But I think we can like visualize it better when we have ways at getting at things you know instead of You know like when you click on like the develop render tab when you have develop module installed and it's that Giant gobbledy goop. You're not really sure like what's coming from what like is it pound items Or is it like the zero key that it's talking to right? I don't actually know, you know Uh, and I do droop all the time. So Getting away from that stuff. I think what will help like say, oh, I can tell this is data. I don't touch it I can tell these are template variables. I can touch them. There may be different debugging ways to to get at those things. Yeah Thanks. Yep Um, yes, first off. I am just so impressed by this work. Thank you This is exactly where I think we have to be going with with the render layer and in Drupal Thank you So we had a bot this morning talking about headless Drupal You know and in the room where a lot of people talking About NBC frameworks using something like angular ember with Drupal doing the data underneath And a big problem we identified is that as soon as you Use Drupal as a data store and just interact with it restfully You essentially cut out any modules chance to jump in and and affect that output If you're putting you know attributes on the html in order to like data attributes or something like that And we seem to be stuck at the moment in this world where as soon as you want to go into a front end World where you're doing your templating you're essentially losing some of the really valuable things in Drupal So for me, this seems to be going in that direction where we can finally associate the data You probably know a template is producing or is associated with this display that's going to go with this data Yeah, it has like there's a name to the template whether it's html or whatever Yeah, and it just has a name if we get a uri to that You know, we could start then doing a second request once you get this data back to get a template If you don't have it already and start Moving the locus of where this gets processed into the client But still make it invisible to the you know the site developer or the site builder They're going to go and you know manipulate a view on their node structure page And then the front end is going to get that template that updated template and whatnot So that's that's what I really want to see this going And I'm happy to actually write code to I would I would love yeah, I would love feedback I mean a lot of this has been like me hiding In my room and like doing and not really like presuming because I had this thing we're like Talking about our hundred bullet org. It's like, oh, let's talk about the render array Let's talk about putting something in their memory to do that because we want to make you know, everybody wants progress, but like Like talking about those design issues. I would I would love feedback and and To do that here and at the sprint and everything too. So yeah Yeah, and thanks again. This is I know this is a lot of work you've been doing like for like years now Well, it's mostly like thinking And and writing some stuff and then deleting it all and so thank you Yes, sir. Hello So I want to echo that it looks awesome. So thanks for doing all that work. Sure And uh, yeah, I like the class decisions that you've made the patterns decisions that you've made there I also wanted to say like uh, I'm doing uh with chicks right now We're doing auto escape and auto escape needs triple render to actually give us an object because it needs to be a safe twig has a an idea of a safe markup We're extending that give me some helpers and basically we're passing these safe variables When they are safe and triple render produces that safe variable So that's something that it's going to be an object and I also know that there's a couple other Might might be better blockers that actually need an object to be coming out of triple render Yeah, that might be something that this can also tie into too because you're yeah if you could extend from or Absolutely, I mean that's absolutely. I mean like the domain of object oriented Code is so much richer to do these kinds of things Um Then arrays and I actually did this this morning. Uh, I was going to put it in the talk But like this is this is a diff between triple render and seven and triple render and eight There's a few changes to a few things, but like the overall You know It hasn't changed much and like There are a lot of new ideas that that we have now especially with Just how the entire architecture of Core has changed or we're using symphony how we have twig and we have objects here and objects there But we still have this array kind of in the middle. So I think Um, you know, it's only a matter of time and and yeah, I think things like this You know, we don't have the answer to yet But the answer becomes visible once we have the vocabulary of Classes and one implementation comment. I saw you changed. Uh, you mentioned that you changed get attribute That could be troublesome. If we can absolutely out of there, then that would be awesome because yeah, absolutely That's the that's the one function that twig has that actually it implements in the c twig And that's what makes twig fast when you have c on so either that or you have to Put that upstream, right? I mean, um, yeah, I would I would love feedback on what what things should be called You know, um, I've had a little bit of input on that but but I'm you know I I'm not married to any of this stuff. You know, I I just want to get like get things moving in this direction Start the conversations And just see where see where it heads if there's another place for that that would be cool if Maybe move your code into twig Yeah, maybe so, you know, I would like right now. This is actually agnostic from the theme engine itself. In fact, um I first got it working in php template Before and syntax looks a little different, but um, I don't know if I have a good example of what I was doing there but But yeah, I mean, it's like it is theme engine agnostic that is basically Injected so to speak. I don't know. It's not using what symphony uses, but but yes I mean that can be separate, you know Oh and for the template if you could expose the template so that you could swap the template out like as a set or get Other type of thing. Uh-huh. Absolutely. Yeah, it would be cool to right. I mean, that's that's a protected um Variable now and that could be you know, that could be that could be extended that we could create a method around that Um some sort of registry to validate that exists those kinds of things. I know all that's possible. I think cool. Thanks. Thanks Thanks for your work on this. Um, it's really cool I have uh been doing a lot of drupal 7 development still and not really paid that close to attention to what's happening with eight Okay, some of this stuff I'm like I didn't even realize coming into this that this wasn't going to be about something that is in eight And then as soon as I saw you doing it. I'm like, why isn't this innate? Sure So, uh, that's the question. No, where I'm going with this is I was in the boff with with jesse About headless drupal. Yeah, we were talking about, you know exposing json data structures On the front end for consumption by an angular setup. So Uh seeing that the data structure you had up there with everything For me, it's like, well, that's what I'm building now in seven And I'm wondering why you know, if I'm going to move to eight why that's not already going to be there And that was our issue was, you know, she brought it up when she was standing here was that How do you get if you want the raw data you also want to allow modules to decorate it I love that you're using the decor decorator setup because that makes perfect sense, you know, you could have the The the raw data, but you could also have the decorator data and you could do what you need with it on the front end And you add it all inside that structure also of You know giving it, you know, what region it lived in and yeah that That's all so important for the future of the internet and drupal staying relevant to it Yeah, that this has to make it in as soon as possible. This can't wait for nine We need an eight one. Okay. It has to be a priority. I think we're going to be pushing for it There's a group of people that are coming together right now. Cool. They'll be pushing for This type of stuff to become a priority for drupal because javascript mvc is where the internet's going and drupal is such an amazing cms We want I've been doing drupal for seven years and I love it But I also am really coming to love mvc stuff on javascript. So We need this. Yeah, so that I can keep doing drupal and I can do angular and they can work well together Right because jesse also said she wants it to be three years down the road That drupal is the cms of choice for people who want to do javascript mvc That's where it's going right. So let's make it happen and and I mean the the kind of json endpoint kind of stuff You know this kind of stuff actually doesn't even invoke theme engine at all like the builders are built It creates the renderables, but it doesn't touch it doesn't touch any other stuff whereas super fast Well, I think so that's another thing. I need tests in benchmarking if you guys want to do tests I love that but yeah, but then having the the decorators in there so you could you know on an end point You could say do I want to supply the decorators or not? You know being able to have that configuration. Yeah, right, you know, all that stuff is so crucial To where we're going. Yeah that I yeah, I love this right. So let's do it. I would love I think yes. Thank you No, there's me So thank thank you for I mean thank you for coming. Yeah, this is yeah, we're the yeah, we're creating. Yeah, there was Let's talk in the bof. There was a talk of creating a group For talking about how to make keep drupal relevant to the whole mvc movement for javascript. So yeah, maybe we can talk After this about absolutely and I mean this this kind of fell out of Now that we have an api, what can we do and this this fell out of that, you know This was not like my primary goal This was kind of like a nice to have it was like, oh, yeah, I'm sure I can write something like that, you know Psylox can do you know But it has it has implications like this it has implications for front-end templating It has the same as it was like, you know the the default understanding with drupal is I'm going to be creating html I need to create html, but where things are going drupal doesn't necessarily need to make that as priority Right what drupal needs to be really good at is providing excellent rich data structures To a front-end framework to tell it what it needs to do with it. Yeah, you know say, you know Here's what the content creator intended this content to do And if the front end is written to understand that language It will do what it needs to with it based on the platform It's on because the platforms are all changing. We've got so many different types of devices And your data is not just going to go live on a desktop. So This needs to provide the information the front-end needs to do the right thing with the content Yeah, and I mean twig templates can be used on the front-end as well So there's a lot of overlap there. What you're writing in twig is basically what we write in ingot. Exactly. It's the same It's it's very similar. Yeah, exactly. I mean the curly brackets everything right, you know the object oriented. Yeah So cool. I'm excited. Great. Well, let's talk more people who were in that boff Let's chat In a few minutes and we'll talk about next steps. So don't no problem. Yeah. Thank you I'd also like to echo that this is awesome. Cool. Uh, I was wondering from like a theme or experience perspective If making more data available to twig Could have some separation of concerns types issues or if there's if there's anything along those lines that Uh, uh, you know, I've I've seen people do some really fun things and themes like back in five in the days of five and six So I was just wondering if that was uh Uh a concern Meaning the address um I'm just gonna repeat the questions. I make sure I understand it. You're asking like, um I mean a lot of these examples. I'm passing very simple things those arguments. You're saying like How do how do we get it more or or just making sure that somebody doesn't put, you know No 45 title in You know field something else sure just like so the separation concerns in the themes, right? I mean, um, that that's I think two points to that twig templates are compiled. So there's this there's some protection there just Make making sure that people aren't doing bad things. That was one of the points of the twig initiative anyway um The other point too is is that you know compared to arrays This is definitely like we can do those types of things. We can do those types of checks. We have um, you know, we can make sure that the Types of the arguments are what we expect um that Gitters are finding things that they want to get, you know I don't know if it's going to be perfect. Obviously we there's a lot of figuring out to do But it's definitely going to be better than digging through an array. You know, I think I think that's that's kind of the point is like methods We need methods to get at things. We need an api. Thank you. Sure So in answer to your question about how we actually make this happen. I have a proposal for that Drupal 8 already out of the box and the raw entities you can serve those as jason with hal with You know restful links on them. You can do that now If you want something that's basically That's plus You know that the preprocess essentially You can hit you can very easily set it up to hit You know node slash whatever id with a different mind type, which will just build an a render array object Turn that into a jason string and print that that would support for doing that is already in core You just have to write it the actual engine of this Doesn't belong in Drupal. This belongs to its own standalone mit licensed library on packages that we could just pull in like everything Absolutely, yep And then just the glue code to take You know any entity run it through render object and then serialize the render object That should be pretty straightforward to do maybe maybe not use the rest module But the routing system is absolutely capable of serving these kind of objects up serialized today Yeah, I think um Yeah, I think that there's a serving um Business objects Can happen serving kind of abstracted structure in this kind of way I don't I don't know if that is there really but it could be written probably but Well, the question asked is why are these different than a business object? Uh, well, they're they're kind of like abstracted like You know, this is this is like abstracted structure. I guess, you know, if we think of pages as business objects themselves Then then we could So, you know where core is moving and this is something I want to talk to you about in more detail afterward Is we're trying to push in this html fragments, right? I was Looking at that thing the other day, which mostly because I was lost Because I don't really understand symphony that well, so that's not a symphony thing at all. Oh um case in point But You know, I'm trying to get anything coming out of Drupal with render arrays to collapse down to those If we can merge these concepts, then there's your business your your domain object That is You know Whatever data in render render ready form And then serializing that to an html string via twig or serializing that to jason To print out on a different mind type at the same uri that's easy Sure So as long as we can approach that in the right way, I think gluing this kind of thing into Drupal As long as we're able to Discipline ourselves about how we're using it. I think that's actually pretty straightforward. Okay We just need to make sure that we're disciplined about how we do that Yeah, but there's I think a lot of potential to do this even as a contrib module to do this sure and I think you know There's kind of the services aspect and then there's like That the kind of twig where are my variables aspect and the twig where are my variables thing? That's that's a harder problem to fix. This is this is a little easier to fix But this fell out It really just did I wrote the code to do this and like a few hours It fell out of all the other stuff that I was doing, you know, so there's definitely Overlap happening and that's where proper domain object modeling is helpful. Yes, definitely And with regard to what she said about this should be a separate component from Drupal. Yeah, I mean all all the namespacing in here is is completely independent I wrote something called like render manager interface That can basically is set to be fake Drupal. So that's dependency injected. It has like, you know, it has an altar it has A decorator things the altar is like if you want to switch out the class that the builder is using So like bit builder says theme node, but you want to switch it to something else. I actually had an example of that in my like fake module um But yeah, but it was it was it was my idea to have This thing be standalone component This github project will probably I'll probably just extract a sub module out of this On github and then turn all this stuff into like a demo That'll be a sandbox for Drupal And then this is just going to be the only thing that's going to be on github are Basically these these files here As that can be used in any php framework Yes I think we have about Five minutes. Okay. So I'll try to keep this one. No, no, no worries. Um, so the one thing that I'm struggling with currently is I From a theming point of view. I like accessing my variables like this. I like accessing my My variables and drill ability inside of my templates. Yeah, as soon as I do that I screw over the field UI I because it's field UI doesn't know that I just ripped out a field from from the non the node content Yes, and then I put it into a different div over here or over there And so all of a sudden it's like My template has just screwed over any site builder that needs to move the fields around with weights inside of the field UI right is like Fundamentally, I think that control should be at the template level, but Of course, I can't just make that decision and say Drupal can have that's the way this right Is there something that we can maybe do to kind of bridge that gap? Right? um, so the question this is maybe Maybe I'm going to say the answer that lair is going to say but um There's this idea that exists in the far future of Drupal where Because twig is compiled we can inspect templates for the things that are in the templates at compile time And actually talk back to Drupal to say like this is never rendered So skip processing that has to do with this an example is like site name variable if you're not printing out site name variable in your page template remove it from Remove it from your theme configuration page like take out like modify the form that's that's like Fantasyland, but because twig is compiled and we have things we have like things like reflection We can discover things about what the templates are, you know, we're not we're not so naive about those things So I think that's that's an aspect there too One thing I don't have in here is the whole like hide render show printed kind of stuff That's not built in yet. That's a very Drupalism kind of thing Oh, yeah, right. Well, it's the without Thing right but that concept I didn't do yet, you know, so that but that's a that's a good question um, and I think you know at some level like sites are sites will be sites and like We're never gonna like there's gonna be inconsistent things in the UI that's like, oh, well, we don't print this because of these reasons like You know, I would I would love to do some work on that too, but um, that's that's I think a very hard problem to solve You know, yeah Yes, sir. That wasn't what I was going to suggest. Okay. All right. We'll go ahead. That's a good idea too Okay, but if Currently fields Use theme functions or formatters for matters right wonky arrays. Yeah Actually and four matters are now objects but If you can associate a field instead with A renderable object That renderable object can very easily have methods on it to say hey, this thing is or is not configurable If you're overriding a given renderable object subclass it Why are that to get used instead? And then right that's something that the field UI could talk to the object and say hey Yes, is this thing configurable or not if this you know, particularly subclass has changed that method to say no Then you can hide that part of the exactly why right objects give you options. Absolutely. I mean, that's that's that's a great idea too a simpler idea But yeah, I mean that like subclass the the the thing Put some information about there about what should disappear in the UI and now we just we have a way to do it now, you know Yeah, that's kind of magic land, but we could we could potentially do it All right, I think that's about time if you have more questions. I'll be around Today, I actually have to jump on a call about 15 minutes. Um, please pick up your trash Um, they told me to ask you that take the survey This is node 20 2618 Take the survey and enjoy austin. Thank you for coming