Recource Registries
CC Attribution - NonCommercial 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Navarro Bosch, Ramon
Gietema, Rob
In this talk explained what is the new resource registry tool, how it works and how developers can use it to customize the look and feel of a Plone site.
 So we are going to start. So welcome everybody. We are going to try to explain what we did in the last months in order to try to integrate JavaScript, CSS and clone. Everything began a lot of years ago with Deco, the forbidden word. Later appeared mockup and mockup tried to solve the problems of the missing JavaScript and CSS that we have in clone, all these widgets and a great structure and I really want to say thanks to the people who have been working in Deco and in mockup because they allow us to reach the point that we are now. Okay, so that was the back one. Then we did a spring in Zidanka. I think it was the second week of August. Everything was started there. So we started everything there. I really want to thank Nathan because he really did a great job organizing this team of people. Unfortunately he is not here. He is here because he is one of the fathers of this project. So later I am Ramon. I work at ISCRE.CAT. I am a member of the foundation since I don't know how. And a framework team member. It's almost Halloween, right? So I am Rob from a company called for digits. I will probably stand here. I am also a foundation member. Used to be in lots of different teams. A framework team, UI team, whatever. Organized some events which some of you might know like conference and sprints. But enough about me. Let's go to the stuff where you actually are here for. So first we are going to talk a bit about the current state of clone. So I think everybody probably should know a lot about what we already have now. So the current way of doing research registries is you have a JS registry and you have a CS registry. There are tools in your Zope instance. What you do is I hope it's a bit readable. But you probably already know how it looks like. So basically you just register JavaScript with some attributes. Same code for CSS. You just register your separate CSS file. So nothing fancy, just the basic stuff which we're used to for all these years. There's some limitations in there as a lot of people already know. JavaScript and CSS have evolved. If we go back a couple of years then actually nobody wanted to touch JavaScript anyway. So it was evil. But now we're all doing JavaScript which I really like because I always wanted to JavaScript a lot. And CSS evolved quite a lot as well. It used to be just including JavaScript files, CSS files, but as with all the package management systems, also with JavaScript and CSS as well. Dependency management was added and was definitely needed. So you could have a nice versioning and depend on other things instead of doing all the reordering which you have to do like collect the arrow up button in your CSS registry a million times to get it up on top. Stuff like that. You all know that you've all been there. Obviously precompiling less and less. So you can actually do a lot more with CSS than just writing plain CSS as Albert and Victor already showed a lot of doing variables and includes and everything which should be done. Versioning as I mentioned which is also kind of related to dependency management which you can actually just depend on the different versions of your JavaScript files and it is on the green CSS as well. And obviously mockup which is, yeah, it's there in the useful clone now. It uses almost all of the things we mentioned here. But what really was the issue is how do we integrate all that into clone because basically it was, yeah, clone was not suited to do this basically. I'm going to talk a little bit about other tools. I'm not going into too much detail but I just want to mention a few which have taken this problem and to, hey, they solved it in the wrong way. So one of them is RequireJS. RequireJS is used for dependency management. So you basically package all your JavaScript into packages and have versions and have dependencies. As you can see on the top right, it's just simply adding RequireJS in your HTML and in your code you just depend on the libraries you want to depend on and it will include them automatically and load them async. Grunt, another tool from JavaScript world which is used as a task runner. So basically you can use it to do basically whatever you want which is mostly used for is minifying your code, doing, running your tests, JSON, code compliance, all that sort of stuff. So you can, it's kind of like a make file and you can just define multiple tasks which you want to do and it will do it for you but it's more suited for JavaScript to do specific stuff which often happen in the JavaScript world. Then we have going into package management. NPM is more the Node.js, so it's server based package management tool. It lets you compile or it lets you create packages for Node. Also add dependencies and versioning and same goes for Bower which does the same thing on the client side which is used quite a lot with the in combination with Grunt to get all your dependencies up and running. Less on SAS. Yeah, so as I said, CSS has evolved as well. So, less on CSS and SAS are pre-compiled for CSS so you can do variables. You can do some examples which you've probably seen them all. Do some nestings, do lots of nice macros. Yeah, basically have well structured style sheets instead of just like the really long CSS which we used to from the old days. I said old now, right? Yeah. Revan. So well, we decided to take everything that we had in Plone. Okay, we have mockup. We have some Bower components that are using in mockup. Some are not using, are using in mockup. Some standalone files like for example we have the Plone app event recursive event JavaScript that does this recursive event and we are still using jQuery tools to make the overlay on Plone app dexterity when you create a new content type. So we have a lot of JavaScript, a lot. So we took all these kind of different components, JavaScript, CSS images and we decided to create like three different, two different main areas. One is the bundle and the resource and everything is stored on the Plone app registry. So it's in Plone and you can modify it. And then at the end you have the Diazo and the static HTML. So we're going to start with the bundles. The bundles is what we say like the main resources that are going to be called on your site. You can define as many bundles as you want. They can have dependency. It's a graph dependency so I can say I depend on that bundle and that bundle depends on another one and they are loaded in that dependency order. They can have JavaScript and see unless files that are compiled. So we can define for example this is the Plone bundle. You define which is the resource, in this case Plone. And then you can have a compiled version of that resource that has all the elements all together. The one in the top is the legacy one. It's a special bundle. It's not compiled. It's just joining all the legacy stuff that we have in Plone like the Plone app, the query tools or whatever else that we have. And you can define if it's enabled or not enabled and you can also define an expression and a conditional expression so if it's rendered, if it's my page or if it's a content type or whatever. So then we have the resources. The resources are the minimal part of all these web components idea. And you define it just some CSS, some JavaScript that it's the same component. For example, it's quite easy to understand that with the Select2. Select2 is a JavaScript and a CSS and this is the web component by itself. So this is a resource and we are defining as resources all the different mockup patterns, all the different plugins from TinyMC, TinyMC by itself, everything that we want to use as a resource in Plone, we are defining it on the registry.xml. Here you have some examples. For example, the Select2 pattern from mockup. We define it where is the JavaScript and where is the CSS. In some kind of cases, like for example, the StructureWidget, we also need to define the base URL for that widget because we want to make some references inside the CSS or the JavaScript to where is it stored. So we also can define a URL to where is that resource. And okay, you can also define the export init and some required JS options that are going to be exported to Plone in case that you want to enable that JavaScript on the JavaScript outside the required JS wall. And if you need to, you need to analyze it at some way with the shim option on required JS. Less variables. Okay, we define it a registry entity, entry that defines for each variable the value that we define. If it's defined there, then it's not taking care about the variable on the less files. So you need to be careful about what you define there because this is always going to overwrite the ones that are defined on the less file. But you can add them through the web. We will show you later how. And you can remove them no matter the problem. There is some kind of special variables like the BowerPath, the MockupPath, the MockuplessPath that are paths that in these variables you can define parameters that are going to be filled when it's rendered. And you can also use whatever you can less variables or whatever you want to define on the less as a variable, then you can use it on any of your less files. Then our patterns has options and most of them needs to be... This is... This still needs to be done in Plume 5. It's... The technology is there. The implementation is there, but we only move it to the pick-a-date pattern options. So it can be stored on the registry and we can modify it through the web. And then we can push that information to the pattern or the widget when we are rendering the widget. Development versus production. This has been really a big fight trying to see how we can solve that because Alt Mockup idea was using production. So you compile everything in a CSS and you deploy that to Plume and that's what you're using in Plume. So trying to solve the problem without integrating everything in Plume, it's been like a bit... A lot of discussions on that. But when you are in the Plume and development, it's quite easy. We just push all the information and some configuration files like the config.js and the variables that modifies everything on the fly. So you see life, you see the less files, the JavaScripts are being loaded. But on production, it's a bit more complicated because it's quite hard to... We enabled the option to compile it on the browser. So you go to the Resolve registry and you can compile it. So it's getting the result of that compilation through the browser and storing in the database so you can use it for production ideas. But if we want to use GRAN, now it's possible and we will show you later that we can extract all the information and create a bundle version compiler for production. Okay, Dayazo. Dayazo also needs to be able to enable or disable the bundles. So we added an option to the Dayazo manifest that you can decide which bundles are enabled or which bundles are disabled and then you can just import them on your Dayazo rules. So you can decide, okay, I don't want Barcelona so I just can remove it. Or you can just forget about that and write your CSS on your Dayazo theme and forget about it. Which are the views that are involved on this magic wall is the config.js that defines all the paths for all the resources that has been configured, all the shim options that have been configured, and the URLs also. For example, you can see mockup patterns, tiny messy URL is the URL where is the pattern. The less variables.js, this is defining an environment for the less compilation on the browser that just overwrites all the different variables with the needed value. So as Albert and me to explain it, the main files for plown by itself is plown.less and plown.js. Plown.less loads all the needed less files that we want to use. So for example, we want to use mockup pattern load, plown patterns, tool bar, all the different URLs that you want to import less files. You just define in the plown.less and plown.js will have them. Plown.js, the same idea. The information of the dependency, it's in the file. It's not in any other place. Everything is on the file. Yeah. So true app customization, that is still possible. It's absolutely possible and it's a lot easier even. There's a control panel on plown which you saw some screenshots in the, well, both in Eric's presentation and the one from Albert and Victor. We'll show it in a demo as well. But it's, yeah, quite easy to customize any of the JS and CSS what you want. So legacy plown stuff, how does that work? So the idea is that we have new resources registries which don't use JS registry and CSS registry anymore. They will just use the plown of registry settings. But what we did do is we created an importer for that. So basically if you do use or if your product still uses CSS registry XML and JS registry XML, they will be read and they will be converted and stored in the registry as well. So you don't need to do that yourself. Ideally you would probably want to do it in the end, just converting it all your, but you have some crazy period of migrating into the new system and don't use the old systems anymore. Yeah. So there are some incompatibilities obviously between previous registry and the new one. The new ones has, doesn't have any ordering which you had before with insert after insert before, the stuff like that. The new ones use dependencies which automatically create that. So I think probably all, well, most of the things will work but you might have to tweak it a bit to make it 100% work. But I think that shouldn't be that much issues. Yeah. So as I said, the standard resources which are available are all the mock-up ones are there. I created a list of all the mock-up patterns which are in there. Those are available by default and you can obviously add any patterns or whatever you would like to add to that. Yeah. As Ramon said, you can, you are able to do, if you don't want to use blown as in development mode, but you want to do some development locally just with static HTML and with, with your JavaScript and CSS files, on your file system, you are able to do that. So what you can do is use this Python script to extract all the information from the research registries and have it, it will create a grunt file which can be used to just run grunt locally and it will have like the full path of every resource there is and you can just combine it there. So now the most important part, the demo. Whoa. And it's obviously, everything is in Catalan, so, but you all know Catalan, right? Like I do. Yeah. Catalan rocks. Okay. So let's, I wasn't kidding. I would change the, I kind of changed the browser language, but I would try to create the site in English. So it says create a new log, it means create a new site and create a new plone, it means create a new plone, create a new plone. So I'm going to choose English, no worry. So we have a language course as well. Okay. Just, just to show that I'm not doing any trick, I'm creating a new site. This is card depth. So here we have a plone, so it just installed plone. Now it's some production by default. That means that any change I'm doing is not going to be applied because it's taking the CSS that are compiled and are stable on the Barcelona, the CSS and Barcelona package and plone CSS and JavaScript is in the plone package. And it's always going to show that unless you install any add-on that adds a new bundle or creates a new legacy JavaScript. This is production. Nothing is going to change that CSS and less file or JavaScript. So the first thing that we need to do is move it to development. Okay. Now it's in development. And now, for example, I'm going to try to do the same demo that Victor did, but a bit different. So this is a variable that is called plone body background. And I'm going to move it to, I don't know, I'm not a designer as they say we have, our taste is really, really bad. So now I save it. And I get, I get, I get really nice. I prefer that. So I just can change the variables that are there. And the development mode takes a bit when you are loading because it's, it's loading, I don't know, maybe 100 different resources. So it's a bit complicated. So what does I want to show you? I'm going, I can remove the variable, for example, in this case, this one. Yeah. Okay. And now it's going to take the one that's on the, on the, on the file, define it on, on the variables. That's the correct one. There is no problem. Everything is going to still work if it's defined on the last file. So what else? Okay. For example, we can try to compile through the web, a bundle. We are going to compile Barcelona. And it's starting at full заг. Compiler, Romano where you want from the set and it's like, I'm going to, I'm going to move my job around. And you go to a device, it wins. So if you want to take about seven trigger scenarios. And so because you agree with me for an antibiotics And if you want, you can edit also the file. But you can also take, for example, toolbar. I want to customize this one. So I just press that, and I took that. And I want that my toolbar, it's not 60 pixels. It's, I don't know, 120. So I'm going to save it. And now my toolbar is 120. So I don't know if this is, I don't think that the user should use that, because it's going to break the site. But it allows us to play with that. And the most important thing is that it allows us to modify the less files on the file system and see it directly live on the changes on the blown site, if you want to check. And I wanted to show something else. I don't remember what. Just to be, we updated the TinyMessy content in CSS. So now it looks like Barcelona. It's not as ugly as before. And I don't know what else. Let me check. Yeah. That was the demo. And let's go back to here. Migration. There are, you can still use the legacy.js registry and CSS precious history files. But if you want to migrate to the new Preserve registry, I just, I did a test yesterday to migrate one of my packages to this. And I was written down what I did. So I tried to refactor the JavaScript to be a pattern and to create a less file. Or at least use your required.js. So it's much easier to integrate. I created a bundle. So it works in production. I moved with all the JavaScript registry and CSS registry to the registry.xml. I updated because Plome 5 has jQuery.1.11. So life doesn't work. So if you have JavaScript that has life, you need to change to on. And I never lose hope that it works. So I'm going to show you which package I move it. This package, it's really, I don't know if you know, it's a mosaic. Mosaic is a small toy that we've been working on the Barceloneta Spring, it's like the rebirth of the forbidden word. OK, here I have it. OK, it's there. So we migrated mosaic to be compatible with Plome 5. There is a branch for that, mosaic. And you can test it. I don't know if it's the rebirth of Dico. I must forbid an usage. Yeah, yeah, yeah, I know. So if everything was fine, you can edit it. And you can then save it. And you can move things up and down as you want. And you get to save it. So it took me less than one hour to migrate this package from the old to the new one. So I think it's a good idea to be the one. And yeah, questions? If there is any question? OK, I'm going to mic. Hi. I don't know if you pointed out already, but there is a way to find what are the variables that are being overridden in the resource registry. For example, a less variable, there is a way to point them out. Any variable that's defined on the control panel pitch, it's overridden its value on the less file. So if you don't want that variable overwrites the file, just remove it. Yeah, OK, but if there is no control of the change, because the variable is set on the registry. So if it's there, it's going to be that one. It's not taking care which one is different from the. You can see them all in the control panel. So there's a complete list in the control panel, not the resource control panel, but on the resource registry control panel. So if a variable is there, it's because you're overridden there. Yeah, yeah. Right. What if you created a new variable? Is it doable? Yeah, if you can create through the web, I need to stop it and start. You can create through the web a new variable that is defined on the less file, and it's going to overwrite the one that's on the less file. Just if it's there, you can define these variables also in the registry.xml. So when you install your product, it overwrites the variables from the less. Thanks. One of the motivations behind doing the MoCAp project was that the resource registry was left behind in time with the technology used for doing the stuff it did. And one of the ideas that using MoCAp was bringing in was that the front end developers didn't need to actually start a blown instance. Sorry. Another thing is in the JavaScript world, sometimes you're using some tool to do something, and then two months later, it's another tool that should be used. So just a month? So my question is, is this going back to the long handling what the JavaScript developers should be handling? And maybe in three years, this new resource registry is going to be in the same state as the old resource registry because Grunt is no longer used and nobody updated the resource registry. Do you have that concern? I mean, Grunt has been there. I mean, Grunt has been there for quite a long time now, and I don't think it will go away that fast. And even though if it does, then I think because we have the whole dependency management and that stuff in-plown now, if we want to have a different back end idea, basically, if there's a new technology, it's a lot easier to switch because it matches a lot with modern JavaScript development as the current resource registries do because they don't only have a list, basically, of the JavaScript. So I think, yeah, I mean, it won't last forever, definitely, because the JavaScript world is moving really fast. But it's a lot easier for us now to adjust to new standards and to new methods than it used to be. But I think this part of JavaScript will probably not change that often. And if it does, then we can easily adjust to it. OK. Thank you. Just a question about migration. If you migrate your old resource registry XML to be compatible with Plone 5, can you make a package that supports both Plone 5 and Plone 4 at the same time, or is this a backwards, incompatible migration? I guess it'll work, because the idea is basically the idea of the file. So if you register it twice, and it will just put it in the registry. So basically, if you have an old Plone version which doesn't have Plone up registry in there, then it will just ignore the registry XML file. And if you have Plone 5 file, it has both registry XML and the jsregistry.xml, then it will just overwrite. And it will pick, I'm not sure which step will be run later, but it will just overwrite those. And you can also have, I think, generic setup conditions in the generic setup to have a profile specific for Plone 5 or below, something like that. But even though if you don't do any of that conditional stuff, I think it'll just work. Thanks. I have a question. The patterns are still developed in the mockup repository, as far as I know. And if you develop one, how do you get this pattern to Plone? They cope it then over somehow to Plone. Do it, is there some grand task, make task defined? Do you start it from mockup, or does Plone start this process somehow? So one of the things that the Catalan loves is being independent. So I think that I was waiting that question. You know. So yeah, for example, the toolbar is a pattern. And the pattern of toolbar is in Plone, in CMF Plone. I think that mockup project is great because it's taking care about a lot of different widgets and patterns. And it's great because it's a good place to put all together. But if my company want to create a pattern, I don't want to fork mockups, so I want to create in my app. So we created the pattern from the toolbar. On Plone, specifics of the people can see that you can create your own pattern at your own place without any problem. And you can integrate easily with Plone. And the technology is the same. We are using mockup core for doing the main thing. So no problem. But you're not depending on the mockup package? Now, mockup package, as we remove all the symbolic links inside, now Plone depends on mockup package because the package, it's by itself the patterns. And we are publishing all these resources in the Plone space. Yeah. When you show that you can create your own bundle through the web and then customize the less file through the web as well, you said that it kind of saves the result into the file system? You save everything into a traversal. Into, I would say, English. It's like the theme editor that you can save it on the database. All right. So it does only work when you're on development mode, right? Yeah. But for example, if you try to, if you overwrite that there, it's going to be on the database always. Yeah. But can you switch back to production mode and it still works? Let me remember. No, because when you are moving to production mode, it's taking the CSS that's compiled. If you want to create a new compiler version, then you need to run the GRAND that's going to get that. And is there anything planned to allow that? I mean, you can change some things through the web and it's going to compile everything and you can make that on production? Yeah. If you change anything on the web and you overwrite, and then you go to the bundles, the first option, and you press build, it's going to build a compiler version with the version that you created. OK, but I still need to run GRAND on the server. Without any need to run GRAND, you can use through the web. OK, good. So in your talk here, you've sort of identified a couple of things that we're going to need to do in the future in order to move forward with this. Be able to upgrade packages so that they compile or said they comply with this new registry. Be able to work through the web and then compile those things and get those things set up so that you can run in production with them. Is there a plan or are you guys planning on sprinting or working over the next couple of days here on making documentation that would explain how that actually operates? OK. Sorry. I am not a paid shell. I just knew. There we go. We've talked before. I'll take my payment offline. Yeah, so if anybody wants to sprint, there is a lot of subjects on that idea. Yeah, I mean, definitely. For this idea to people to know it, they have to work with it. So if people want to sprint on it or add anything, basically, just join. And it's probably not sure what all the sprint topics will be. But there's still a lot to do, although it's quite far already. But at least documentation is one of the parts. We have some documentation, but it should be a lot better, definitely. It's been only four months since we started to do this. OK, so thank you, everybody. And thank you. Thank you.
 So we are going to start.  So welcome everybody. We are going to try to explain what we did in the last months  in order to try to integrate JavaScript, CSS and clone. Everything began a lot of years  ago with Deco, the forbidden word. Later appeared mockup and mockup tried to solve the problems  of the missing JavaScript and CSS that we have in clone, all these widgets and a great  structure and I really want to say thanks to the people who have been working in Deco  and in mockup because they allow us to reach the point that we are now. Okay, so that was  the back one. Then we did a spring in Zidanka. I think it was the second week of August.  Everything was started there. So we started everything there. I really want to thank Nathan  because he really did a great job organizing this team of people. Unfortunately he is not  here. He is here because he is one of the fathers of this project. So later I am Ramon.  I work at ISCRE.CAT. I am a member of the foundation since I don't know how. And a framework  team member. It's almost Halloween, right? So I am Rob from a company called for digits.  I will probably stand here. I am also a foundation member. Used to be in lots of different teams.  A framework team, UI team, whatever. Organized some events which some of you might know like  conference and sprints. But enough about me. Let's go to the stuff where you actually are  here for. So first we are going to talk a bit about the current state of clone. So I think  everybody probably should know a lot about what we already have now. So the current way  of doing research registries is you have a JS registry and you have a CS registry. There  are tools in your Zope instance. What you do is I hope it's a bit readable. But you  probably already know how it looks like. So basically you just register JavaScript with  some attributes. Same code for CSS. You just register your separate CSS file. So nothing  fancy, just the basic stuff which we're used to for all these years. There's some limitations  in there as a lot of people already know. JavaScript and CSS have evolved. If we go back  a couple of years then actually nobody wanted to touch JavaScript anyway. So it was evil.  But now we're all doing JavaScript which I really like because I always wanted to JavaScript  a lot. And CSS evolved quite a lot as well. It used to be just including JavaScript files,  CSS files, but as with all the package management systems, also with JavaScript and CSS as well.  Dependency management was added and was definitely needed. So you could have a nice versioning  and depend on other things instead of doing all the reordering which you have to do like  collect the arrow up button in your CSS registry a million times to get it up on top. Stuff  like that. You all know that you've all been there. Obviously precompiling less and less.  So you can actually do a lot more with CSS than just writing plain CSS as Albert and  Victor already showed a lot of doing variables and includes and everything which should be  done. Versioning as I mentioned which is also kind of related to dependency management  which you can actually just depend on the different versions of your JavaScript files  and it is on the green CSS as well. And obviously mockup which is, yeah, it's there in the useful  clone now. It uses almost all of the things we mentioned here. But what really was the  issue is how do we integrate all that into clone because basically it was, yeah, clone  was not suited to do this basically. I'm going to talk a little bit about other tools. I'm  not going into too much detail but I just want to mention a few which have taken this  problem and to, hey, they solved it in the wrong way. So one of them is RequireJS. RequireJS  is used for dependency management. So you basically package all your JavaScript into  packages and have versions and have dependencies. As you can see on the top right, it's just  simply adding RequireJS in your HTML and in your code you just depend on the libraries  you want to depend on and it will include them automatically and load them async.  Grunt, another tool from JavaScript world which is used as a task runner. So basically  you can use it to do basically whatever you want which is mostly used for is minifying  your code, doing, running your tests, JSON, code compliance, all that sort of stuff. So  you can, it's kind of like a make file and you can just define multiple tasks which you  want to do and it will do it for you but it's more suited for JavaScript to do specific  stuff which often happen in the JavaScript world.  Then we have going into package management. NPM is more the Node.js, so it's server based  package management tool. It lets you compile or it lets you create packages for Node. Also  add dependencies and versioning and same goes for Bower which does the same thing on the  client side which is used quite a lot with the in combination with Grunt to get all your  dependencies up and running. Less on SAS. Yeah, so as I said, CSS has evolved as well.  So, less on CSS and SAS are pre-compiled for CSS so you can do variables. You can do some  examples which you've probably seen them all. Do some nestings, do lots of nice macros.  Yeah, basically have well structured style sheets instead of just like the really long  CSS which we used to from the old days. I said old now, right? Yeah. Revan.  So well, we decided to take everything that we had in Plone. Okay, we have mockup. We  have some Bower components that are using in mockup. Some are not using, are using in  mockup. Some standalone files like for example we have the Plone app event recursive event  JavaScript that does this recursive event and we are still using jQuery tools to make  the overlay on Plone app dexterity when you create a new content type. So we have a lot  of JavaScript, a lot. So we took all these kind of different components, JavaScript,  CSS images and we decided to create like three different, two different main areas. One is  the bundle and the resource and everything is stored on the Plone app registry. So it's  in Plone and you can modify it. And then at the end you have the Diazo and the static  HTML. So we're going to start with the bundles. The bundles is what we say like the main resources  that are going to be called on your site. You can define as many bundles as you want.  They can have dependency. It's a graph dependency so I can say I depend on that bundle and that  bundle depends on another one and they are loaded in that dependency order. They can  have JavaScript and see unless files that are compiled. So we can define for example  this is the Plone bundle. You define which is the resource, in this case Plone. And then  you can have a compiled version of that resource that has all the elements all together. The  one in the top is the legacy one. It's a special bundle. It's not compiled. It's just joining  all the legacy stuff that we have in Plone like the Plone app, the query tools or whatever  else that we have. And you can define if it's enabled or not enabled and you can also define  an expression and a conditional expression so if it's rendered, if it's my page or if  it's a content type or whatever. So then we have the resources. The resources are the  minimal part of all these web components idea. And you define it just some CSS, some JavaScript  that it's the same component. For example, it's quite easy to understand that with the  Select2. Select2 is a JavaScript and a CSS and this is the web component by itself. So  this is a resource and we are defining as resources all the different mockup patterns,  all the different plugins from TinyMC, TinyMC by itself, everything that we want to use as  a resource in Plone, we are defining it on the registry.xml. Here you have some examples.  For example, the Select2 pattern from mockup. We define it where is the JavaScript and where  is the CSS. In some kind of cases, like for example, the StructureWidget, we also need  to define the base URL for that widget because we want to make some references inside the  CSS or the JavaScript to where is it stored. So we also can define a URL to where is that  resource. And okay, you can also define the export init and some required JS options that  are going to be exported to Plone in case that you want to enable that JavaScript on  the JavaScript outside the required JS wall. And if you need to, you need to analyze it  at some way with the shim option on required JS. Less variables. Okay, we define it a registry  entity, entry that defines for each variable the value that we define. If it's defined  there, then it's not taking care about the variable on the less files. So you need to  be careful about what you define there because this is always going to overwrite the ones  that are defined on the less file. But you can add them through the web. We will show  you later how. And you can remove them no matter the problem. There is some kind of  special variables like the BowerPath, the MockupPath, the MockuplessPath that are paths  that in these variables you can define parameters that are going to be filled when it's rendered.  And you can also use whatever you can less variables or whatever you want to define on  the less as a variable, then you can use it on any of your less files. Then our patterns  has options and most of them needs to be... This is... This still needs to be done in  Plume 5. It's... The technology is there. The implementation is there, but we only move  it to the pick-a-date pattern options. So it can be stored on the registry and we can  modify it through the web. And then we can push that information to the pattern or the  widget when we are rendering the widget. Development versus production. This has been  really a big fight trying to see how we can solve that because Alt Mockup idea was using  production. So you compile everything in a CSS and you deploy that to Plume and that's  what you're using in Plume. So trying to solve the problem without integrating everything  in Plume, it's been like a bit... A lot of discussions on that. But when you are in  the Plume and development, it's quite easy. We just push all the information and some  configuration files like the config.js and the variables that modifies everything on  the fly. So you see life, you see the less files, the JavaScripts are being loaded. But  on production, it's a bit more complicated because it's quite hard to... We enabled the  option to compile it on the browser. So you go to the Resolve registry and you can compile  it. So it's getting the result of that compilation through the browser and storing in the database  so you can use it for production ideas. But if we want to use GRAN, now it's possible  and we will show you later that we can extract all the information and create a bundle version  compiler for production. Okay, Dayazo. Dayazo also needs to be able to enable or disable  the bundles. So we added an option to the Dayazo manifest that you can decide which  bundles are enabled or which bundles are disabled and then you can just import them on your  Dayazo rules. So you can decide, okay, I don't want Barcelona so I just can remove it. Or  you can just forget about that and write your CSS on your Dayazo theme and forget about  it. Which are the views that are involved on this magic wall is the config.js that defines  all the paths for all the resources that has been configured, all the shim options that  have been configured, and the URLs also. For example, you can see mockup patterns, tiny  messy URL is the URL where is the pattern. The less variables.js, this is defining an  environment for the less compilation on the browser that just overwrites all the different  variables with the needed value. So as Albert and me to explain it, the main files for plown  by itself is plown.less and plown.js. Plown.less loads all the needed less files that we want  to use. So for example, we want to use mockup pattern load, plown patterns, tool bar, all  the different URLs that you want to import less files. You just define in the plown.less  and plown.js will have them. Plown.js, the same idea. The information of the dependency,  it's in the file. It's not in any other place. Everything is on the file.  Yeah. So true app customization, that is still possible. It's absolutely possible and it's  a lot easier even. There's a control panel on plown which you saw some screenshots in  the, well, both in Eric's presentation and the one from Albert and Victor. We'll show  it in a demo as well. But it's, yeah, quite easy to customize any of the JS and CSS what  you want. So legacy plown stuff, how does that work? So the idea is that we have new  resources registries which don't use JS registry and CSS registry anymore. They will just use  the plown of registry settings. But what we did do is we created an importer for that.  So basically if you do use or if your product still uses CSS registry XML and JS registry  XML, they will be read and they will be converted and stored in the registry as well. So you  don't need to do that yourself. Ideally you would probably want to do it in the end, just  converting it all your, but you have some crazy period of migrating into the new system  and don't use the old systems anymore. Yeah. So there are some incompatibilities obviously  between previous registry and the new one. The new ones has, doesn't have any ordering  which you had before with insert after insert before, the stuff like that. The new ones  use dependencies which automatically create that. So I think probably all, well, most  of the things will work but you might have to tweak it a bit to make it 100% work. But  I think that shouldn't be that much issues. Yeah. So as I said, the standard resources  which are available are all the mock-up ones are there. I created a list of all the mock-up  patterns which are in there. Those are available by default and you can obviously add any patterns  or whatever you would like to add to that. Yeah. As Ramon said, you can, you are able  to do, if you don't want to use blown as in development mode, but you want to do some  development locally just with static HTML and with, with your JavaScript and CSS files,  on your file system, you are able to do that. So what you can do is use this Python script  to extract all the information from the research registries and have it, it will create a grunt  file which can be used to just run grunt locally and it will have like the full path of every  resource there is and you can just combine it there. So now the most important part,  the demo. Whoa. And it's obviously, everything is in Catalan, so, but you all know Catalan,  right? Like I do. Yeah. Catalan rocks. Okay. So let's, I wasn't kidding. I would change  the, I kind of changed the browser language, but I would try to create the site in English.  So it says create a new log, it means create a new site and create a new plone, it means  create a new plone, create a new plone. So I'm going to choose English, no worry. So  we have a language course as well. Okay. Just, just to show that I'm not doing any  trick, I'm creating a new site. This is card depth. So here we have a plone, so it just  installed plone. Now it's some production by default. That means that any change I'm  doing is not going to be applied because it's taking the CSS that are compiled and are stable  on the Barcelona, the CSS and Barcelona package and plone CSS and JavaScript is in the plone  package. And it's always going to show that unless you install any add-on that adds a  new bundle or creates a new legacy JavaScript. This is production. Nothing is going to change  that CSS and less file or JavaScript. So the first thing that we need to do is move it  to development. Okay. Now it's in development. And now, for example, I'm going to try to  do the same demo that Victor did, but a bit different. So this is a variable that is called  plone body background. And I'm going to move it to, I don't know, I'm not a designer as  they say we have, our taste is really, really bad. So now I save it. And I get, I get, I  get really nice. I prefer that. So I just can change the variables that are there. And  the development mode takes a bit when you are loading because it's, it's loading, I  don't know, maybe 100 different resources. So it's a bit complicated. So what does I  want to show you? I'm going, I can remove the variable, for example, in this case, this  one. Yeah. Okay. And now it's going to take the one that's on the, on the, on the file,  define it on, on the variables. That's the correct one. There is no problem. Everything  is going to still work if it's defined on the last file. So what else? Okay. For example,  we can try to compile through the web, a bundle. We are going to compile Barcelona. And it's  starting at full заг. Compiler, Romano where you want from the set and it's like, I'm  going to, I'm going to move my job around. And you go to a device, it wins. So if you  want to take about seven trigger scenarios. And so because you agree with me for an antibiotics  And if you want, you can edit also the file.  But you can also take, for example, toolbar.  I want to customize this one.  So I just press that, and I took that.  And I want that my toolbar, it's not 60 pixels.  It's, I don't know, 120.  So I'm going to save it.  And now my toolbar is 120.  So I don't know if this is, I don't think that the user should  use that, because it's going to break the site.  But it allows us to play with that.  And the most important thing is that it allows us to  modify the less files on the file system and see it  directly live on the changes on the blown site, if you want  to check.  And I wanted to show something else.  I don't remember what.  Just to be, we updated the TinyMessy content in CSS.  So now it looks like Barcelona.  It's not as ugly as before.  And I don't know what else.  Let me check.  Yeah.  That was the demo.  And let's go back to here.  Migration.  There are, you can still use the legacy.js registry and CSS  precious history files.  But if you want to migrate to the new Preserve registry, I  just, I did a test yesterday to migrate one of my packages  to this.  And I was written down what I did.  So I tried to refactor the JavaScript to be a pattern and  to create a less file.  Or at least use your required.js.  So it's much easier to integrate.  I created a bundle.  So it works in production.  I moved with all the JavaScript registry and CSS registry  to the registry.xml.  I updated because Plome 5 has jQuery.1.11.  So life doesn't work.  So if you have JavaScript that has life, you need to change  to on.  And I never lose hope that it works.  So I'm going to show you which package I move it.  This package, it's really, I don't know if you know, it's  a mosaic.  Mosaic is a small toy that we've been working on the  Barceloneta Spring, it's like the rebirth of the forbidden  word.  OK, here I have it.  OK, it's there.  So we migrated mosaic to be compatible with Plome 5.  There is a branch for that, mosaic.  And you can test it.  I don't know if it's the rebirth of Dico.  I must forbid an usage.  Yeah, yeah, yeah, I know.  So if everything was fine, you can edit it.  And you can then save it.  And you can move things up and down as you want.  And you get to save it.  So it took me less than one hour to migrate this package  from the old to the new one.  So I think it's a good idea to be the one.  And yeah, questions?  If there is any question?  OK, I'm going to mic.  Hi.  I don't know if you pointed out already,  but there is a way to find what are the variables that  are being overridden in the resource registry.  For example, a less variable, there  is a way to point them out.  Any variable that's defined on the control panel pitch,  it's overridden its value on the less file.  So if you don't want that variable overwrites the file,  just remove it.  Yeah, OK, but if there is no control of the change,  because the variable is set on the registry.  So if it's there, it's going to be that one.  It's not taking care which one is different from the.  You can see them all in the control panel.  So there's a complete list in the control panel,  not the resource control panel, but on the resource registry  control panel.  So if a variable is there, it's because you're overridden there.  Yeah, yeah.  Right.  What if you created a new variable?  Is it doable?  Yeah, if you can create through the web,  I need to stop it and start.  You can create through the web a new variable  that is defined on the less file,  and it's going to overwrite the one that's on the less file.  Just if it's there, you can define these variables  also in the registry.xml.  So when you install your product,  it overwrites the variables from the less.  Thanks.  One of the motivations behind doing the MoCAp project  was that the resource registry was  left behind in time with the technology used  for doing the stuff it did.  And one of the ideas that using MoCAp was bringing  in was that the front end developers didn't  need to actually start a blown instance.  Sorry.  Another thing is in the JavaScript world,  sometimes you're using some tool to do something,  and then two months later, it's another tool  that should be used.  So just a month?  So my question is, is this going back to the long handling  what the JavaScript developers should be handling?  And maybe in three years, this new resource registry  is going to be in the same state as the old resource  registry because Grunt is no longer used  and nobody updated the resource registry.  Do you have that concern?  I mean, Grunt has been there.  I mean, Grunt has been there for quite a long time now,  and I don't think it will go away that fast.  And even though if it does, then I  think because we have the whole dependency management  and that stuff in-plown now, if we  want to have a different back end idea, basically,  if there's a new technology, it's a lot easier to switch  because it matches a lot with modern JavaScript development  as the current resource registries do  because they don't only have a list, basically,  of the JavaScript.  So I think, yeah, I mean, it won't last forever, definitely,  because the JavaScript world is moving really fast.  But it's a lot easier for us now to adjust to new standards  and to new methods than it used to be.  But I think this part of JavaScript will probably not  change that often.  And if it does, then we can easily adjust to it.  OK.  Thank you.  Just a question about migration.  If you migrate your old resource registry XML  to be compatible with Plone 5, can you  make a package that supports both Plone 5 and Plone 4  at the same time, or is this a backwards, incompatible  migration?  I guess it'll work, because the idea is basically the idea  of the file.  So if you register it twice, and it will just put it  in the registry.  So basically, if you have an old Plone version which  doesn't have Plone up registry in there,  then it will just ignore the registry XML file.  And if you have Plone 5 file, it has both registry XML  and the jsregistry.xml, then it will just overwrite.  And it will pick, I'm not sure which step will be run later,  but it will just overwrite those.  And you can also have, I think, generic setup conditions  in the generic setup to have a profile specific for Plone 5  or below, something like that.  But even though if you don't do any of that conditional stuff,  I think it'll just work.  Thanks.  I have a question.  The patterns are still developed in the mockup  repository, as far as I know.  And if you develop one, how do you  get this pattern to Plone?  They cope it then over somehow to Plone.  Do it, is there some grand task, make task defined?  Do you start it from mockup, or does Plone  start this process somehow?  So one of the things that the Catalan loves  is being independent.  So I think that I was waiting that question.  You know.  So yeah, for example, the toolbar is a pattern.  And the pattern of toolbar is in Plone, in CMF Plone.  I think that mockup project is great because it's taking care  about a lot of different widgets and patterns.  And it's great because it's a good place to put all together.  But if my company want to create a pattern,  I don't want to fork mockups, so I want to create in my app.  So we created the pattern from the toolbar.  On Plone, specifics of the people  can see that you can create your own pattern at your own place  without any problem.  And you can integrate easily with Plone.  And the technology is the same.  We are using mockup core for doing the main thing.  So no problem.  But you're not depending on the mockup package?  Now, mockup package, as we remove all the symbolic links  inside, now Plone depends on mockup package  because the package, it's by itself the patterns.  And we are publishing all these resources in the Plone space.  Yeah.  When you show that you can create your own bundle  through the web and then customize the less file  through the web as well, you said that it kind of saves  the result into the file system?  You save everything into a traversal.  Into, I would say, English.  It's like the theme editor that you can save it on the database.  All right.  So it does only work when you're on development mode, right?  Yeah.  But for example, if you try to, if you overwrite that there,  it's going to be on the database always.  Yeah.  But can you switch back to production mode and it still works?  Let me remember.  No, because when you are moving to production mode,  it's taking the CSS that's compiled.  If you want to create a new compiler version,  then you need to run the GRAND that's going to get that.  And is there anything planned to allow that?  I mean, you can change some things through the web  and it's going to compile everything  and you can make that on production?  Yeah.  If you change anything on the web and you overwrite,  and then you go to the bundles, the first option,  and you press build, it's going to build a compiler version  with the version that you created.  OK, but I still need to run GRAND on the server.  Without any need to run GRAND, you can use through the web.  OK, good.  So in your talk here, you've sort of identified a couple  of things that we're going to need to do in the future in order  to move forward with this.  Be able to upgrade packages so that they compile or said  they comply with this new registry.  Be able to work through the web and then compile those things  and get those things set up so that you can run in production  with them.  Is there a plan or are you guys planning on sprinting  or working over the next couple of days here  on making documentation that would explain how that actually  operates?  OK.  Sorry.  I am not a paid shell.  I just knew.  There we go.  We've talked before.  I'll take my payment offline.  Yeah, so if anybody wants to sprint,  there is a lot of subjects on that idea.  Yeah, I mean, definitely.  For this idea to people to know it,  they have to work with it.  So if people want to sprint on it or add anything, basically,  just join.  And it's probably not sure what all the sprint topics will be.  But there's still a lot to do, although it's quite far already.  But at least documentation is one of the parts.  We have some documentation, but it should be a lot better,  definitely.  It's been only four months since we started to do this.  OK, so thank you, everybody.  And thank you.  Thank you.
Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_0_119.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_120_323.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_324_935.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_936_1031.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_1032_1115.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_1116_3107.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_3108_3539.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_3540_3719.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_3720_7475.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_7476_9275.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_9276_9359.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_9360_11063.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_11064_11423.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_11424_11483.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_11484_11939.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_11940_13175.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_13176_13655.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_13656_14447.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_14448_14615.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_14616_16703.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_16704_17699.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_17700_25871.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_25872_25931.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_25932_29171.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_29172_30215.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_30216_30275.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_30276_30335.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_30336_30491.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_30492_30647.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_30648_34115.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_34116_39143.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_39144_40943.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_40944_41135.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_41136_42311.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_42312_43487.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_43488_43607.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_43608_43811.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_43812_44171.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_44172_45203.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_45204_45479.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_45480_47723.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_47724_49943.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_49944_59615.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_59616_59699.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_59700_59747.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_59748_59807.png Plone_Conference_2014_-_Front-end_development_with_Plone_-_Ramon_Navarro_Bosch___Rob_Gietema_HD_WEB_59808_59840.png