 needs to develop a web application without any esoterical things are inside one jar. You just have to download one file and you're up and running. There is no dependency hell. You don't have to figure out how everything works together. And since it's a full stack, all the layers in there can benefit from cross-proliferation. And they can talk together. A lot of the configuration and defaults are there, done for you. And it means that the whole approach is very consistent. We have the same approach that applies at multiple points. You don't have to figure out how something is done for your persistence layer and how something is done for your view layer. It's a component-based framework. It's component-based at several points in the framework. So it provides, in general, a very standardized structure for the application. It means that anybody can really read it and get up to speed easily, understand what goes on. And it uses these components to manage the lifecycle of your entire application. Thanks to the components, you are able to use your business logic from each element that's been componentized and reuse them where you see fit. And so each layer in the framework has also been componentized. That's in the inner work and sort of framework, the database layer, the templating engine. All that has been componentized and you can use them independently. Now, one of the main points, it's not the most important point, but one of the main points is that you want to allow people to quickly develop a web application. So there is an accent on quick and there's an accent on develop. It's not drag and drop. We are really geared towards developers, not some users that don't really understand what goes on beneath, we're geared towards people that write code and quickly. So I'll talk about the integrated layers. We have a number of best practices that have been considered best practices along the years, like MVC and a lot of other things well understood patterns that are enforced at certain points, which means that once you know that they are there, you are guaranteed that these best practices have been followed and you know that your fellow developer has followed them too. So it's very easy to take code from someone else and get up and running with it. But quick is important, but another thing that's even more important is that you have to be able to maintain your application easily. You have to be able to take your code over a long period of time and not spend a lot of time on understanding it over and over again. It doesn't have to be difficult to refactor it. It doesn't have to be difficult to pass it on to another developer. Maintainability is extremely important. And that's why we make it easy for the developer to write codes and benefit from the approaches that we take. We allow every change to happen instantly. And the generalized approach of the framework, the best practices, allow you to be very maintainable on the long run. We also embrace the standards. Like, for example, HTTP has got a lot of limitations. Instead of trying to simulate something that's not actually possible with HTTP, we try to embrace it and give you as much functionality as possible without going against what it stands for. The same thing with SQL and with HTML. All these things, we embrace what's already there. So people that know it can apply their knowledge. People that learn it can use it afterwards on all the projects. And we are geared towards web applications. Now, this means that the web engine, in Rive, since it's a full stack framework, there are a lot of engines and different layers, the web engine is geared towards web application. This means also that we haven't abstracted things too far. We still talk about cookies. And we still talk about URLs. And we talk about those things that make up a web application. But all the other layers in Rive are actually not tied to the web tier. So that's the definition again. Now, a full stack, I said that in one of the first slides, contains everything that you would need to get up to speed and running with a web application and without doing anything really fancy. That's a big thing to say. Contains everything you need, if possible. It can't contain everything you need. But it contains a lot. And this is what's inside the framework. Those are the main parts. There is a lifecycle management that gets your application running and have all the participants in this application work together, figures out how it has to start up and how it has to communicate. It's got a database layer, a web layer. It handles templating for you. It handles metadata. Then on top of all that, there is content management. How do you work with that? And there are some other things that are not really integrated along the rest. But that should be present. That is, how do external interfaces work with your applications? And then a collection of general purpose utilities, common services. The lifecycle management has got several parts again. There is configuration. There is a schedule, something like CRON or any other Java project that also does scheduling. Then there are IOC factories, inversion of control factories that allow you to inject dependencies into your components, and it manages your lifecycle. The database has been split up also in a layered stack. First, we have wrappers around GDBC to make GDBC very comfortable to use. And we handle all those little tricky situations where you have to have a number of try-finally blocks. And then again try-finally inside that to make sure that everything is closed correctly. There's a bunch of templating methods that allow you to quickly perform operations that you do every day, like retrieve a bunch of beans over GDBC. Then on top of that, we've got object-oriented query builders that allow you to create SQL queries, specifically targeted for a certain database. And this targeting is done by Rive. So you use an object-oriented API to declare your SQL queries, and Rive will handle the syntax differences for you. Then we have callbacks, the ways how types are mapped in between the database and your actual Java types. And on top of that, a very easy to use persistent manager so that you can just say, this is my object, and I want to save it. I want to just say, save one line. I want to delete. I want to update one line. This is a persistent manager that floats on top of that. And the web tier has got two main parts, of course, the web engine that I talked already about, and one other very important part, everything that you write, all the components in your web application, can be tested outside of the servlet container. This means that you can quickly write unit tests, and it's very comfortable to write these during your development. You don't have to start up any engine. You just write it outside of the container, and all the logic applies. It will work exactly the same. And then there is the whole web engine that handles the flow and has something that's called continuations. I'm not going to talk about this today because I can talk about that for an hour on its own. And, of course, it's got components. Templating. Well, there is, of course, a template engine, which you will see is very different to what you use as template engines, and then form-building, error-marking, error message indication, all the standard stuff that you would expect to be there. We handle metadata for you through validation and something that's called constraints. I'm going to focus on that later in the presentation, too. It allows you to declare metadata outside of your actual domain models. Then the whole content management framework allows you to work with images, with rich text, to store them in the database, to stream them out, to transform them, to do all these things that you would like to do with a content repository. External interfaces, web services, it contains content syndication, so RSS feeds, atom feeds. All these can be easily created by using Rive. We've got an asynchronous mail queue for those applications. I think that most applications should be able to do this easily send out mail, but not directly hit the SMTP server, but have a queue somewhere that does this asynchronically, not tie up everything, and then a bunch of common services like authentication, resource abstraction, and utilities. So that's a full stack. I think you can do most functional, implement most functionalities of most web applications with that, if you don't want to do any PDF generation on the fly, or Excel files, or stuff like that. Of course, you can use any other existing Java library that's out there. Just put it in your class path and use it inside your code like with any other Java project. So these were the essentials. Has anybody got any questions about that already? OK. I'm going to quickly look at a very simple application. First, I'm going to talk a little bit about Rive Jumpstart. I said in the beginning that Rive is just one jar that contains everything that you need. But of course, you need to be able to work with files. You need to be able to edit your code. You need to be able to get your application running, to deploy it, to package it, and stuff like that. That's not handled inside a jar. All these things that normally are part of your projects are handled by Rive Jumpstart. So it's a source archive. You download a zip file that you unzip. It allows you to start up easily with new applications. It contains all the things that you need to just say, and run, and everything is running, to say, and war, and get your package. Everything is there. It's got support for the major IDE's. You just open your IDE. You go towards the project file. And boom, you're up and running. And this is a quick demo about how this happens. I downloaded the zip file and zip it. I launched an IDE. In this case, xDevelop. I'm going to open the project file. I just rebuild the sources, because there are a number of blueprint sources in there, as an example. And I started it up. And the application will start up. It contains an embedded JETI container. And I switch to my web browser. And I've got a running application. That's how difficult it is to get started. You just want to look around and see what's there. And I use it for every new application that I write for a customer. I take Rive Jumpstart, and I hop, unzip. I rename my directory. And I'm up and running. I change the default of the files that are already there. I rename some stuff. And you're up and running. That's it. OK, so I said that it contained everything you need. Of course, the question is then again, what is everything? This is directory structure. So it contains most of the things that you don't expect. It's got an AMP build file. It allows you to run tests. It's also got test blueprints. You'll see that. It's got an embedded JETI container that's there, ready to use, configured for you to work on your local host. A number of additional jobs that would be handy if you test your application, like, for example, run xpath queries on your XHTML and stuff like that. Then some sources, a source directory that's laid out for you. It's just an example. You can do whatever you like with it. It's just an example that works well for most people. Some Java tests, tests out of container tests. And a regular main directory of a Java web application, you'll see the web interface and you see for the rest a bunch of CSS files and stuff like that. So this directory structure of your sources is just a suggestion. This is something that worked well for us. It worked well to split up the different type of files that are composed that are inside the Rive project. But you can change it any way you like, because by default, Rive looks all the files up through the class path. This means that if they are inside a jar, or even if they're taken from somewhere remotely through a custom class loader, I don't know, Rive will find it. So if you want to have some extremely complicated structure, it's OK. You can just change it. And I said in the common services, I don't know if you remember, but in the common services, there was something that's called resource abstraction. Resource abstraction allows you even to, for example, store all your files in a database and Rive will load them from a database. You can abstract these. The loading and the finding and the writing part of resources is abstracted. So it's set up for development. You start it and you start coding. You change a file and you save. You reload in your browser and it has changed, something that's very comfortable to use. Of course, there are certain limitations in Java still, but that's being worse on. Certain limitations that don't allow certain changes to happen and you will have to restart this container. But once this is supported by the GDK and the GVM, Rive will just support them also. And now I'm going to talk about an overly simple example. This is really, really a very simple application. I think it's about time. A lot of this abstract talk about what's in there and people fall asleep. I would fall asleep, certainly, on a Sunday morning. So I'm just going to focus on small parts, the web engine, a little bit about templating. This is not the best, this is not the ideal way to do things, but I have to make choices. I can't explain everything at once, so I just extracted some functionalities instead of using, for example, our validation layer and stuff like that. I want it to be comprehensible to you and not woo. It will already be woo, I think. So I opted for taking an IOC-oriented approach. Who knows what IOC is? That's good. IOC is inversion of control. Basically, instead of from within your code going to fetch something somewhere and say, OK, I want this. I'm going to look for it. You have something else that pushes all your dependencies inside your business logic. So it inverses the control. The nice thing about it is that you're totally decoupled. You can take something, you put it elsewhere, and something else is injected into it. Instead of you looking up things and having to find sensible names to make them reusable and stuff like that. And a small remark, some things might seem a little bit long, but that is because it's an overly simple example. Just like Hello World in Java is an overly simple example. Java has not been created to write Hello World programs. For God's sake, if you want to write Hello World programs, write it in Ruby or in Perl. It will be very, very small. But I don't think that's something that's very important to look at at such a small scale. This is the application diagram. It's very simple. I'm going to ask for the name of somebody. If it has been filled in, it will just greet the person. If it has not been filled in, it will display a warning and an error, and ask for the name again, and so on. And these are some small screenshots, little form, error indication, and welcome. No, it's not Friday, but when I wrote the slides, it was Friday. OK. I talked about in the beginning when I said, what is Rive? That it's geared towards maintainability. And quick development, but maintainability is the key part. This means, we believe, that it's very important to declare everything that's state-related and everything that's flow-related in terms of your application, to declare that externally from your business logic, to have a centralized view of things where you can plug in all your components. And this is, for example, a site descriptor. This is where rifles start looking for things. So all your components are grouped together in a site. But a site on itself is a component also. So you can have whole applications that are just been identified by one ID, and you can reuse them anywhere. A site is a component also. Then I say, this is an element. That's with a certain implementation. It's got a specific ID, and you can optionally tie it to a neural. This is optional. If you want to have hidden elements or elements that sit in between certain parts of your flow, that's OK. I also declare that this element has got a certain property, because I want to display something in this application. I say that it needs a template, and this template will be injected from here into the actual implementation. And to handle forms, we have something that's called submissions. You submit data to it. It's not necessarily tied to a form, but usually it is. You submit data, a submission has a name, and it's got parameters that are named to. Now, of course, people will say, oh my god, if I've got a bean with 30 properties, do I really have to say 30 time parameter and all the property names? No, of course not. There are a lot of other things inside Drive. Like for you can just say bean, give the name of a bean, and it will do all this for you automatically. But we're in the overlay trivial example. And then an arrival. This is like your index.html in any static site. If you go to the slash of a directory, it goes automatically to index.html. Here, when it arrives at your site, it goes immediately to that element. So that's the arrival. So what does this site structure do? It allows you to declare a broad overview of how all the components relate to each other and how the flow and the state transfers from one area to the other. This has got a huge benefit if you work with a team on an application. Why? Because you don't have to start drawing this out for someone. People that want to understand, on a high level view, what your application does, just take the site structure, look at it, and they understand what the meaning is, what the data inputs are, what the properties are, and all these things. And besides that, Rives uses all the things that you declare there to give you a lot of advanced features. I'm not going to go into detail in this, but it does some very nifty stuff thanks to that. And some people are allergic to XML. Well, I can understand that. Sometimes it's a little bit convoluted to write, and it's not very comfortable. But that's no problem, because XML is just a facade for us. Everything is done through a Java API, and we put Groovy Builders on top of that, Genina Builders on top of that. You can do it even in plain Java, declare your site structure, or even automate it. And I will show that in the last part of the presentation by just providing it with one B, one class, it will generate a whole site for you, in one line. So what is the business logic of this component? This is the element. So an element extends either element or implements the element-to-wear interface. So either a project you like to take, you just can go either directions. Then I talked about the properties. You will recognize the template property. This is the template instance that will be injected into your component. And also, the name was a parameter in the submission. This will also be injected when the request arrives at your component, at your element. And by default, Rive executes the process element method. If there has to be only one method there, it would be that, it would be process element. This is what is executed if there's nothing else there. So in this case, if you arrive at this component, your first thing that has to happen is print out the template. I want to have some HTML displayed, and I want this form to appear, and stuff like that. Now after that, the submission will happen. The form will be sent. And this form had a certain name. The name was MyData. And Rive will look up methods that are called do, and then the name of the submission, and execute that automatically. Now this is not mandatory. If you don't like this, you can just do if then else inside your process elements methods and handle this manually. But this is a nice way to split things up. So at the end of the submission, of the form submission, it will print out the template again. If the name hasn't been filled in, so here normally, I would use our validation framework. But I didn't, to keep the application simple. If the name was not filled in, if it was empty, I'm going to display an error, say this is wrong, has to be filled in. And if it has been filled in, I'm going to take the day, I format it, and I display it in the template. That's it. That's the implementation of what I discussed in the little diagram. It's very intuitive. It does exactly what I drew out in the process diagram. And you notice that I didn't have to worry about the flow at all. I just declared some properties, and everything will be injected into it. I don't have to worry, oh, I'm going to obtain this parameter, has it been present, has it not been present, how does it has to pass on, has this form been submitted? No. By the code structure, everything is handled for you. And since you've decorated it separately in your site structure, Rive knows how to do this. And there are very little artifacts in this code. You work with the template, and for the rest, that's it. Also, people don't necessarily want to write this in Java. People that quickly want to have something running could do this in any of the GVM scripting languages. You could do this in Groovy, in Janine, or even in JavaScript or Tickle. And as you noticed, there has been no relation at all to the outside world from within the element. It's totally decoupled. I can reuse it anywhere. I can put it elsewhere in another site structure, with another ID, with another URL, and tie it to something else. And this is a template. And this is how most people look like after they've seen it. I know. But don't worry. It's OK. Most people get used to it. And once you look at it, it's OK. Once you understand the concepts, it's actually really an understanding of the concepts of the templating engine. It will go very quickly. You're not used to seeing these things. But they're always the same. And I will explain why they are like they are. The templates are completely logicless. It's not like GSP. Have people here worked with GSP or PHP? Don't you think it's a bit stupid in PHP? PHP is a templating. Initially, it was a templating language. That there are no templating languages for PHP, that you've got smarty for PHP, or any kind of other templating language. That again gets another language. So you've got all these languages just to do templating. If you, for example, create a PowerPoint presentation, what do you do? You create a template. And then you use that template, and you reuse all components in your PowerPoint template to put things into place. You don't want to write all the logic of how your template is done inside the PowerPoint template. No, you're going to do this in your actual presentation. And this is how Rive's template engine works. So you mark up something existing, a layout that you get from a designer. You mark up content placeholders, so areas where content and data has to be displayed. And other areas, you mark them up as reusable blocks that you will use to build up your final design. This is a little schematic compared with GSP. So in GSP, you typically have your view logic that receives some data. It sets it apart elsewhere. And then it says, OK, I'm going to execute the GSP. This GSP retrieves the data that has been set apart. Does all the layout logic there, and a lot of people even write database code in GSP, or any kind of horrible thing that you could do? And then the logic of the view resumes, and the content is given by the GSP at the end. So you could write anything in this template. This template can become a language on its own. It's a maintainability nightmare. With Rive's template engine, it's completely different. You see that there are no logic arrows going from one side to the other. The only thing that transfers is data. So you've got your view, you've got an instance of the templates, you provide it with values, you provide it with the name that has been submitted, you provide it with the date of today, and then you take a block of reusable content and set it also at a certain location. So you build it up just like building blocks. It's like Lego. You build it up, you build up your template by everything that's been marked up inside of it. And then you fetch the resulting content. It's not given to you, you fetch it. So let's go over this horrible piece of code step by step. You see that it's a regular HTML template, a regular HTML file. This can be done by anybody, any designer, in any editor. And the head is almost completely regular too. There's just one little thing. It's the yellow thing. That's a tag, a Rive tag. There are only four tags in Rive. This is the value tag, a V. This is a value placeholder. This is an area where values have to be displayed. And we have a number of default names to make your life easier. For example, the web applications root URL will be automatically filled in there. This makes it easy for you to create applications that can be positioned anywhere. They could be located elsewhere in the directory hierarchy. It could be located on another server, anything you like. Got another value placeholder there. And that is where I want my contents to be. This is the location where everything should display. And if you remember from the example application, if someone provided his name, the application will welcome the user. And I declare a welcome block, B is a block tag. This block is reusable content that I want to place somewhere else. In this case, when someone has submitted his name, I want to use this welcome block and set it at the content value tag. And again, there is a standard name to automatically display a parameter that has been sent through the submission, so the name will automatically be filled in there. The third tag, and this is actually most of the tags that you will use, is the block value tag. It's the same as block tag. It marks up reusable content. But if a value is present with the same name, it will use this content and set it in that value placeholder by default. This is just a default value. You can still set anything else in that placeholder. But it allows your template, for example, to be split up into modular parts and still have a default content. And in this case, a default content is the form, the form that will be submitted by the user. And this form, again, has got some value placeholders to handle the URL for you. Since you declared the URL in the site structure, remember that you put the element there. It gave it an ID, an implementation, and an URL. Rive is able to fill this in for you automatically there. So if your component structure changes, this will change too. And then there is a second tag there. These two go together to handle the state for you, to handle the fact it could be very complex. It could be a submission that has to remember a lot of data that's been transferred in between components. It will set it there automatically for you. So these are just standard names according to the name of your submission. And for the rest, I've got a regular HTML, a form with an input, and an input that will show the name after it's been submitted. And this little setup could look weird, but actually it's very simple. It's a div, a regular HTML div, with a CSS class. And I want to change this class if it never happened. I want to display the red rectangle. I don't know if you remember in the little screenshots, it was a little red rectangle when the name has not been filled in. I want to display the error, CSS class, at that location when an error has occurred. Remember that piece of code? This is where that happens. So the name class value placeholder is a location where I can set the class of the name input field. And I will use, in this case, the class error block of reusable content. Set block in the template, in the value placeholder name class, and we'll set the block that's called class error. OK? Now, the benefit of this, so I set the value day and display, instead of the form, I want to display as content this welcome message at the bottom. So there are only four tags, I said. You saw three of them. So you're already almost home free. There's nothing more to learn. There is the value tag, the block tag, the block value tag, and then there is a fourth tag that's called the include tag if you want to build template hierarchies. In the template language, also, a lot of people ask me, why didn't you just do this in DOM? Why didn't you just allow people to provide an attribute to an XHTML tag and use the DOM structure and manipulate it like that? For the very simple reason that templating is not limited to XHTML people, I want to template my email messages. I don't know, generate Java code on the fly through templating, generate SQL on the fly by using SQL templating, Rive does database abstraction. All these things are valid uses for templating, for having text that's been generified in a certain way and that you want to reuse and adapt to get your final result. And in this case, that's why the tags were so long because we've got three other tags in taxes. But in this case, I showed you a visible markup. We used HTML comments, if you remember well. And these comments will become invisible so they can just be added to an existing design. And to the layouter, the guy who really actually does a design for you, they have no impact at all. And you can very easily work together. I said that they are hierarchical because they can include themselves. But also, if you remember well from the little schema, something very important is that they are bi-directional. Instead of activating a GSP template that does everything and just goes back, you really communicate from within your Java code with your templates to build up your final result. And finally, something very important, there is no logic at all. This means that templates get the same benefit as themes because you can just switch out templates, take components that have got business logic in them, put other templates inside, and you don't have to worry at all if you correctly copied the business logic, if things fall into place. OK. Any questions about this? Yes? It is. But then again, it's very useful for a simple for each statement. But once, who does simple for each statement? I've got a lot of my for each statements mostly do conditional stuff inside there too. So there are always corner cases. There are always situations. So I don't know if the question was understood by everybody. So the question was for each statement that could be handy inside the templates. Yes, but then you've got logic inside of them. And again, you have to worry, has someone actually written this for each statement or not? In this case, it's never the case. So you don't have to analyze these templates to see if any of the business logic bled into it. OK. Another question? So this, I showed you a very simple example, an overly trivial example that just touches on some of the small parts of the framework. And maybe some areas were a little convoluted. Now I'm going to go to the totally opposite end of the spectrum, going to talk about metaprogramming, how to do things extremely quickly. People should wonder normally what is metaprogramming. It's a term that exists for quite a long time, but it's getting quite in vogue again recently, which is a good thing. So it's a process of writing programs that write or manipulate other programs. So you write something externally, and this will manipulate something else. That's metaprogramming. You do it externally in a decoupled fashion. And usually to do this, you've got a domain-specific API, something that's very specific to the metadata that you want to attach. It allows you to approach things in a very high level fashion, but still, since you do it externally, you can still go in, get dirty, and go into the lower parts of the integrated parts and access all the underlying functionalities. So this allows you to concentrate on your business logic, to concentrate on the things that you really want to express and don't get tied up with things, boil up late code with trivialities that would take up a lot of time and you do over and over and over again. And Rive does metaprogramming with something that we call constraints. What are constraints? There are rich dynamic metadata API for Java being instances and their properties. So that's, again, a mouthful. It's rich because it handles images, XHTML for you. It does transformation of all these things. You can plug in anything you like. It's rich. It's not just texts and integers and stuff like that. It's dynamic. This means that you don't write it as annotations or XML inside your Java codes as dockets, so I don't know anything like that. It's dynamic. You can change it at runtime. There is an API present for it. And it works with instances of your Java beans, not with the classes, but the instances. So you can make exceptions for particular instances. Your metadata might change in certain situations. And it bases itself on the properties of these beans, which is quite logical when you work with beans. So this is a regular Java bean instance. I've got a news item. And it's got an ID to identify it instead of using, if you want to identify it textually, it's got an ID. It's got a title, which is just a regular string. It's got text, which has to be XHTML because I want to write a nice news item. I want to be able to format it. And I have an image that can be attached to it that will be displayed. I add some constraints because these properties, these on itself, they say nothing. They just say that they are there. And I add some constraints to give them additional meaning to add metadata to the original structure. So I say that the ID is actually an identifier. It identifies the news item. And that the title has got a maximum length, that it's mandatory, that the text itself is mandatory also. It's got a certain mime type. And for the image, it's the same thing. It's a ping mime type with the limited width. And it will automatically rescale, things like that. And the entire framework will use this metadata to adapt to the new information that's available to it. So I can create my database structure from this information by using the maximum length of the title. I can put, actually, say, VARCAR, open brackets, say the maximum length, and close it again. I can reuse this. So the database creation layer uses this, too. The same thing for the properties, primary keys, everything is handled through that, if you want to. You can do it also with the nitty-gritty details yourself. But the metadata API constraints allow you to do this in a consistent fashion. Form generation. I can generate my forms from this information. I can have instant input fields with maximum length, and stuff like that. Make them mandatory. Can validate my data according to these constraints. And have meaningful validation errors and markings. Can display the data, format it. I could attach to, for example, date certain formators to display dates in a certain fashion. I can also put this in my constraints. I can store the data based on this information. For example, the text and the image are not regular data. They are rich data. And I want to store this in the content management framework that's integrated in RIFE. That will be handled for you. And content storage. So they're unobtrusive. They're totally decoupled. You can add them to anything already existing, even if you like to. But if you quickly write some code, you write a quick application, you could just extend the metadata class, use that as your domain model, and then add some properties and do it right there without having two classes. It's instance and runtime based. Now what do they look like? This was the news item I talked about. This is a regular Java bean. Everybody should recognize this. Nothing spectacular about that. So regular Java bean. And these are the constraints. This is another class. This is the news item metadata class. And I extend the metadata base, abstract base class. You could also implement a lot of other interfaces if you prefer implementing interfaces. But this is very convenient. And then I implement one method, which is called the activate metadata method. And I declare all the constraints. This is regular Java code. And I can modify these. I can add constraints at runtime. I can modify them if I want to. And Rive, so these are the constraints. And Rive will put them together automatically. We'll use these two classes. And behind the scenes, it does some very nifty bytecode modifications and stuff like that that are reloaded to put these two together. This allows you to really separate the different concerns and to add metadata to existing classes. So how do you use this? Because now we just showed how to declare them. How do you use this? This is how you create a structure. So I create, because I want to use a content manager. And the content management framework. I use a content query manager. I give it a data source or the database with which it has to work. As an instance, I know I want to store news items. And I install it. Bam, done. That's it. It installed the class, installed all the columns according to the constraints. It added a sequence if your database needs this. My SQL, for example, doesn't need sequences to do identifiers. It handled the foreign keys, everything. In the templates, it's the same thing. You can use value placeholders with a specific name. I say, for example, a form input with a disname. So the title there will automatically be changed by the actual HTML with the maximum length filled in. And I can still customize it. I can add an ID to be able to write a label for it to do some proper HTML. This is how you do data validation. So it's got a few concepts together in the same thing, actually. I get the submission. So if you see in the top, there is this, does this work? News item. And I get the submission beam after the submission has been done. So I get it from the request. Then I create, again, this content manager that we saw in the previous slide. And I simply say the news item has to be validated against the manager. Why against the manager? You could also validate it against itself. But if you validate it against the manager, it can check unicity, for example, for you. If you add a certain constraint to a property that it has to be unique, it can go directly to the database and check if it's not already there and then give you a validation error, stuff like that. It can also check foreign keys for you to see if the value that's filled in in a certain property is a valid value for the foreign key that goes towards another table. And then here, I generate the form. So in case that the validation doesn't succeed, I generate the form. And this will generate these fields. And it will fill them in with everything that's needed. And additionally, oh, sorry, wrong button. Additionally, it will markup errors, give you error messages. Now, all these are just invisible if they are not filled in. And then here, I save it, I save the news item. That's all I need to do to persist my domain model instance. So it will store them into the database storage and into the content storage. And split it out accordingly. The images and the rich text will be stored in the content storage and the rest in your regular database. But we can do better. This is still too much code if you want to, I don't know, write a simple crowd application, something that you do all the time, create, report, update, and delete. I've got my domain model, and I just want to get something running quickly. I want to provide an administration interface, for example, for my customer. I write this web application. The front end is really cool for all the users. But he has to have an administration interface. And then you have to spend, I don't know how many times to write this administration interface. It's a bit silly. So we can do better by using Rivecrud. And Rivecrud automatically generates entire websites according to your domain model. And it uses these constraints to do so. But contrary to most existing solutions, it doesn't generate any code. It does this at runtime. It creates the structures on the fly. It creates this side structure that you saw in the beginning on the fly. It creates your templates on the fly. Everything is done on the fly without any code generation that might bleed into your CVS or subversion repository and then change by someone and then overwritten when it's generated again. It doesn't, you don't have these problems. And by using the constraints that I explained earlier, Rivecrud is able to do all these nifty things automatically. But it still uses Rive's component model. So these elements that you declared in the side structure, it uses that. And actually, it generates a whole site for you, a component as site, that you can plug in anywhere in your structure and integrate with any application. And therefore, it's got the necessary extension points to customize it and make it yours. Of course, functionality that's generated on the fly is very handy, but if you can make it yours and look like what you would like to have, it's even better. So it's got a whole bunch of features here, support for localization. The CSS that's in there by default is well structured. You add the templates with several levels of granularity. You can localize things. There is an API, Java API, to be able to execute these reflection-based algorithms from within your own logic. You can generate, so the menu is generated on the fly, you can replace that too. It's the whole bunch of things. And this is a quick demo. Actually, the presentation is done afterwards, so you can just sit down and relax. This is something I recorded. Oh, no, sorry. I forgot there was some source code. This is actually the source code for the domain beans. So I added several properties, a moment property and a category ID to the news item that we had before. And there are some additional constraints. So the ID, I say that it's an identifier that's not editable, so there will not be any form field for it. This moment that I added has a certain format and it has to be listed when I have a list. The category ID is a many to one, so it will generate a foreign key and stuff like that. And I added another constraint that's not related to the property, but it's related to the beam, saying what the default order is if I want to report it. And additionally to the image, I say that it's listed and it's been submitted as a file. So it will automatically handle for you multi-parts requests and see that it's a file and integrate it into your property sort in the content management framework. All this is just done by saying file. This is the additional class because I said there was a category attached to the news item. This is an additional class, so the news items got an ID and name. This is very similar to what you already saw and this is something new. It's an anonymous inner class that allows you to generate a textual identifier for this category. So instead of having an ID that's being displayed when someone has to select a category, you can display anything you like. It generates this textual identifier as you see fit. And these are the two only things that I need to do to make these two domain models work in my application. So I've got a site structure again, I've got an arrival and I declare two subsites that are actually sites on their own and by using a specific protocol that's called the CRUD handler, I say instead of using a regular file, I say CRUD and I point it towards the class name. I didn't include any package here to make it fit on the slide but you point it towards your fully qualified class name and it will generate the whole site. And this is another thing. In the life cycle, so when the application starts up, we've got this repository with participants. You can add some specific participants to automatically create the database structure. That's all. No. Now of course, this will generate, the texts will be very boilerplate, it will be generified texts. So I added some localization. I haven't shown here what it looks like because we're out of time. But after adding some property files, regular Java property files saying localization, this key corresponds to that, I get this. So this has been totally generated by just putting these two domain models in a site structure. So I can manage the categories, it handles the validation for you because it knows that it's mandatory. So it indicated with a little star what was mandatory, what not. You have the reporting with paging, you can edit them again. Everything here can be customized, of course. Also the menu. So I added two categories, now I'm going to add the first news item. This is a textual identifier that has been generated, the ID and the name of the category. You see here that it detects what is mandatory and what not. It knows that the image is a file, so it will offer you the file upload. I can add HTML here. And I made a mistake, I forgot to close the B tag, to validate the XHTML, to see that it's valid XHTML, only when it's valid will allow you to submit it. So it's been submitted. Like at my reporting, everything that was listed there had listed true constraints. I'm going to add a file. And you see that this file here has got 392 width, while the width was constrained to 100. So it rescaled 120, sorry, it rescaled the image. I'm going to add a second news item. So all this has been generated on the fly. I can integrate it into any existing site that I wrote with Rive, customize it fully. Hold on, any questions? Yes? Yes, you can. So it's got a whole bunch of type mapping that will detect the type that's present in your table and map it to the Java type. So we've got default mappings to create the table when you want to create them, but it will accept almost any SQL type that's present and convert it into the Java type that's present in your domain model. If it's possible, if the conversion is possible, it will be done. I'm sorry, I didn't understand you. Yes? Yes, okay. Okay, so the question was, it doesn't generate Java codes on the fly, that's what I said, but it does generate bytecode. Yes, the Rive generates bytecode also, even if you don't use the CRUD API. So of course you have to have this policy, the security policy has to be activated, well actually disabled in your server container before this is possible, yes. Okay? It's actually extremely performant. I've got, there's a company now that's rewriting bank sites in Holland with Rive that was totally blown away because things are running on one server and it used to be PHP. We did a number of big sites with it. Are you from Belgium? No, okay. Otherwise I could say some names that you wouldn't understand, but sites of publishers that have a few million hits a month and a couple of thousand simultaneous users just runs on one server, it's, yes. Okay, so the question is, why use Rive instead of everything that's already out there and that is established and known by everybody? Okay. If you want to have a competitive edge, be able to deliver something with less effort, be able to jump onto new technologies like I didn't cover continuations for example, to be able to use the component model. I didn't detail this also because it's quite an extensive topic, but every element that you declared here can work as portlets, as mini-apps inside your templates so you can create whole apps that work as templates, as portlets inside your templates with just one object model. And another approach I think is that it's a full stack. You get 90% of what you would get from everything else and you don't have any effort at all to do. So, yes? It can be an input stream. Yes. Why do you? You can. Ah. Okay. So this will work, so it's a battery but it could be an input stream or it could be, there are a lot of types that are supported when you use constraints. I'll just put it back. So the question was why use a battery to store, actually to store the image in your domain model, I actually use always input streams because I rarely, when you have a domain model, your bean, you rarely want to have this image completely inside your bean. If you want this image, you usually manipulate it on its own and you can fetch this directly from the content management framework by just using one call also. So usually you do it like that and not for every instance of the bean. Typically, if this image is displayed, it will stream directly through the browser and not be inside your bean instance and then you're doing something with it, yes? But you can fetch this very easily with the content management framework API. So it's just one call away, actually. And like this it's well separated and it doesn't pollute your instance. But we can talk about this more extensively afterwards if you want. There was still one other question, yes? Web ML diagrams? So the question is, is there support for Web ML diagrams and to plants? Actually, not for Web ML, but there is someone that's finishing his thesis and it's got a visual editor in Eclipse running for the website, for the site structure. So there are visual editors coming out. And... Simply do the site structure and generate. Yes, yes. And his version actually does, how do you say this? Two ways communication with the source code and the visual editing. So if you modify the source code, the one will update and vice versa. Okay, thanks a lot. If you have got any additional questions, come and see me.