View source for VpPuZzle. Observe. Part 2

From wiki.visual-prolog.com
You do not have permission to edit this page, for the following reasons:
The action you have requested is limited to users in the group: emailconfirmed.
You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.
You can view and copy the source of this page.
{{spbCopyright}}

{{VpPuZzle. Observe. Naivgator}}
==Pzl-system== 
All features of the PZL mechanism are provided by the Pzl-system. Pzl-system contains some classes represented as source code and some classes represented as the statically linked libraries. It was used the feature of Visual Prolog that the source code of libraries can be written in Visual Prolog language.
The picture below shows the content of the PzlSystem for the executable entity (EXE).

[[Image:SystemStructure Exe.png]]

And the picture below shows the content of the PzlSystem for the DLL

[[Image:SystemStructure Dll.png]]

The difference is in the libraries and in the package pzlPort.pack, which used in the case of application.
There is no need to remember all these files – the Pzl-technology tools can generate the project for the DLL and any VIP application project can be easily modified to support the Pzl-technology. 
The name PzlPort was chosen for the core of the PzlSystem, which must be included to the application project.

The PzlPort is responsible for the loading and unloading DLLs. When user calls the pzlComponent constructor, PzlPort finds the DLL, which contains the appropriate pzl-component. If the DLL is not already loaded, then it loads the DLL and communicates with the classes of the pzl-container.

The PzlPort uses the order as follows:
*Local user defined registration file
*Current User at Windows Registry
*Local Machine at Windows Registry

The pzl-technology uses the same principles to support the lifecycle for classes. When the instance of the class is not needed, then all references to this class must be removed. PzlPort is responsible to unload the appropriate DLL, when there is no pzl-components in use. This happens, when the Visual Prolog garbage collector removes the instance of the class.

Thus User has no deal with the DLLs and has the deal the only with classes the same way as it would be using the standard VIP programming style

===Compatibility and Authorising===
Because of the parts of the applications, based on the pzl-Technology, may be build in different time and with the different versions of the Visual Prolog, the incompatibility between the application and DLLs and between DLLs may happen. Tools placed to pzl-port and pzl-container libraries communicate and check this compatibility before the use of components have started.  

If the incompatibility have descovered, then the DLL is unloaded and the exception is generated.

Also three levels of the licenses are used to avoid the unauthorized use of pzl-containers. These levels are:
#Public
#Commercial
#Exclusive

PzlPorts may have Commercial and Exclusive license levels, while pzl-containers may have all three levels listed above. The Exclusive license level has the highest privilege. 

The PzlPort can communicate with the pzl-containers, which have the same or the lower privilege.

The Exclusive license level is the private license and can be created for the given user personally. 

The PzlPort, which has the Exclusive license level of the given edition, can communicate with the pzl-containers, which have the same edition of the Exclusive license level. 

The use of the pzl-containers with the Public and Commercial license levels is available also in that case.

===Active Objects registration=== 
PzlSystem performs some functionality, which are not directly concerns with the component technology.

One of these kinds of the functionality is the Active Object registration. Let’s come back to the major construction of the VIP:
<vip>
...
   MyClassInstance =myClass::new() 
   MyClassInstance:callNeededPredicate(…), 
...
</vip>
Once created instance of the class will be destroyed if the pointer (reference) to the instance will not be stored. There are many situations, when one 
instance may be used by many other classes. Then it is needed to store the pointer to this instance in the place, which all components can easily reach. 

When we have the application built using the usual style we may have the static class, which can store pointers to instances. When we use the technology based on the DLLs we need some data store, which all components can refer to. In the pzl-technology the special data store engine embedded to the pzlPort. Any component placed to any container can easily make the operation like
<vip>
  MyClassInstance =myClass::new(), 
  pzl::register(“MyClassInstance1”, MyClassInstance), 
  MyClassInstance:сallNeededPredicate(…), 
...
</vip>
Any other object can get the object using the call
<vip>
...
  Object =pzl::getObjectByName_nd(“ MyClassInstance1”),
  !,
  MyClassInstance=tryConvert(iMyClass, Object), 
  MyClassInstance:сallNeededPredicate(…),
...
</vip>
Class Pzl contains many other useful predicates to manipulate with the object registration.

If we follow the idea of the open architect applications, then the user-defined component may have an access to all components active in the application at the moment. The only condition is that User must know the interfaces of the classes in this case and User must know the principles of the organization of the application.

===The common Error Handling space===
Vip has convenient error handling system. Pzl-technology supports the common error handling space. Thus any pzl-component has the access to the exception data common to all pzl-components of the application.

===The common standard output stream STDO=== 
All pzl-components, which are active at the given moment, use the same standard output stream.

==Summary== 
The following features of the Visual Prolog programming system used: 
*The VIP DLLs permit to use the deterministic and nondeterministic predicates invoked through the border of the DLL.
*The DLLs work in the same memory space as the main application
*The package-oriented source code organization
*The advanced class system
*The flexible interface concept, combined with the domain concept
*The existence of the domain object, which all instances belong to
*The localization of the constants in classes
*The conditional compilation
*The possibility to build statically linked libraries
The Pzl-technology has all advantages and disadvantages, which VIP programming has because of it don’t change much the VIP style of programming.

The pzl-technology sets some limitations:
*The only one constructor type may be used
*The interacting classes must be dynamic
*The names of the class and the base interface must be different
*Being DLL-based,  pzl-components can be invoked only by the applications, which use the pzl-technology and created by Visual Prolog tools

The usual limitations of VIP DLLs must be taken in account: 
*The DLL-based components must have the stable set of declarations of interfaces. When the DLL is built, any changes of the used interfaces may lead to the exceptions. All interacting components must be rebuild
{{VpPuZzle. Observe. Naivgator}}
*VIP DLLs use the Visual Prolog system run-time DLLs, ‘which are Visual Prolog version dependant. Any modification in these DLLs may lead to the unstable functionality. All interacting user components must be rebuilt when the new versions of VIP DLLs are issued.

==References== 
[[Category:VpPuZzle]]
Templates used on this page:
Return to VpPuZzle. Observe. Part 2.
Retrieved from "https://wiki.visual-prolog.com/index.php?title=VpPuZzle._Observe._Part_2"
View source for VpPuZzle. Observe. Part 2

Search

Navigation

external links

collaboration

Personal tools

Views
