 The core of OpenERP is built in Python and all the extension models are built in Python. And it's a cool, nice open source software. Now we will see how we can develop models and how we can integrate with the community and contribute to the project. So these are the main sites where we develop OpenERP. It's hosted in Louchpad. I'm pretty sure you all guys know Louchpad, and so it's Bazar. It's not kid, but it's cool anyway. So here we have the page with the main projects, the server where we can have access to the code, the stable branch is the 6.1, and the trunk it will be the 7.0. But for now we're working with the 6.1, and this is the server. And we have the client, which is made for the web. We used to have a GTK client. We still have it actually, but it's deprecated. For now the main interface, it's the web interface. So if you guys want to contribute, you can branch the project, the server or the client or the add-ons. This is the add-ons is actually where the fun starts because it's where are the models that gives all the functionality, like warehouse management, CRM and everything. This is kind of a model in OpenRP. It's not very different from a package. We usually have a folder add-ons and a folder with the model name, and then in it, point pi, and a very important file, the OpenRP, point pi. That's where goes all the information about that OpenRP needs to know to sell the model. And they go with the files with functionalities, where we define models, and where we define views, and where we define reports, and all the standard business type of software thing. What we're going to do now is we're going to create a small model to illustrate the model development. This model will help to manage the Montreal Paton events. It's based on the event model. It's a standard model, and we're going to extend it to add functionality. And we're going to have three interactions. The interaction 0.1, 1, 0.2, and 0.3. And here you go to the 0.1. It does nothing. 0.1. Here I have a Neal and Stylet instance of OpenRP. Look for our models. And here I have our model, our newly created model on install. Going to search for a lot of dependencies. We have a config parameter that says the folders where you can get the models. It's add-ons-dir. Okay, install. We're going to have to do some boiler pre-work because it started the account models as well. It was a dependency, but it would be quick. And we have our model started, but it does nothing. All this is from the standard events model. But let's see what we have to do to get this nothing. This is the only file that's in our project for now. And it's a dictionary with the definition of the model. Information about the editor, the developers, the dependencies. Instal a lot of stuff because our model depends on the event model that depends on the accounting model and a lot of other stuff. We have no demo, we have no data. But it's officially a model. Right now we're going to go to the 0.2 interaction. And in this interaction, we're going to add two new fields called event technical level that says the level of the conference. And we have three levels, newbie average show programmer and hardcore ninja kernel developer and the speaker technical level that goes with lane and not so lane. Well, I'm going to stop my 1.0. I'm going to start my 2.0 or 0.2. I already created an event in this conference. In our model, we have this event technical level which we have hardcore newbie average show programmer in the speakers. We have the speakers technical level. And cool, you see the result but you don't see why it's there. And that's what I'm going to show you. In our version 0.2, we have a data file. This data file defines the modifications that we have in the view. All views in OpenRP are XML files. So when you see this interface, it's generated from an XML file. And then you can start to ask, but wow, it's a big interface and you have only two fields. But the thing is, it's an inherited interface that is inherited from view event form. And you can go find view event form. So this big chunk of XML code, it's the complete view with all the pages and all the groups that we saw in the interface. And I extended that view from my file. I added two fields, but those fields came from where? I also extend the model. In OpenRP, which is a MVC system, we have model, views and controllers standard procedure. And this is a model controller actually because the models are in the PostgreSQL database. And this is also a model that is based on the parent model that's event. So we added two new fields that are selection fields. And like this, it creates the fields in the database and it managed the tables and everything. And now in the version 0.3, I added a report in our event. We have a nice report, nice PDF report. That is a list of the participating people. For the guy in the door who keeps note, who came and who didn't came, who said it would come and didn't come. It's a valid business need. But how do we get this result? I'm gonna go again to the code. In our OpenRP, we have another file report in that file. The report engine in OpenRP is based on report lab. I'm pretty sure you all know report lab. It uses RML, report make markup language. And we can generate these files, these RML files from OpenOps files. I have this report folder. When I have a report render, where I say the name of the RML file and the name of the render, it's an RML parser. And I have a nice, not at all dirty RML file with the dynamic content between these brackets questions. It's a little fast, but there's a time in here.