 First and foremost, thank you guys so much for coming to this session. This is a topic that Randall and myself are very excited to talk about. And obviously from the look of the crowd, you guys are pretty excited as well. So thank you so much for your support, for being here, it means a lot to us. Let me just start by introducing myself. My name is Travis Tidwell. I'm the co-founder and CTO of Form.io. And to my right is Randall Knutson. He is our lead architect at Form.io as well. And we're very excited to talk about Jason-powered forms in Drupal. Also, just so you know, if you wanna find us on Twitter, you can find us at form underscore IO. And as well as on GitHub, we have a very robust open source offering. That's something that we're very proud of, is that a lot of our capabilities, a lot of our renderers, the form builders, a lot of the stuff you're gonna see tonight is open source and it's on GitHub. So please check that out, come and star our repos. That means a lot to us when you guys do that. So just to kind of give you a little bit of a history about Randall and myself, we actually have a very long and fruitful history in the Drupal community. We've, both of us, started in Drupal about 10 years ago and had a wonderful experience with Drupal. As of recently though, just kind of as a disclaimer, we've somewhat kind of left Drupal. We started to go off and do our own thing with Form IO as well as some different technologies. And really our journey looks something similar to this. We started off with in Drupal, we loved it. In fact, whenever Dries asked that question, did Drupal change your life? We were among of you that stood up. Drupal definitely changed my life, it changed Randall's life, and it means a lot to us. However, as most of you guys are very aware, about a couple of years ago, the market changed. There's a lot of things that have been happening with Headless Drupal, new technologies coming out. And there was this call to adventure from being a developer myself and Randall as well, that there were a lot of technologies that we wanted to explore. Those included AngularJS, ReactJS, something I'm very passionate about, NodeJS, a lot of these JS JavaScript, you kind of see the trend going on here. And out of that kind of came this rebirth. We had this almost awakening of this new way of thinking, this new way of building applications and it really excited us. And out of that came this revelation, if you will, on this new way of building applications, but even more importantly, this new way of dealing with building and managing forms, which is what we're gonna talk about today. And out of that came this transformation and we formed a company around that. That's this concept of JSON-powered forms, which we will be talking about today. And through that experience, we realized kind of retrospectively looking back on our experiences with Drupal that what we have done at Form.io has a massive implications on the Drupal community. In fact, what this concept of powering your website with JSON-powered components really could serve as a massive benefit. In fact, for a lot of the discussions going on in the Drupal community right now, where people are talking about Headless Drupal and people are talking about, how are we gonna deal with this? This idea and this concept really serves as an elegant bridge where you can keep the power of Drupal in place because Drupal is an amazing technology, very powerful, while at the same time liberating yourself to handle and deal with all of these new technologies. So I'm excited to talk to you guys about that capability. Another thing that I like to do is if any of you guys wanna follow along with this presentation, I know that's might be hard to see on this presentation up there, this is all online, this entire presentation you guys can log on. There is a big video involved, so you guys might bring down the network if all of you sign on at once, but it should be fine, right? None of you guys have had wireless issues this conference have you, so I'm sure we'll be okay. So before I get started, let me just tell you a little bit about Form.io. We will be talking a lot about Form.io in this presentation, but just as a quick synopsis, we are a SaaS, a software as a service company, built around this concept of JSON-powered forms. Essentially what we provide is a form builder interface that allows you to build a form using a drag and drop easy to use form builder where developers or even technically savvy people, not developers, can build forms and those produce JSON schemas. And then that generates a REST API where you can immediately connect those forms to the REST API and then your world opens. You can do all kinds of things from integrating it to third party providers. And very recently what we've done is we put a lot of effort in building a module which we'll talk about later in this presentation where we've taken that concept, brought it to Drupal and to really bring this JSON-powered form concept into the Drupal community. So this talk will be a headless Drupal talk and all of you guys know this, that Drupal is kind of the hot topic right now. It's very hot, you know, it's so hot right now. But at the same time, I actually feel like the Drupal community is getting somewhat fatigued by this conversation. And I sense that because there's a lot of banter going on about, oh, it should be this way, it should be that way. You know what, Drupal is just not good enough, let's just not use Drupal. And that's going on right now. And I think a lot of that churn is happening because this has been somewhat of a disruptive thing that's happened to the web where you have the separation between front-end and back-end and I'm gonna talk about how Drupal got to where it is today. But I would like to frame this conversation and just say that this will be a headless Drupal talk, but it's gonna be a much different approach than I think what you guys are probably used to with a typical headless Drupal talk. And I think this different approach in my, as far as I'm concerned, is a very elegant bridge. It allows you to fully utilize Drupal to its powerful extent while at the same time introducing these capabilities of building these next generation web applications. And there's a reason why a headless Drupal is such a big deal is because there's a lot of benefits of these separated architectures. One of those is that these applications can now really kind of exist on their own. These applications can not only have the templates included in the app itself on the front-end, it can also include databases. And then in conjunction with all of the JavaScript libraries what you really end up with as a product is the front-end app. And that front-end application, and I'm gonna talk about this in a little bit, can be deployed anywhere. It's not constrained to the web. And I think that that's one massive thing about headless Drupal in this movement is the reason why it's becoming so popular. If you actually point the direction back at the server on the flip side of that, even from a server side's perspective, we have a number of benefits as well. No longer do we only have to deal with websites. We can now deal with all of these IoT devices because now Drupal can suddenly handle APIs using JSON schemas, XML, whatever. The point is that that is also a massive benefit as well, not only from the application perspective but also on the server. There is one benefit that I feel though almost eclipses all of these. And unfortunately in a lot of these conversations that I've been hearing about headless Drupal, it's almost like this one benefit that I'm gonna bring up next is something that's kind of not really thought about. And in my opinion, this is the most powerful aspect of headless Drupal, which is that the applications are now deployable anywhere. And this only happens if you construct your applications in a certain way where there's total separation between the application and the server, meaning the server should never send markup to the client. And whenever you build your apps this way, you really open up the world to deploy that application in a number of devices using Apache Cordova. You can install your app on an S3 bucket. You can use a CDN. In fact, if you go to form.io, our entire application is served from a CDN. And you can't serve a server-side web application on a CDN. You can also deploy it on a smart TV. GitHub Pages is becoming a big deal as hosting your website for you. And also another thing, I put it down there at the bottom. I don't know if any of you guys have experimented with this, but this is an amazing technology that came out of GitHub called Electron that allows you to compile a web app as a desktop application. And I know you guys are saying, oh, why would we wanna do that? Well, there's a number of enterprise organizations who are still locked into IE7. And this actually serves as a remarkable solution. You compile their entire web app in an Electron desktop application, you deploy it to their entire enterprise, and now you're suddenly dealing with modern-day web browsers, and you don't have to deal with that anymore. It's a remarkable capability, and it's something that, in my opinion, is getting lost in the conversation. Like when we talk about big pipe or things like that being a solution where the server is still sending the application to the front end interface, you cannot do this. And so it's important that whatever solutions we come up with, you don't lose this. And JSON-powered forms and JSON-powered components enable this type of deployments. So I know a lot of you guys are seeing all of these benefits, and it's, in my opinion, in fact, from taking a year, a year and a half of actually going down the road of building applications like this, to me it's obvious we should be building apps like this. This is the future. And hopefully it seems obvious to you guys as well. And I think the whole Drupal community has accepted that this is the future of Drupal. There's just a couple of things that make it hard. In fact, there's the big massive problem with Drupal is that it just was not built to work like this. And if you really kind of stare at it and say, what is really the problem and why was Drupal not built to work like this, you run into one, in my opinion, one single massive issue, which is that Drupal is handcuffed to these PHP renderings where it, and it's hard to break it from that, where the entire foundation of Drupal was built on this concept that in order to get markup rendered, the PHP has to be responsible for rendering it in a PHP array. In my opinion, that is a handcuff. And really if we stare at that one single problem and solve it and break it, we have the ability to use Drupal to its full powerful capabilities while at the same time enabling front end applications to consume these new modern technologies to build amazing applications. So just to give you an example, and I know a lot of you guys are gonna, this is gonna strike home for you. In fact, this really puts us into the context of this discussion because what we're really here to talk about are JSON powered forms. And if you guys know, as most of you know, the Drupal has its constructs in PHP, which is the form API. Everyone is very familiar with this. In fact, this was revolutionary whenever this came out. And really all you're doing is you're taking a form definition and you're breaking it up into a PHP array, which is defining the schema of that form within a PHP. You guys already know this. What I do want to mention is that while the form API in my opinion serves as a great example and actually a really good place to focus to start off with, there are a number of other pieces in the Drupal CMS where this happens. And so we can almost take the form API as a pattern to apply this to other renderings within Drupal. And so what really happens out of this, and if you actually think about it, a lot of you are looking at these renderings and you're saying, you know, how did we get here? How did Drupal get to a point where this is okay, where this is the accepted solution? And in fact, I kind of have to take you back to the beginnings of the web, where web forms really came out of the very origins of the web and actually Drupal came from that. And this will kind of take you back to web forms, you know, 1.0, where you would have this website and it would quite literally request a single file on the server and that single file was an HTML file. And if you wanted a form, that form in HTML would be on that file. So out of that actually came this PHP, you know, PHP community said, hey, listen, we can actually script that. You know, we don't have to be recreating the wheel for every single one of these pages and then when a request comes in, we can dynamically create these templates and send it up to the client. And then Drupal came out of the PHP movement, created the Form API, which was amazing, allowed us to essentially take that one step further where we could create these very well structured PHP arrays to essentially generate the forms that you have on the front end. The point that I'm trying to make is through all of this and even today, the server is sending the form to the client in all of those cases. And that, in my opinion, is what we have to break. And for a long time, life was good. If you guys remember, I mean, life has been good. Drupal had a massive boom, life was amazing. And for a long time, this PHP rendering was doing very well and then, as all of you guys know, this happened. Apple introduced a revolutionary device that really kind of made us stare at how we're implementing these websites and we had to rethink it a little bit and rejigger it. In fact, out of this came, all of you guys are gonna know this, the mobile first movement, which where you said, okay, now I need to make my forms or my website look good on a mobile device. So I'm going to still have the server send me the interface, but I'm gonna rejigger it so it looks good on a mobile device. And Drupal was great at this. You would send a request to Drupal. It would happily use the form API to happily use the form API to render the form and then it would send the form up to the client and the client would render it and it'd look beautiful on a mobile device. And guess what, life was good again. So life has been good even with mobile first. Then this happened. And so what has ended up happening is that now the server can no longer be responsible for a single type of interface. It now has to deal with all types of devices. And these devices display how they want to display. They are responsible for displaying the content in the way that they want to display it. And now at this point, this is really what's brought on the headless Drupal movement where Drupal has to figure out, how do I render this form and all of these devices that are requesting the form from me? And so headless Drupal is basically saying, you know what, the rendering should happen on the client. The client knows how to render itself. It should be responsible for that. And that's the right approach but now we have this problem because we're still building forms using a PHP array that can no longer serve the AngularJS and the ReactJS communities. And so what's happened out of that is a lot of developers, as of right now, there's kind of this vibe going on where developers are kind of like, you know what, they're throwing their hands up in the air and saying I don't really know how to solve this because Drupal has really anchored itself on this PHP renderings concept. And in order for us to get these front end applications we have to do API first development. We have to build APIs. We've been doing that, it's great. But even today we are still anchored to these PHP rendering arrays. And from our experience building a platform founded on JSON powered forms, it's very clear to us that the solution is actually far simpler than a lot of people realize. And we can do it piecewise. We don't have to throw the baby out with the bathwater. We can take little components out of Drupal and take them in piecemeal our way to a big solution. And in fact, we can not only get the best of the AngularJS abilities, but we can also get the best out of our CMS. Drupal is an amazing tool. We should not let go of that. Drupal's amazing and it serves a purpose. And so I really believe that we can actually get the best of both worlds. And I actually did a Google search for the best of both worlds. And this is the image that came up and I was like, I got to go with that, right? You know, Hannah Montana just kind of put you in a good mood. So anyway, so with that said, this really kind of gets us into this new way of thinking that we can take these old PHP constructs, rejigger them a little bit and we don't have to throw the baby out with the bathwater and by doing so we introduce this new capability called JSON powered forms which is the next generation of web forms. And I'm gonna hand it over to Randall at this point. Thanks Randall. Thanks Travis. So we're gonna talk a little bit about JSON powered forms and we're gonna look back just a little bit. If we look at kind of what's been happening in the last few years, Travis has touched on it a little bit. You can't probably read a lot of this but this is kind of the Google trends of things like Angular and mean and REST APIs. The last couple of years we've seen like just this tremendous takeoff of that. In fact, Dries even touched on this in his keynote yesterday and he kind of just stuck them down in there and he said they're building bespoke solutions with Angular and I think today he's very correct in that. I mean, if you look at what it takes to really do this, if you do it on Drupal with the headless Drupal you gotta install Drupal, set up all your entities, set up either RESTful or RESTWS or services or something to get the data out of it. In Drupal 8 you automatically can get an API and then you have to custom build the entire client side application or iOS application or whatever. So they're very hard to do. There's a lot of work and they're very bespoke. What really struck me in the talk and I wanna challenge him a little bit on as he says they have moved up but will always be for bespoke solutions and I think that always is dead wrong. How many of you can think back to life before Drupal and what it did for us? Anybody in here program in PHP before Drupal? It was a lot of work. It was bespoke solutions, right? The first thing you had to do is you went and you created a bunch of database tables in the database and then you created forms inside of PHP and you rendered those forms and presented them to the client. Client would fill it out and submit it back to the PHP and then you had the logic in there to do all the validation and if the validation failed then you gotta rebuild that form and put those old values back in there without clobbering the default values, send it back to the client to fix it all and they would submit it and then you got that data and it's all good and then you gotta figure out how to go store it in the database, right? It was a lot of work and everything was bespoke. Some might've even said then that it will always be bespoke. Along came Drupal and made it so we didn't have to think about all the nitty gritty details. Instead we could build our entities at the time it was node. Now it's entities, right? You could build an entity and you knew your database tables would be built for you. The validation would be handled for you. All of the complexities would be handled for you. You just have to describe what it is you want in your application, your Drupal site. So we are currently living in the world of client side front end applications where they are bespoke. What Travis and I are working on with Form.io and JSON Powered Forms is making it so it's no longer bespoke and works in a way that you just describe what you want and everything behind it is taken care of. So we're trying to get us to that next level. So how do JSON Powered Forms work? How do we do that? Well the first thing we do is we have a form builder. It's a, on our site is a drag and drop form builder but at the end of the day you're building forms and those forms actually live as JSON schemas. And kind of like that PHP array it's a schema that defines what the form is. It have like a title where the form submits to as well as all of the fields that are contained on that form. Now we can take that schema and do a couple of things with it. One thing is we can actually render it in the client side. That could be the browser in Angular, could be in React, we can render that form. Could be in iOS or anywhere else. You've got the schema of the form sitting wherever you're trying to render it. Instead of getting handed HTML you get handed the schema and can figure out what you want to do with it. But here's the really cool thing. At the same time we can build a REST API that corresponds with that form. We don't have to build it custom every time. We already have a definition of what we're looking for, what the form's gonna provide. Let's build the REST API behind it as well as the database behind that. So, and then that schema, so we now have a REST API and a form schema that the front end's gonna consume. We can actually serve up that same JSON schema as part of that REST API. So the front end application can just say, tell me what this form should look like and tell me where to submit the data and they can get all of that information, render the form and send the data where it needs to go to. So that JavaScript library can just do all of this and it doesn't even have to be JavaScript. It's JSON, right? We can do this anywhere. So I'm gonna give you a quick demo of kinda how our technology works around this. So this is a code pen of our form builder building a schema. So you can see right now we already have a form in the form builder over here on the left and a series of fields that we can drag and drop onto there. So let's say I wanna drag a company field on here and I'm just gonna label it company. And now if we look over here, this is the schema that defines that form is being defined into. And if we can see there's the last name and you may not be able to see this real well, but here's company. It just added into that schema dynamically. Now, if you notice there's no placeholder in that field yet. So I'm gonna go over here and configure it and say, enter a company. And now when I save it, if you look over here again over there in the JSON, there's enter a company that's been added to that JSON object dynamically in real time. So now we have that JSON that's the definition of the form and we can render that. So if we scroll down the page a little and it's not scrolling, I'll do it manually. As we go down the page, if you can see up there it says, we have our FOMEO directive in Angular and we pass it into it the form definition and then it will render out that form based on that definition. And so you can see that company field is now added to it. Now, inside of Drupal with our Drupal module, it can create an entity with those same fields on it and create a REST API using the RESTful module that can then send that data into and then it lives in it. Now by default, we are a company, software as a service, no JS, express backend. So if you don't need it in Drupal, you can send it to our service as well. And that API is like I said, no JS, MongoDB. We have lots of connectors to third party services as well. So as you're building out those forms, those REST APIs automatically will build out in our service but you can also create entities for them in Drupal as well. So that's kind of how this whole concept plays out. So let's talk a little bit about the benefits of JSON-powered forms and what that looks like. So one of the great things about JSON is it is ubiquitous. Pretty much everything out there nowadays knows how to talk JSON. There was a time when it was kind of like XML, PHP arrays, only PHP really knows how to talk them but everything talks JSON. So we're able to use this across pretty much all the devices, watches, phones, you name it, smart TVs. And this allows us to deploy our forms anywhere. This could be in a website. You can drop that into a website. You could drop it into a tablet application, into your phone. And if we think back to again bespoke applications and how much work that is, imagine if you've got a form inside of an application that somebody wants to make a modification to. That never happens in client services, does it? Nobody ever makes modifications in the middle of stuff. So they wanna add a new field or change a field. What do you have to do in a bespoke one? You have to go in there, go talk to the database people or add it in the database and then change the REST API, which might be in Drupal, might be in Rails, might be in who knows what that's written in, right? And then you have to go into each of the front ends, maybe computer, tablet, phone applications, wherever all of these forms are embedded. Each one of them, you've gotta go add that field and make sure everything all syncs up correctly. If everything is JSON powered, you literally just drag the field over there, save it when the schema is updated, your REST APIs update, your front end forms all update because they're all looking at the same schema and everything across the board just changes automatically, everything updates. So this does away with a lot of those problems of having a bespoke application that takes a lot of work to build and update. Another really cool benefit of using JSON powered forms and this separated architecture that Travis talked a lot about is you can actually have offline form rendering and data collection. You can't do this with server based applications. What that means is with browsers nowadays, they have application caching and databases built within them that we can utilize when you have these separated architectures. You can actually cache a web app into the browser so if they have no internet and they go to the URL, it will still come up and then as they fill out things and hit submit, it will cache them into a database in the browser, wait for an internet connection when it's there, we'll send that data up to the server. We actually have clients that are using this today and how it worked, like one of them, they sign medical waiver forms because they do scuba diving and snorkeling in the middle of the Great Barrier Reefs and stuff. So they are on a boat in the middle of the ocean. There is no internet and they need people to fill out these forms and hit submit and save those data and then when they get back to land and they can turn it back on, they will sync all the data back up to the server. We're able to do this with JSON powered forms. Another, a couple of other examples are customers that have service workers or clients that are going on site. Sometimes it'll be like drilling locations or remote places in the middle of fields. Again, no internet, they need to enter a work order or a sales quote for a large vessel or something. They can fill out that information right in the field, hit save, it gets stored until they get back to a place with internet and then sends it up. This is a pretty cool thing. Again, by doing everything based on schemas, we're able to do other things like those REST APIs behind it. When we were doing our Drupal module, it was pretty easy to just say, oh, just create an entity based on this schema and just build it out. So these REST APIs then are able to update automatically the back ends and the front ends all at the same time based on these schemas. So our Drupal module is at Drupal.org slash project slash formio. It's gonna be released probably around the end of the month. We are looking for beta testers, so if you're interested, come talk to us. Right now, this one's gonna be Drupal 7. Once that's done, we'll start working on the Drupal 8 module, which probably will be easier because we don't have to do all the REST API stuff. So I'm excited about doing that. So let's take a quick look at a demo of what this all looks like in our platform. So here, this is on our portal, so we're gonna create a form, or a project in formio, and that will allow us then to go create a form. So we're gonna create a form using our drag and drop form builder, so a new form. What's cool about this, you title it, and then we have a whole bunch of different form components that we can use to build these forms. So we also have layout components. So I'm gonna drop a columns on there, and that will give us two columns. Then I can drag over a first name field and there's lots of different validations and other settings you can do. Last name field, you can do input masks, placeholders. We also have some other, more special fields, like we have a phone number field that will automatically force people to enter phone numbers. We also have a really cool address field that does a Google API lookup, and will validate the address and include additional location information like the GUIP coordinates and all that kind of stuff that gets saved back to the database automatically immediately. So there I add another text field in there. So there, we've created our form. We can preview it really quick, put some numbers in, see how the input masks all work, the address, I'm gonna look up an address here, and there's one World Trade Center. And so now that that's selected, it's actually storing all of the information about that location in the backend, and we only see the little bit on the front end. Now, let's go back over to Drupal and see how we can integrate this into Drupal. So if you've got the project set up, you need an API key in your project URL, it will automatically populate the list of forms down here. And when I drop it down, we're gonna embed a much larger, more complex form in here. And you can see there's a ton of stuff. I'm gonna go back up and we can more slowly see. You got a ton of information. Try building this with the web form. Good luck. We also have conditional visibility, so you can say only show this, that's this value, and so stuff can hide and show. You can save it to Drupal or save it to our service either way. If you choose to save it to Drupal, it will create a Drupal entity and a REST API, and when you submit the form, it will save it back to that entity. So here I'm creating a panel page. It is panelized or blocks either way. You can display it either in a panel or in a block. It's up to you. So here I'm gonna add the Formio form. It's gonna pick the demo one. You can select another one as well and save it. And then we're gonna preview it inside of Drupal to see what that looks like. And this is just a vanilla Drupal install. I did it like five minutes before I recorded this demo. And here you go. There's your form, all in Drupal, ready to go. And then when it submits, if you choose you can save it into an entity in Drupal, all that data. That's kind of how those JSON forms are gonna look. So where do we go from here? We've got a really great solution. We operate outside of Drupal. We have a really great Drupal module coming that's gonna allow you to use these things in Drupal. But this is something that Drupal could do more natively. And if that happened would really enable people to build front end based applications, client side, single page applications more easily. So what does that mean? Well, here's what we currently have, right? Everybody's probably familiar with REST APIs. This is all the full crud. You've got the index, create, read, update and delete, right? Your standard crud operations. And that's typically what REST APIs do. Kind of the innovation that we're talking about is that we add one more endpoint. And that is something like form. Could be something else, but we typically call it form. And that, when you get it, will return you the definition of the form that's needed to interact with this API. We could base that on the entity definition, right? You could just grab the entity definition and say what should a front end form look like that can interact with this API? That's all we need. And once that happens then you have a rendering library in Angular, in React, in Ember and whatever else you wanna have it in. And it can take that JSON form and render it and submit it to that exact same old APIs. So that's kind of what we're proposing here. And we really think, so here's an example of, if you were to translate the entity definitions into a JSON schema. So we really think that something like this for Drupal could really pull us into the whole Web 3.0 single page applications next generation without having to make everything bespoke. We could make a lot of, we could connect everything from A to Z without all of that extra work. So thank you very much for your attention. That's what we've got. So we did leave plenty of time for questions. So we really wanna get y'all's, first of all, get your input as well as answer any questions that people may have. So I'm gonna go ahead and answer that. You don't have to follow your presentation. Do the what? The address. The address for the presentation. Oh, the address for the presentation? Yeah, sure, absolutely. So let's ask questions, sure. I saw a signature field up here. Oh, there's a microphone up there. Sorry, go ahead. Yeah, go ahead. Yeah, go ahead. I saw a signature field up there. How are you guys capturing that and storing that? So the signature component is actually using Canvas so that you can actually sign with your finger and it uses Canvas. And that actually stores the base 64 binary of the signature. And so we're not actually saving it as an image. We're just saving the binary, base 64 binary as a blob, really. And so then whenever we render it in an image, you can pass that directly to the image tag and it happily renders it and we don't have to store the actual image. Yep, go ahead. So currently when I make a form in Drupal, I can pull all sorts of information out of my database, user ID, whatever other information I have and use that to customize the form. So it looks like what your module does is pretty much one way. I build the form on form.io and then I import it into Drupal. So it seems like I'm losing a lot of flexibility. So great question. To be able to pull information from your existing, let's say entity collections, we have a number of components that allow you to hook them up to custom rest endpoints. So for example, the select dropdown. Let's say you wanna be able to select an existing entity within your Drupal solution. Our select component actually has the ability where you could hook it up to its own REST API, which would essentially be the component endpoints so that you actually can get some of the data into the form for people to select certain entities and the like. So you can do that with certain components. So to continue on to that, a good example that might be like customizing what options are in a select dropdown, right? And I'm curious on a use case, but so let's just talk through that. Typically it's really important to start wrapping your mind around when you're doing front end applications that a lot of that logic takes place in the front end application, not when you're building the form and rendering it from the server. So in that instance, we still build the form and we send it, but like Travis is saying, you have a REST API in that select list that says go get the options for this select list. And part of that is the user token and then you can customize in the REST API for that select list and say, oh this user only has access to these five items, only pass them back. So the logic is actually happening in the front end and in the REST API. You don't do that when you're building the form. Hi, two questions. Hopefully they'll be fairly quick. First off, big thing is, I can see how this would work well for like a contact test form. But what about a form that collects more sense of information? So like how do you do encryption? How do you help protect data as it travels from the form through various systems? So that's one major benefit of having our forms point directly to Drupal and the entities that were created from Drupal. So essentially you're sending the same requests that you would be today with a server rendered form. I mean the server rendered form is going to the client, the client's filling it out and then they're sending that request back to Drupal. That still applies with this system. So any SSL mechanisms that you have to protect the transport of that data over the wire is still in place. You're not sending that data to our service and then we're kicking it to Drupal. That's not happening. Yeah, a quick follow up question to that. Yep, sure. So say we use your Drupal module, have a form module, but say we don't want to go to Drupal, we want to plant to another system, is that possible? Absolutely, yeah. So that's another major benefit of using JSON powered forms is you can choose to point that form to Drupal. You could also choose to point it to Form.io and have Form.io execute its actions, or you could choose to point the REST API to some other service that you may have. It's really up to you on where you want to point that data. Okay, final question. How easy would it be to configure a form to pull hidden value? So say you have an Analyze system that cookies somebody with a specific ID. Yep. I want to go ahead and get that value passed into my CRM. Yep. How can you pull hidden values through your forms? Yeah, we actually do that all the time, and that's another major benefit of a JSON powered form. With that, you actually get full JavaScript control over the form itself, and you can inject certain values based on just setting a certain data model within JavaScript. So in your particular example, you would have a hidden field, which is the Google Analytics or whatever you need for Google Analytics as a hidden field in the form. And then within JavaScript, you would just simply assign the data model in the client to that value, and it'll automatically populate that hidden field within your form. Hi, first of all. Hello. First of all, thank you for the presentation. I thought it was excellent. Thank you. And my question is, in regards to AJAX forms or conditional forms, do you support that? Yeah, yeah, and that's actually configured within the JSON schema. So whenever you're configuring the schema, you actually on a per field basis get to decide this field should be showing under these certain conditions. And that's actually part of the schema definition. And as it turns out, our renderer, the renderer JavaScript library that takes that JSON schema and renders the form in the front end, honors those conditions that are within the JSON array. So yeah, absolutely. Is this on? Yep. Thank you. Your demonstration pretty much showed an English related situation. What about sites that need to support multilingual translations? Great question. Actually, the renderer is capable of translations. We're actually standing on the shoulders of giants there. There's a very common AngularJS translate library. And that actually uses Angular filterings. And so the way that works is you have to just provide one additional JSON object to the renderer, which is the translations. And so based on whenever the client is rendering the form, it can also say, okay, what language does this form need to be in? And that additional JSON schema is used to configure the filtering mechanism within the renderer so that it actually dynamically translates based on their language. And a great example of that is the waiver forms for the scuba diving. As you can imagine on the Great Barrier Reefs in Australia, not everybody there speaks English. And so for that application, we actually translated into, I think, six different languages. And all that was required is we took all the strings in the form, had the different translators, give us the different values, pass those JSON objects into the form, and then the user can pick which language they wanted and immediately translates the entire form into all those different languages. Yep, next question. Yep. For a bootstrap includes like a form system, is that something that would work with form.io? And I was just looking at that recently, and it's, you know, somebody like me with no aesthetic taste can make pretty decent looking forms with it basically. Yeah, and that's actually a very common use case. And I hope I got your question correct here, but a very common use case is to offload the form building capabilities to other people. And it's actually, once the developer gets the mechanism in place, we actually kind of showed you the workflow of form building. Imagine handing your entire marketing team and say, you live in form.io to control your world. Build whatever forms you want. And all the developer has to do to get that form into Drupal is create a preset, select that form and add it to a block. And you suddenly have that workflow that you described where other people control the creation of forms. If I understood your question a little bit, all of our rendering is actually bootstrap compatible. We all use templating from bootstrap and all of the themes from bootstrap. So what you saw in there actually was a bootstrap theme for the form. I was wondering if you guys have like standard clients, like that you have a renderer that, I mean, do we have to write the client in AngularJS for every platform or do you have a standard client that we could configure that would interact with form.io so that we could run it on the browser, run it on iOS or run it on Android or something like that? So right now we have two renderers available. One is for AngularJS and the other one is for React. And the way we get that into Drupal is we actually add those dependencies to the page. So those two renderers are what we support right now. However, we've actually created them in a way so that we've essentially established a pattern so that if you need a rendering capability and let's say Android native, you could take the pattern that was established with these other renderers which are all open source. I wanna also throw that out. All of the renderers, builders, MIT licensed open source. So you can take those patterns and actually use that to construct other renderers but out of the box you have AngularJS and ReactJS which should cover you on most devices. And in addition, if you do the web view components inside of Apache Cordova or Electron, you can actually compile desktop, iOS, Android, Windows Phone, all of those different devices as well. So if you're not going native, you actually can still use those Angular and React components as well. Yep. So a question about say business rules that you would like to put into the front end like a date, can't be after today, a date of birth for scuba diving, right? You have to be 16. So those kind of validations, where would you put those? How would you manage the library for that? So the validations are actually also described within the schema itself. So when you're building the form, you're actually, there's actually a section within Form.io where there's a validations tab where you can say these validations should apply. And the module, what it actually can do is whenever that request makes itself into Drupal, it can perform a simple validation request to Form.io. Right now, what it's doing, it's actually using the standard entity validation criterias, but eventually in the future versions of the module, we can also make it so you can configure it to also do a quick ping over to Form.io to say is this form a submission valid? So the follow up from that, then following the example from the Great Baby Reef, I have no signal. So in other words, you know the old saying Gaga, I want to validate the data that I put in. That's a great question. So our forms, not only do they validate on the front end, but they also validate on the back end. So to answer your question, we actually have two validations in place. One is front end validation, which means as they're typing it out, it's actually validating the request. So you put all of those rules in the schema and the renderer is actually compatible to say, is this valid as you're typing it out on the front end? And then we actually, with the offline mode and talking about offline mode, because things get kind of complex there, because what if they type in something and then they connect to the internet and it tries to submit it and there's a validation error that happens. In fact, our system, the way it works is, whenever there's a validation error, it knows the form that the validation error occurs and the app sees the validation error, shows the form again and says, hey listen, we're trying to re-sync this and can't. Here's the validation error, fix it. When they fix it, it moves on to the next item in the queue. Does it go on entity reference? Not right now, it does not do entity reference. But to achieve references, now Form.io, if you were building and highly leveraging Form.io's API platform, Form.io's API platform absolutely does resource relationships and all of the like, but if you really want to anchor yourself to Drupal right now, that's not a capability, but it's open source so I see we could add it soon. It could? Okay, yeah, he knows more about the entity creation. Well, I mean if you have an API and you're feeding that into a select list. You're feeding it into a select list, you would select it and that would be part of the payload. The ID would be the value you selected so that would save into the form. Okay, let me put it this way. We haven't tested that. But it could work. We have, yeah, I think we have time for maybe like a few more questions, go ahead. Oh yeah, go ahead, I'm sorry about that. I didn't see that microphone. I just had one quick question. Do you have an easy way to pull URL parameters and feed them into the form or does that just need to be done in JavaScript? Well, JavaScript is the easy way to do that for our forms because it's all in JavaScript and so it's very easy to write the code to say, just grab some query strings and feed it into the form. So that happens very easily. I just thought maybe there was like a, there's no checkbox for that. Okay. All right, thanks. Yeah. So yeah, I was wondering if I had a bunch of existing Drupal entities. It can be done. We'd love to have a patch for that. I'll work on it. Thank you. All right, well, thank you guys so much for coming to the session. I really appreciate it.