Af-Gen Syntax Reference

Command reference index

Af-Gen syntax considerations

server interface

 Syntax:
    server interface af-server-name { server-definitions }
 Where:
    af-server-name    = (required value) server name to be produced 
    server-defintions = more af-gen IDL lenguage definition to stablish what
                        is going to implement current server.
 

Defines the interface for an Af-Arch server. It includes all definitions used to build the given server.

Here is an example:

server interface af-server-name {
        // interface definition
}

Note:
Server names allways needs to start using af- prefix (see Naming convention inside the Af-Arch.)
All posible declarations which already support af-gen language are:

module

 Syntax:
    module module module-name (types) [modifiers] { module definitions }
 Where:
    module-name        = module name identifier
    types              = a module attribute type defintion.  
                         See also supported types.
    modifiers          = module modifiers. Allowed values:
                         implicit definition or without sql. 
    module definitions = Definitions for the current module. Allowed
                         definitions are: relation statements, services declarations,
                         independent doc declarataions, reserved services declarations,
                         and disable services statements.
 

Defines a new module to be produced by af-gen tool. The module can act as a service holder, as other IDL syntax, but it can act as a type definition in conjuntion with implicit definition to produce common required services.

As a service holder here is a simple example where the given module holds three services:

server interface af-server-name {
        module my_data () {
 
                public get () return simple;
                
                public store (int value) return nul;
                
                public remove_all_data () return nul;
        }
}

In the previous example, af-gen will produce a server and an STUB connector having only one module with three services. This services will be generated with no code. Services can also be implemented inside the IDL definition. Check services definition.

In the case we want to let af-gen to define implicit services according to module types and its relations we have to do the following:

server interface af-server-name {

        // relation declaration
        relation relationName;

        // module nameB declaration
        module nameB (decimal (10,2) value, boolean is_something) implicit definition {
                // set relation with module nameA
                nameB relationName nameA with 0..n;
        }
        
        // module nameA declaration
        module nameA (int value, string value2) implicit definition {
                // set relation with module nameB
                nameA relationName nameB with 0..n;
        }
}

Previous example declares two modules using implicit definition module modifier. This modules are linked through the relation declared.

Previous declaration will make af-gen to figure out services required according to this definition. See implicit definition documentation to more about services declared.

On previous example we are declarating two modules relationed though a M:N relations, as the followign diagram:

relation-example.png

As we have see, inside a module definition can be declared new services and relation between modules. In addition to previous declaration a module can also hold the following:

Service definition

 Syntax:
     [public] service_name (types) return [return-type] {optional-user-code} optional_semicolon;
 Where: 
     public             = (optional value) marks the given service as public.
     types              = incoming paramenter types definition
     return-type        = return value definition. This can be nul, simple, 
                          string, node, decimal, user defined type or no stub
     optional-user-code = (optional value) service implementation. This code
                          will be inserted inside the service implementation
                          at server side.
     optional_semicolon = (optional value) a semicolon to end service definition.
 

Services inside Af-Gen IDL language are placed inside module definition. To flag a service to be available to any Af-Arch users use public keyword. Otherwise it will be flaged as private. This means users will need permissions to execute the given service.

Following service name is found service types definition. This types are the parameters this service is expecting to receive. Check supported types section to know more about available incoming types.

Next to service type definition is found the return type. Inside the Af-Arch framework return types are especial. You can only return four types. Again, check supported types section to know more about available return types.

Finally, once defined previous values, is allowed to provide service implementation. This code will be placed inside the right place into the generated server component.

Here are some examples:

server interface af-server-name {

        // type definition
        type item_list is data (string value, int value2) index (id);

        // module declaration
        module test ()  {
                // public service definition with no user code
                public make_operation (int value1, boolean value2, string value3) return nul;

                // private service with user code
                how_many_items () return simple {
                        CoyoteDataSet * result;

                        result = afgs_command_execute_single_query ("SELECT count(id) FROM items");

                        AFGS_OK ("available items", COYOTE_CODE_OK, result);
                        return TRUE;
                }

                // public service which returns a user defined data (item_list)
                get_my_data () return item_list {
                        CoyoteDataSet * result;

                        result = afgs_command_execute_single_query ("SELECT id, value, value2 FROM items");
                        AFGS_OK ("item list", COYOTE_CODE_OK, result);

                        return TRUE;
                }
        }
}

In case it is not required to generate the STUB connector but the service, no stub command must be used as return-type. This will make af-gen to build the service especified but not building the STUB connector.

relation

 Syntax:
   relation relation-name semicolon
 Where:
   relation-name = new relation name declaration. Relations have to be declared before
                   been used by module definitions.
 

Allows to declare a two way relation between two modules. Relation must be declared before being used.

Once declared inside a module declaration a relation is used as follows:

 Syntax:
     moduleA relationName moduleB with relation-type on delete delete-semantic semicolon
 Where:
     relation-type   = 0..1 | 0..n | 1..1 | 1..n
     delete-semantic = keep | remove
 

Relations between modules is strongly based on entity relations inside Model-Entity theory.

Keep in mind previous declaration only defined one way for the given relation relationName. Other way must be declared inside the partner module. If a relation is half declared, that is, only have one side declared, af-gen will report an error.

implicit definition (module modifier)

  Syntax:
    module (types) implicit definition {
    }
 

Module modifer which activates automatic service definition according to module types and its relations. Once used af-gen will create implicit services that are commonly used in the domain problem Af-Arch was designed.

Here is the services produced according module situation:

Description Example Implicit services
Module is declared as a standalone. No relation with others.
 // module declaration with no relation
 module test1 (int value, string value2) 
                    implicit definition; 
  • new: creates a new item using the module types. This new services accept as parameters to create the new item those defined as types for the current module.
  • remove: removes an item selected by the unique identifier.
  • edit: edit attribute values for one item selected by the unique identifier. As the new servic, edit service receives the same parameters plus an unique identifier used to identify the object to edit.
  • list: returns a list of items created. This services have two arguments. An initial id to start list result an a maximum list length to return.
  • num_elements: return the number of items created. Service generated doen't require any parameter.
Module is declared with a 1..1 relation with other module.
 // relation for test1 and test2
 relation relation1;
  
 // module test1 declaration
 module test1 (int value, string value2) 
                    implicit definition {
     test1 relation1 test2 with 1..1;

 // module test2 declaration
 module test2 (itn value) 
                    implicit definition {
     test2 realtion1 test2 with 0..n;
 }
  • new: new service for module relationed using 0..1 relation are created as the standalone example, that is, adding all paremeters defined for the module types, but adding an additional parameter which is an unique identifier pointing to the peer module instance to be associated at creationg time.

  • edit: edit service Edit service receive the same parameters the new service does but adding a new parameter identifying the object to be edited.

  • NOTE: This services are implicitily created no matter what relation the partner module has with no restriction for other services obtained by other relations.

Module is declared with a 0..1 relation with other module.
 // relation for test1 and test2
 relation relation1;
  
 // module test1 declaration
 module test1 (int value, string value2) 
                    implicit definition {
     test1 relation1 test2 with 0..1;

 // module test2 declaration
 module test2 (itn value) 
                    implicit definition {
     test2 realtion1 test2 with 0..n;
 }
  • peek service: peek service Because 0..1 relation doesn't requires to establish a relation between modules at creation time the new service is create as it were defined as a standalone module. But peek service is provided to allow knowing if the given module test1 have set a reference to a instance for the module test2. Result from peek service is a simple value. See supported types for returning values". This simple have the reference to the partners instance of -1 if partner relation is still undefined.

  • add_element service: This service allows to establish the reference for the given module instance to other module instance. Value set for this service is returned by peek service. This service is built requiring two parameters: both unique identifier to modify the relation.

  • remove_element service: This service allows to remove the relation already established. If no relation were set the service have no effect. This service is built requiring two parameters: both unique identifier to modify the relation.

  • set_element: this service allows to remove or to establish the relation between two instances according the a thrid value which is a boolean.

  • NOTE: This services are implicitily created no matter what relation the partner module has with no restriction for other services obtained by other relations.

Module is declared with a 0..n relation with other module.
 // relation for test1 and test2
 relation relation1;
  
 // module test1 declaration
 module test1 (int value, string value2) 
                    implicit definition {
     test1 relation1 test2 with 0..n;

 // module test2 declaration
 module test2 (itn value) 
                    implicit definition {
     test2 realtion1 test2 with 0..n;
 }
  • add_element service: This service allows to establish the reference for the given module instance to other module instance. Value set for this service is returned by peek service. This service is built requiring two parameters: both unique identifier to modify the relation.

  • remove_element service: This service allows to remove the relation already established. If no relation were set the service have no effect. This service is built requiring two parameters: both unique identifier to modify the relation.

  • set_element: this service allows to remove or to establish the relation between two instances according the a thrid value which is a boolean.

  • list_element: this service allows current instances for the other module which are relationed with the given instance. This service only require the module unique identifeir to get relations to other modules.

  • num_element_list: as num_elementservice this returns the number of instances the previous services returns.

  • update_all_element: this service allows to update all element which are relationed with the given module instance. As parameters this service requires a module instance identifier and a list of elements to set as module instance relationed.

  • delete_all_element: this service is the oppose service for update_all_element and allows to remove all references to other module instances for the given module identifier. This service requires only one parameter, the module unique identifier to remove its relation to its partners.

Previous definitions are higher level descriptions. Services name are built using concrete names using the following tables supposing they are generated using a server interface definition as the following:

  server interface af-definition {
 
       module name_a (types) implicit definition {
          // relation definition to module name_b
       }

       module name_b (types) implicit definition {
          // relation definition to module name_a
       }

  }

This is because service name inside the stub files are generated using the standard naming which depends on server name and module name.

Reserved service Mapping to C Mapping to C#
new afdal_af_definition_name_a_new Commit class definition NameA inside namespace AfDefinition
edit afdal_af_definition_name_a_edit Commit class definition NameA inside namespace AfDefinition
list afdal_af_definition_name_a_list GetList class definition NameA inside namespace AfDefinition
remove afdal_af_definition_name_a_remove Remove class definition NameA inside namespace AfDefinition
num_elements afdal_af_definition_name_a_num_elements NumElements class definition NameA inside namespace AfDefinition
add_element afdal_af_definition_name_a_name_b_add NameBAdd class definition NameA inside namespace AfDefinition
remove_element afdal_af_definition_name_a_name_b_remove NameBRemove class definition NameA inside namespace AfDefinition
set_element afdal_af_definition_name_a_name_b_set NameBSet class definition NameA inside namespace AfDefinition
element_list afdal_af_definition_name_a_name_b_list NameBList class definition NameA inside namespace AfDefinition
set_element afdal_af_definition_name_a_name_b_set NameBSet class definition NameA inside namespace AfDefinition
element_peek afdal_af_definition_name_a_name_b_peek NameBPeek class definition NameA inside namespace AfDefinition
num_element_list afdal_af_definition_name_a_name_b_num_elements NameBNumElements class definition NameA inside namespace AfDefinition
update_all_elements afdal_af_definition_name_a_name_b_update_all NameBUpdateAll class definition NameA inside namespace AfDefinition
delete_all_elements afdal_af_definition_name_a_name_b_delete_all NameBDeleteAll class definition NameA inside namespace AfDefinition

NOTE: All services generated by implicit definition are considered to be reserved. This means it is not posible to implement a service with equal name. However reserved services can be reeimplemented using reserved syntax.

without sql (module modifier)

  Syntax:
    module (types) without sql {
    }
 

Allows to disable SQL generation for the server selected. This modifier can not be selected at the same time with implicit definition (module modifier).

This modifier is especially useful when writting custom services inside custom modules where these modules are acting as service holders.

If all modules inside a server definition have set without sql flag, the result server will have disabled SQL backend. To reenable it use --enable-bbdd-access as option to af-gen tool.

Here is an example:

server interface af-server-name {
        module my_data () without sql {
 
                public get () return simple;
                
                public store (int value) return nul;
                
                public remove_all_data () return nul;
        }
}

in, out and inout (type semantic)

 Syntax:
    type-semantic allowed-type param-name
 Where:
    type-semantic = in | out | inout
    allowed-type  = int | string | decimal | boolean | set of 
    param-name    = the name for the given parameter
 

Allows to define semantic for types definition for modules declared with implicit definition modifier.

By default, all parameters are implicitly declared as inout. This means the parameters for the module definition are considered public. All attributes will be required in all operation. All attributes will be used in all operation that returns list of elements.

In some cases, it could be needed to declare some parameters that only are received from server side but are not required to be especified at new and edit service. This can be accomplished setting the parameter with the out modifier.

In case a parameter will only be required to be passed in to new and edit services but not received when list service is invoked. In this case, the parameter must be flagged with in type modifier.

Type semantic is only applied to module declaration with implict defininition. For custom service definition, type semantic is ignored.

no stub (service return type)

 Syntax:
    service-name (types) return no stub {
    } 
 

Allows to disable STUB connector generation for the given service. Service will be generated at service side.

This can be useful to implement some especial operation with returned data.

To disable STUB connector will enforce you to invoke afdal_request function directly.

doc

 Syntax:
    doc { doc-declarations } 
    doc-declarations         = param param-name constant-string |
                               service-doc { service-doc-declarations }
    service-doc-declarations = short contant-string |
                               param param-name constant-string |
                               description { string-description }
 Where:
    param-name         = string value identifing the param to be documented. Used
                         outside service-doc-declarations documents module params. Used
                         inside service-doc-declarations documents service params.
    contant-string     = one line string description enclosed by "" simbols.
                         Used next to param describes a param. Used next to short, 
                         describes the service where short sentence is found.
    string-description = long string description allowing several lines with no
                         constraint. 
 

Allows to declare Af-Gen independent documentation format. This doc format allows to document module parameters, service parameters, service short descriptions and service long descriptions. Then, this independent doc format is traslated into the proper format selected inside the source code generated.

Currently there is only support to translate independent format into doxygen (http://www.doxygen.org) format. To activate doxygen output the --enable-doxygen option must be passed in to af-gen tool. Seen af-gen help: af-gen --help

Document syntax is allways found inside a module definition. As the following example:

server interface af-server-name {

        module module_to_doc (int value, string param2) implicit definition {
 
                public service_to_doc (decimal(10,2) my_value, boolean is_something) return simple;

                // independent format doc declaration
                doc {
                        // this document param value for module_to_doc
                        param value "Document module_to_doc value param";

                        // this document param param2 for module_to_doc
                        param param2 "Document module_to_doc param2 param";
                        
                        // to doc a service for the given module just reference
                        // it.
                        service_to_doc {
                                param my_value "Decimal value to do something";
                                param is_something "Check whenever something is";
                                short "A short description for the service";
                                description {
                                        Long format description,
                                                
                                        Inside description, new lines are
                                        left untouched and conserved as is inside the final
                                        documentation inserted into source code
                                        generated
                                }
                        }
                }
        }
}

As you can see, previous example documents the module parameters and one service. To document a service has the same semantic as document module parameters. In addition, doc command allows to introduce a short service description and a long description.

In previous example we have see how a service is documented. This is the same to document the reserved services, that is, those that have been generated by implicit definitions.

In case the new service must be documented, doc section have to refer to the service name as it were defined explicitly. Here is an example:

server interface af-server-name {

        module module_to_doc (int value, string param2) implicit definition {
 
                // independent format doc declaration
                doc {
                        // this document param value for module_to_doc
                        param value "Document module_to_doc value param";

                        // this document param param2 for module_to_doc
                        param param2 "Document module_to_doc param2 param";
                        
                        // document reserved new service.
                        new {
                                short "Creates a new item for module_to_doc";
                                description {
                                        This service allows to create a new item
                                        using provided values. As especial case...
                                }
                        }
                }
        }
}

In previous example, to document reserved service new we didn't especify document for params received by new service.

This is posible because service document system first lookup for document defined inside the service. If it isn't found, then the look up is extended to module parameters.

In this case, service new have the same parameters as the module. This allows to reuse documentation done to module at the new service.

reserved

 Syntax:
      reserved service-name () {source-code}
 Where:
      service-name = reserved service name to be overrided with
                     the given code
      source-code  = source code definition to be used to
                     replace source code provided by af-gen
 

Allows to override services declared due to implicit definitions. Service generated by implicit definitions are considered to be reserved. To override source code generated for them you can use this command.

Syntax is straightforward, here is an example to override source code generated at the server side for new service:

server interface af-server-name {

        module module_to_doc (int value, string param2) implicit definition {
 
                reserved new () {
                        // source code to implement new service.
                }
        }
}

disable services

 Syntax:
    disable services service-name, [service-name2,..] semicolon
 Where:
    service-name(N) = service (or services) to be disable (not generated) by af-gen.
 

Allows to avoid serviced declared due to implicit definitions to be generated. Because Af-Gen automatic service generation can be generating more services than it could be required, disable service< command allows to select and disable service generation.

To avoid reserved service new and edit to be generated use the following example:

server interface af-server-name {

        module module_to_doc (int value, string param2) implicit definition {
 
                disable services new, edit;
        }
}

Service disabled will not generate server side exported service and STUB connector function.

Disabled service can be extended not only to reserved service but also to explicit defined service.

type

 Syntax:
   type type-name is return-type (types) index (index-attribute) semicolon
 Where:
   type-name       = user defined type name. This identifier will be used to be referenced
                     from services declarations.
   return-type     = multi or data. This defines how this user defined data is.
   types           = a set of types which defined the given type.
   index-attribute = attribute used as index.
 

Inside supported types to be returned, there are two especial cases: data and multi. data type is a list of items returned by a remote server, normally a list service. multi is a set of data instances.

Normally, returned data values are infered due to module type definition. This allows to create list of items having as attributes those defined for the module.

However, while creating custom services, it will be necesary to create custom data and multi types. This is done using type command.

Type command allows to build custom data types definition as follows:

server interface af-server-name {

        // custom type definition
        type custom_data_list is data (int value, string value2, decimal (10,2) value3) index (id);

        module custom_module ()  {

                public get_list_item (int initial, int max_row_number) return custom_data_list {
                        // some select stuff to return a custom_data_list
                }
        }
}

All custom type definitions are placed outside module definitions. This allows to reuse them across modules. In previous case, we have defined a custom_data_list which is used from get_list_item service.

Previous custom type definition is a data definition with three attributes plus the id attribute which is obligatory to all datanodes.

At the end of the type definition is found the index keyword. This allows af-gen to know which attribute will be used as attribute to order elements inside the data returned.

In this case we have used as index the default id attribute. Allowed index attributes can be int parameters defined at the type definition or a string parameter. It is also allowed a set of strings as index.

Service programmer must ensure that the index constraint is implemented for all service that returns the custom type definition. This is importat because client layers are expecting to received an ordered element list using as index the index especified.

Type definition is only allowed outside module definitions, holded by server definition.

enum

 Syntax:
     enum enum-name { enum-value, [enum value2,..] } semicolon
 Where:
    enum-name     = enumeration name.
    enum-value(N) = values to be included into the enum definition.
 

Alows to define an enumeration to be used as parameter type for services. Here is an example:

      enum EnumType {value_1, value_2, value_3};

Enum values are defined outside module definition. Check supported types to know more about enum values and how they are mapped.

view

 Syntax:
     view view-name from base-module with module-name1, [module-name2,..] semicolon 
 Where:
     view-name      = the view name.
     base-module    = view declaration base module.
     module-name(N) = module name already declared to extend the given view.
 

View command is especially designed to solve a set of problems related to modules that are relationed thought 1..1 relations.

Normally, when a module A refers to other module called B using 1..1 semantic, this means this instance have only a reference, that is unique and allways it is set. When showing a list of value for module A, allways appears the problem of showing its unique partner inside the same row without the need of any additional operation.

view command allows to get a "unified row" by join values for a chain of modules having a relation 1..1 set.

Here is an example:

server interface af-server-name {

        relation rel_a;
        relation rel_b;

        // module a declaration: first item inside the chain
        module module_a (int value_a, string value2_a) implicit definition {
                module_a rel_a module_b with 1..1;
        }

        // module b declaration: second item inside the chain
        module module_b (int value_b, string value2_b) implicit definition {
                module_b rel_a module_a with 0..n;
                module_b rel_b module_c with 1..1;
        }

        // module c declaration: third item inside the chain
        module module_c (int value_c, string value3_c) implicit definition {
                module_c rel_b module_b with 0..n;
        }

        // view declaration
        view module_a_extended from module_a 
                 with module_b (value_b, value2_b), module_c (value_c, value3_c);
}

View declaration generates an implict list service which returns a data. Items inside the returned data has as attributes those declared in the view's chain.

View chain is composed from attributes from base module (in our example module_a) and those attributes selected from the modules apearing after with keyword.

Additionally, any view created can also be searchable using search interface but not replaceable.

use

 Syntax:
     use "file-to-include" semicolon
 

use keywords allows include external IDL definition inside the current IDL at the same place use was used.

This command works as include command on other languages, which allows to replace the use declaration with the code inside the file the command include.

use command can be used at any place of the IDL definition.

Here is an example:

server interface af-server-name {


        module module_a (int value_a, string value_b) implicit definition {
                use "some_services_definitions.idl";
        }
}


Where include file is:

public get_list (int initial, int max_row_elements) return module_a;

startup check

 Syntax:
     startup check { user defined source code } optional-semicolon
 

Allows to define source code to be run at the server statup. Here is an example:

server interface af-server-name {

        startup check {
                // some code to check if server can run
                // this code is run at the server start.
        }
}

As example, this command is used by af-kernel to perform some environmental checks on startup.

include on definition

 Syntax:
     include on definition { source code } optional-semicolon
 Also accepted:
     include on header     { source code } optional-semicolon
 

Allows to define custom source code to be include inside the header definition at server side. Source code definition is include at the module where this declaration was found.

Include on definition declaration can only be made inside module definitions.

Here is an example:

server interface af-server-name {

        module test_module () {
                include on definition {
                        // source code definition to be include at server side inside 
                        // headers files (.h)
                }

                include on body {
                        // source code to be include at service side inside the
                        // body definition (.c)
                }
        }
}

include on body

 Syntax:
     include on body { source code } optional-semicolon
 

Allows to define custom source code to be include inside the header body at server side. Source code body is include at the module where this declaration was found.

Include on body declaration can only be made inside module bodys.

Here is an example:

server interface af-server-name {

        module test_module () {
                include on definition {
                        // source code definition to be include at server side inside 
                        // headers files (.h)
                }

                include on body {
                        // source code to be include at service side inside the
                        // body definition (.c)
                }
        }
}

include on sql for install

 Syntax:
     include on sql for install { SQL code to be included inside install.sql } optional-semicolon
 

Allows to declare custom SQL sentences to be include at the final install.sql file.

include on sql for uninstall

 Syntax:
     include on sql for uninstall { SQL code to be included inside uninstall.sql } optional-semicolon
 

Allows to declare custom SQL sentences to be include at the final uninstall.sql file.

unistall.sql file contains all elements to uninstall SQL database required by a server.

Supported built-in types

The following base types are supported to be used at user type declarations, module type definition and services type definitions.

As types for incoming data are defined the following (servers view):

TypeDefinitionMapping to CMapping to C#Mapping to SQL
intInteger values ranging from -231 to 231gint (actually a define to int)intINT (and SERIAL for common Id value)
string
or string(size)
String value definition with no format (utf8 is not enforced but prefered)gchar * (actually a define to char *)stringVARCHAR (size) where default size is 250 characters
booleanBoolean valuegboolean, values: TRUE, FALSEboolBOOLEAN
decimal
or decimal(size,decimals)
A fixed decimal value representation with unlimited size representationAfDalDecimalAfDecimalDECIMAL (size,decimals) where default size is 10 and decimals is 2
enum declarationEnumeration declarationsA C enum declarationA C# enum declaration INT
set of [int|string|bool|decimal] identifierA list of elements of type identified by identifier. Examples could be:
set of int int_list
set of strings names
set of decimal prices
AfDalSetof referenceAfDalSetof#no representation. It is used as a way to set list of items. Each item is stored according its types.

As types for outgoing data are defined the following (servers view):

Type Definition Mapping into C Mapping into C#
nul Operational responses status. Only contains values to acknowledge operation status and a message explaining current status. AfDalNulData NulData
simple Operational responses status with an integer value. Contains values to acknowledge operation status, a message explaining current status and an integer as operation value. AfDalSimpleData SimpleData
data Operational responses status with a list of items. Contains values to acknowledge operation status, a message explaining current status and a list of items returned by the operation. Currenly there is no way to say a service returns a plain data. It has to be used type command or reference a module name as returning data AfDalData AfDalList
multi Operational responses status with a list of data types. Contains values to acknowledge operation status, a message explaining current status and a list of data types returned by the operation. Currenly there is no way to say a service returns a plain multi. It has to be used type command. AfDalMultiData Currenly no mapping available
node Operational responses status with an Af-Arch datanode (AfDalDataNode (C layer), DataNode (C# layer)). Contains values to acknowledge operation status, a message explaining current status and an Af-Arch node inside the Node attribute. AfDalNodeData NodeData
no stub

No stub generated for the given service. Allow to instruct af-gen that the given service have not client stub.

No mapping done. No mapping done.
string

Operational responses status with an string. It is used for those services which only returns an string value.
NOTE: You not confuse this return type value with the string type as a module or service incoming type. The last one maps to a single string

AfDalStringData StringData

search interface

 Syntax:
     search interface module1 [, module2 [,..]] semicolon
 

Allows to activate search interface to the selected modules. Modules can also be views defininitions. Here is an example:

server interface af-server-name {

        relation rel_a;
        relation rel_b;

        // module a declaration: first item inside the chain
        module module_a (int value_a, string value2_a) implicit definition {
                module_a rel_a module_b with 1..1;
        }

        // module b declaration: second item inside the chain
        module module_b (int value_b, string value2_b) implicit definition {
                module_b rel_a module_a with 0..n;
                module_b rel_b module_c with 1..1;
        }

        // module c declaration: third item inside the chain
        module module_c (int value_c, string value3_c) implicit definition {
                module_c rel_b module_b with 0..n;
        }

        // view declaration
        view module_a_extended from module_a 
                 with module_b (value_b, value2_b), module_c (value_c, value3_c);

        // activate search interface
        search interface module_c, module_a_extended;
}

Search interface generates a service which allows to search elements following a set of criterias exposed by the interface generated.

replace interface

 Syntax:
     replace interface module1 [, module2 [,..]] semicolon
 

Allows to create a replace interface for the given set of modules and views. The replace interface allows to seek a pattern data and replace it with the given data. This is usefull when it is desired to aply a replace operation to a set of data.

sync interface

 Syntax:
     sync interface module1 [, module2 [,..]] semicolon
 

Enable af-gen to also generate synchronous interface to service invocation. Default service invocation inside Af-Arch framework is asynchronous. To enable synchronous interface for a set of modules this command must be used.

Synchronous interface is the same as asynchronous interface by having the preffix _sync for the STUB connector.

When build C# (using --csharp-bindings af-gen option), synchronous interface is activated for all modules. This is done because C# bindings are generated using client STUB synchonous version.

bind as

 Syntax:
     relation-definition bind as attribute-name-binding
 

When a module is relationed through a 1..1 relation, a new implicit attribute appears inside the module definition. In this case the semantic used for the new attribute is module_name + id. In other languages such us C#, this name mapping would be ModuleName + Id .

But, if the same module has two, three or N 1..1 relations with the same module, that sematic makes collition because every implicit attribute is named the same. In this case the bind as sentence is used. Here is an example:

   moduleA relation1 moduleB with 1..1 bind as other_name;
   moduleA relation2 moduleB with 1..1 bind as another_name;

Previous source code will map the first implicit attribute as other_name+ id and the second one as another_name + id.