So far we didn't write a single line of code, but somehow managed to get a lot of things done. Usually it works like this only for quite simple applications doing some standard stuff. As soon as you need anything fancier or less standard, you're looking at writing some code. So, let's scratch the surface of this very extensive topic. [MUSIC] Let's look at some very simple example, and least old events right here. First, a user double clicks on this product catalog item. Then the platform opens this item form. Next, the user changes the units of measurement field value. And eventually the user clicks on Save, and Close. Now, to allow us to customize these functionality the platform exposes for us so called events, between these major happenings. [SOUND] These events are the places we can insert ourselves code in, let's see what exactly we have on hand. Her set of events happens before, and during the product catalogue item form opening. If we look at the forms properties, we will see them right down here. On create on server,and on open. [SOUND] If we click on the event, we'll get into the objects module. And here is our event handler. The procedure we can write ourselves code in, but back to the example. Next, the form gets open, and to the user changes the value of the units of measurement held. Let's check out this element events. And here is the on change event that happens at this point. [SOUND] Then the user clicks, Save, and Close. And these triggers a whole lot of various events. First bunch of them leave in the forum. They are the right events, and different closing events. Besides that, we have some quite similar events on the metadata object level. So, if we open the product catalog metadata object module, there will also be the before right, and the own right events. I also can click any of these, and write my event handler here, why there are pairs of similar events on the forum, and on the metadata object level. So anyway, hold on the thought please, we'll get back to it later. So, any code in one's enterprise always starts with an event. The events are the places democracy developers can insert some source code in, to modify the application appearance, and behavior. Need to change the default behavior of the system, is to look for the appropriate event and to write the event handler code. Vanilla the event happens the platform will run your handler, and do whatever you have implemented. This is how it works, and one more thing, all events are predefined by the platform. We can handle them, but we cannot add a new event, wherever we wanted. There are also some events connected to the application as a whole. They live here in the application module. There are the events that happened when the application starts, when the application finishes, and so on. From that script language syntax point of view, the event handlers are just procedures you need to implement. So, this is what once is quick procedure looks like. It starts with a keyword procedure, and answer with a keyboard, and procedure. Both of these guys are mandatory. After the procedure keyword there must be the space, and an arbitrary procedure name, followed by the round brackets, that can contain the list of procedure parameters. In the case of the event handler, this set of parameters is predefined by the platform. Can you use the handler parameters to get the operation context, and to control what happens next? Okay, now let's write some code, shall we? There is a task for us to start with. When I opened the product item, and change its type to service. There are still the brand, and the Euro outfield so that doesn't really belong here, do they? So, I want these two guys hidden, if I select the service product type. So step one, find the event we need to use, this entire action happens inside this form, right? So, let's open it into designer. Here is our prototype field, and here is it on change event. Okay, that was easy, let's just click here, and write some code, right? Except the platform is asking something again. Okay, let's take a closer look. There are actually the code templates that the platform can create for us. And the difference between them is all about the client server interaction. So,let's look at this part first. >> [SOUND] >> So,here is the deal. The platform utilizes the three tire architecture. The approach that recognizes the three isolated layers of the application. The client, and the application server, and the database server. This architecture is the one we wrote, requests always go downstream only. The client can call the application server, and the application server, can call the database server. But never the other way around, the forum leaves in one, see client, the data leaves in the database server. Whenever the forum needs the data, it has to ask the application server to get it, because he's the only one who can do that. And the form asks the application server using the form zone module. That's in a way suits on two chairs. It can have some procedures working on the client side, and others working on the server side. How does the module now, the client side procedures from the server side ones? Well, it actually doesn't. So, you need to tell it, if you want the procedure to run on the client side, you want to put the ad client completion directive right before the procedure declaration. If you want to try to underserve site, you want to put the etc directive. [SOUND] The ad server procedure passes the entire form to the server, and make it accessible for the procedure. So, the server side procedure can read, and change anything in the form object, attributes, values, form elements etc. When such a procedure finishes, it passes, the changes form back to the client. These form passing back, and forth takes time, so you want to do it only when it's really necessary. Otherwise, you want to use at server now context calculation directive. To speed up the app, and reduce resource usage. So, let's put it all together. First you find the forum event you want to handle. [SOUND] And then you bind the event with the Add client procedure. If you don't need to access any data, you stay in this procedure, and do whatever you want within the forum. If you do need the data, you go either add server or server, no context procedure, depending on whether you want to work with the form on the server or not. And then you access the database data from any of these two. Okay, now let's clean this up, and ask the platform to create a handler for us one more time. [SOUND] Now this question is quite clear. Do we want to work within the form or we need to access the data? And if we do, do we need the form to be accessible for the server or not? What we actually need is to compare at least one attribute, with the product types, and humiliation value, the attribute leaves on the forum, but all the numerations, as well as all catalogs documents, and registers live in the database. So we're going to need a server recall. We are comparing the only value, so we don't want to pass the entire forum to the server, and back. So, this is our choice, and here we go. This is our client procedure that will be called as soon as the product type field value is changed. This client procedure calls the server procedure, that has an access to the data, so we can get the enumeration value. And now we are ready to write some code. [MUSIC]
