The PHP code generator is a plug-out directly written in C++.
The generated sources follows the definition made in BOUML at the artifact / class / operation / relation / attribute / extra member levels.
When the code generation is applied on a artifact associated to several classes, the code generation is made for all these classes. Nevertheless the the Php code generator produce first the code in memory and update the appropriate files only when it is necessary, to not change the last write date of the files for nothing. Depending on the toggle verbose code generation of the global menu Languages the code generator is verbose or not.
The Php code generator plug-out may be called on :
a class : in this case the code generation is in fact applied on the class's artifact, then on all the classes associated to this artifact
a artifact : in this case the code generation is in fact applied on all the classes associated to the artifact
a class view : the code generation will be applied on all the sub classes, then on all the artifacts associated to these classes
a deployment view : the code generation is applied on all the sub artifacts
a package (may be the project itself) : the code generation will be applied on all the sub class views and deployment views, then on all their sub classes and artifacts.
When the Php code generator is ask through the Tools menu, it is applied on the project, then on all the artifacts.
The name of the generated files depend on the artifact name, the extension depend on the language and is fixed for each by the generations settings (see below), the directory where the files are generated may be set in each package containing directly or indirectly the artifact (see generation directory).
The Php definition of a artifact is set through the Php source tabs of the artifact dialog.
The code generation depend on the stereotype of the artifact :
text : the Php definition of the artifact is produced without changes, the name of the generated file is the name of the artifact, including the extension.
source : see below.
else nothing is generated for the artifact.
The generated file name is the artifact's name with the extension specified in the first Php tab of the generations settings :
There are four ways to produce the require_once forms
without path : ask for the Php code generator to generate them without relative or absolute path
with absolute path : ask for the Php code generator to generate the absolute path of the automatically required files.
with relative path : ask for the Php code generator to generate the relative path of the automatically required files, warning : relatively to the file containing the require_once
with root relative path : ask for the Php code generator to generate the relative path of the automatically required files, relative to the directory specified by the generation settings (it is probably indicated in Php include_path)
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the Php code generator are :
${NAME} produce the artifact name capitalized, ${Name} produce the artifact name with the first letter capitalized, ${nAME} produce the artifact name forced in lowercase, at least ${name} produce the artifact name without modification.
${comment} is replaced by the artifact description adding /* */
${description} is replaced by the artifact description without adding /* */
${namespace} is replaced by the namespace xx; dependent on the namespace specifications associated to the package containing the deployment view where the artifact is defined.
${require_once} is replaced by the require_once forms for the files associated to the classes referenced by the ones produced by the artifact. It is also a good place to add your required_once forms, when the ones produced by the code generator are not sufficient. The Php code generator does not look at in the operations body, only the operation's profiles, relations and attributes, classes inheritances etc ... are used to compute the needed require_once list.
${definition} is replaced by the definition of the classes and extra artifact definitions associated to the artifact.
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the artifact, if not found for the deployment view containing the artifact, if not found in the package containing the deployment view etc ...
The Php definition of a class is set through the Uml, Parametrized, Instantiate and Php tabs of the class dialog.
A Php type definition may be a class, an interface or an enum defined through a class, depending on the stereotype and its translation in Php (see generation settings).
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the Php code generator are :
${comment} is replaced by the description of the class adding /* */
${description} is replaced by the class description without adding /* */
${final} produce final when the class is declared final
${abstract} produce abstract when the class is abstract
${name} is replaced by the class's name
${extend} is replaced by the class inheritance
${implement} is replaced by the interface inheritance
${members} is replaced by the code generated for all the class's members (relations, attributes, operations and extra members) following the browser order.
${items} produces the enumeration items of an enum. other members are not produced
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the class, if not found for the container of the class (an other class of a class view) etc ...
In the special case where the class is declared external, its Php type declaration must contains a line indicating how the name of the class is generated, by default ${name} meaning that the name is produced unchanged, the only allowed keywords are ${name}, ${Name} and ${NAME}.An optional second line may be given to specify the require_once form to produce in artifact containing classes referencing this external class.
The Php definition of an operation is set through the Uml and Php tabs of the operation dialog.
The indentation of the first line of the declaration/definition give the indentation added to the class definition for all the operation definition.
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the Php code generator are :
${comment} is replaced by the description of the operation adding /* */
${description} is replaced by the operation description without adding /* */
${visibility} produce the visibility (see the UML tab), except if the visibility is package (use this case to produce Php4 code)
${static} produce static when the operation is a class operation (see the UML tab)
${final} produce an empty string when the check box final is not checked, else produce final
${abstract} produce abstract when the operation is abstract (see the UML tab)
${name} is replaced by the name of the operation.
${type} is replaced by the returned value type (see the UML tab)
${multiplicity} is replaced by the multiplicity of the return type (see the UML tab), a priori used in a comment
${(} and ${)} produce ( and ), but there are also a mark for BOUML to find the parameters list
${t<n>}, ${p<n>} and ${v<n>} produce the type, name and default value of each parameter (count from 0), this allows you to remove a parameter, etc ...
${m<n>} produce the multiplicity of each parameter (count from 0), a priori used in a comment
${staticnl} produce a line break when the operation is static, else an empty string. In case you do not like this notation, change the generation settings to remove this macro.
${body} is replaced by the body of the operation, this macro may also be replaced by the body itself (BOUML use this way for the get and set operations associated to a relation/attribute). The usage of ${body} has a great advantage : when you hit Default definition the body is not cleared ! At least BOUML share the definition forms of the operations (and other objects) to minimize the needed memory size, ${body} help for this ! The indentation of the keyword ${body} is added at the beginning of each line.
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the operation, if not found for the class containing the operation etc ...If the toggle preserve operations's body is set through the Languages menu, the generators do not modify the body of the operations protected by dedicated delimiters. This means that for them the body definition set through BOUML is not used. The first time you generate the code with the toggle set, because the delimiters are not yet present in the generated code, the operation's body will be updated depending on their definition under BOUML. After, while the toggle is set and the delimiters present, the bodies will not change, allowing you to modify them out of BOUML.
Notes :
In case the file containing a body definition is not consistent with the artifact under BOUML, the body will be regenerated by the code generation, using its definition under the model.
When you import a project, the body of the imported operations must be the right one in the imported model. The preserved bodies of the imported operations will not be find because the identifier of an operation used to mark its body changes during the import.
The bodies under the model are not updated by the code generation, use roundtrip body for that
Only the operations using the keyword ${body} may have a preserved body.
The only modification you can do in the lines containing the delimiters is the indent.
The toggle is saved in the file associated to the project, be sure the save is done when you change this toggle !
The Php definition of an attribute is set through the Uml and Php tabs of the attribute dialog.
The indentation of the first line of the definition give the indentation added to the class definition for all the attribute definition.
An attribute may be a standard attribute or the item of an enumeration defined through a class.
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the Php code generator are :
${comment} is replaced by the description of the attribute adding /* */
${description} is replaced by the attribute description without adding /* */
${visibility} produce the visibility (see the UML tab), except if the visibility is package (use this case to produce Php4 code)
${static} produce static when the attribute is a class attribute (see the UML tab)
${const} produce const when the attribute is read only (see the UML tab)
${var} produce var when the relation is not read only nor static(see the UML tab) and the visibility is not package, else produce an empty string
${name} is replaced by the attribute's name (see the UML tab)
${value} is replaced by the initial value of the attribute (see the UML tab)
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the attribute, if not found for the class containing the attribute etc ...
The Php definition of a relation is set through the Uml and Php tabs of the relation dialog.
The indentation of the first line of the definition give the indentation added to the class definition for all the relation definition.
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the Php code generator are :
${comment} is replaced by the description of the attribute adding /* */
${description} is replaced by the attribute description without adding /* */
${visibility} produce the visibility (see the UML tab), except if the visibility is package (use this case to produce Php4 code)
${static} produce static when the attribute is a class attribute (see the UML tab)
${const} produce const when the attribute is read only (see the UML tab)
${var} produce var when the relation is not read only nor static(see the UML tab) and the visibility is not package, else produce an empty string
${name} is replaced by the role's name (see the UML tab)
${inverse_name} is replaced by the name of the inverse role (see the UML tab)
${value} is replaced by the initial value of the relation (see the UML tab)
${stereotype} is replaced by the translation in Php of the relation's stereotype (see the UML tab)
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the relation, if not found for the class containing the relation etc ...
The class inheritance are managed at the class level.
${type} is replaced by the name of the inherited class/interface may be with with namespace.
In that special case the forms use are produced from the keyword ${member} at the class level.
When ${type} is alone in the definition, it is replaced by two spaces then use then a space then the name of the inherited trait may be with namespace then a ';' then a newline.
Else ${type} is just replaced by the name of the inherited trait may be with namespace, of course the other characters presents in the definition are also produced, and in case the last character of the definition is a comma a new line is not generated allowing you to use several traits on the same line. The best way to see how to model complex cases is probably to use the reverse and to see what it did.
The Php definition of an extra member is set through the Php tabs of the extra member dialog.
No macros.
Previous : Java catalog
Next : Php reverse