Module 3. Episode 6. Modules and client-server interaction

1C Junior Developer training course
Module 3. 1C script language basics

Start learning now for free ? https://academy.1ci.com/

Telegram chat: https://t.me/joinchat/DRc2iRL1O5OcAJYpX6RCIA
Blog on Medium: https://medium.com/yellow-universe

#1CiAcademy #1CEnterprise #LowCode

Link to the training course: https://support.1ci.com/hc/en-us/articles/360021920154-Welcome-to-the-1C-Junior-Developer-training-course

OK. Now we know how to write the source code in 1C:Enterprise. How about where to write it and where it goes after it’s written? That’s right. Let’s talk modules and the client-server interaction.

Please tell me, you still remember that the form module can have both client and server-side methods? During the compilation, the client part of the module goes to the client side and the server one goes to the server.

They share the same module, so they can call each other. Well, for the most part. Client-side methods can call any other methods including the server ones, and the server-side ones can call only each other.

If there is a Metadata Object living on the same side of the client-server boundary (like this Companies catalog, for example), my object can create its instance like this - from the object’s reference - or any other way for that matter. And then get access to all its Export methods.

So, your ability to access an object method comes to these two things. First: does the object live on the same side of the client-server border as you do? Second: is the method you’re interested in an Export one or not?

So, let’s make sure we know who lives where.

Form module gets split up into the client-side and the server-side parts, regardless of whether the form belongs to the Metadata Object or lives all grown-up and independent in the Common forms. The same applies to the Command module.

Metadata Object modules live only on the server side, whether it’s the object module or the manager one.

Now. What about the common modules? This one goes to the server because of this flag right here. So, I can write an export procedure here, and it will be accessible from any other server module just like this.

Will it be accessible from the client, though? Not so much. The thing is that the server modules are hidden from the client unless this flag is on. How about now? No problem.

So, do not forget to set the Server call flag if you want your server module to be accessible from the client side. So, this was the server-side Common module.

The client-side module, like this one, goes to the client. Obviously. And any Export method now can be called from any other client-side method. But not from the server, because upstream calls is an absolute no-no in the client-server architecture.

So, these are our client-side modules. Interestingly enough, we can create a Common Module with both Client and Server flags. And how is this supposed to work?

Well, the Platform just makes two copies of the module and sends them both to the client and the server sides. So, the method I write here is now accessible from anywhere.

Why on Earth might we want this kind of a module? Well, sometimes (quite often, honestly) we have many general-purpose procedures we want to call from anywhere.

For example, at some point in the future, I might start thinking about some across-the-board standard for my error messages. They should always include some title, the error info, and so on.

So, I will create a procedure named MessageThis in a common module and make it accessible for both client and server because errors can happen anywhere, right?

But back to our client-server saga. We do know now what’s accessible where in terms of the application tree residents. How about the rest of the 1C script objects and classes?

The short answer is: look it up in the Syntax Assistant. For example, this Catalogs object is accessible only from the server side. And don’t mind this "thick client" thingy. We arenтАЩt supposed to use it anymore and never refer to it in this course.

This is what we’re looking for. This means that we can use this object on the client side.

As for a longer answer, here it goes: almost everything is accessible from the server side. And the reason is: we want the most of the workload to go to the server. The client should be as light-weight and undemanding as it gets.

There are some exceptions, of course. These interactive guys, for example, are mostly client-side, for they show various kinds of message boxes and stuff, which is doable only on the client.

So, this was all I had to say about 1C script language for now.

See you for the next Module: UX/UI basics.