Document Production

Originally published at:

I have a question about the ‘collections’ you create that basically define a layout segment.
For example, take the Demo 3 method:
I understand the idea of retrieving the forms into $u, $h, $v, $f

$u:= getFormObject (“single”)
$h:= getFormObject (“2x horizontal”)
$v:= getFormObject (“2x vertical”)
$f:= getFormObject (“4x logo”)

and then you create $a $b $c $d which are collections that basically define the corresponding layouts
$a:= New collection ($v;$u;$u) // a “2xV” + single + single
$b:= New collection ($u;$u;$v) // a single + single + 2xV
$c:= New collection ($h;$u;$u) // a 2xH + single + single
$d:= New collection ($u;$u;$h) // a single + single + 2xV

then compose the document:
. add (Layout large;$f). add (Layout double and two singles;$a)
. add (Layout two singles and a double;$b). add (Layout double and two singles;$a)
. add (Layout double on two singles;$c). add (Layout two singles on a double;$d)
. add (Layout double on a double;$h). add (Layout double double;$v)
. add (Layout double and two singles;$a). add (Layout double on a double;$h)
. add (Layout double double;$v). add (Layout large;$f; True )

I understand the idea, but I don’t see where the ;$f, ;$a, ;$b … gets used in the execution.
In your code it seems to just be an ignored parameter. Instead, each of the layout styles have built-in controls that cause the form to be composed using those stylistic layouts (single, 2xh, etc).
Am I missing something when following the code’s execution?
I do not see where the collections of ‘layouts’ ever gets involved in controlling the layout process.

I am examining your coding for your style too; interesting exploitation of the formulas! Thanks.
– Chris

The one-letter local variable is an object or a collection of objects.

Each object is a JSON form.

When passed as parameter to the method add() (in $2), you will see that they are received as C_VARIANT, because the type could be either an object or a collection.

When you trace the project method addForm (which is the formula corresponding to the method add()), you should see that it gets passed to printFormInForm.

Inside that method, you will see that $2 is processed to retrieve the JSON form’s contents.

Case of 
: (Value type($2)=Is object)
: (Value type($2)=Is collection)
End case 

Thank you for responding.
I did the trace but did not discern the subtlety of the handling of the ‘collection’ of pages. It makes sense now that you point it out.
The part that tricked me is that I needed to realize that $a, $b, $c, $d are collections of OBJECTS (i.e. FORMS). For some reason my brain missed that subtlety.
The approach you took to coding this example is fascinating (i.e. extensive use of formulas, and so on). It would translate best as a CLASS in v18r3 on; it would be instructive if it was reworked as an example of how to use the CLASS feature in v18r3.
You did an ingenious job of basically creating class structure with functions and without that new 4D feature.

In the absence of CLASS, I made myself a custom GUI system to define the data structure of CLASSes and INSTANCES (which can be stored in a single 4D table and/or loaded into Storage). I used it to define custom menu system, 4D lists (orda-based too), contextual menus, and the like. I am intrigued with the possibility of leveraging this little GUI into a tool for defining true 4D CLASSes in the future. But I need to wait a bit and see how 4D’s implementation takes shape.
I bring that up because trying to understand your coding methodology sheds light on how it could be done more effectively. Thanks for your well-thought-out example.

Quelle est la bonne méthode pour ouvrir une base projet en V18.2
Faut il aller dans le dossier project et sélectionner un fichier en .4DProject
ex pour cette base démo : v18-document-production.4DProject ?
(Ou trouve t on cette information dans le Doc Center)

or, just drag and drop.

Pour utiliser la notation objet en V18.2 nous devons revoir le nommage des champs et tables.
Il faut supprimer les espaces (blancs)
Faut il aussi supprimer l’accentuation des noms ?

I think not.

My customers go one step further, they use Japanese for table and fields, but they seem to work OK in ORDA, at least in native 4D code.

As for spaces, sometimes you can get away with bracket notation, but it gets difficult for methods that expect property path in string.

However, some JavaScript parsers may choke on non-ASCII.

Nous posons la question de l’accentuation car dans le Menu Développement/Structure l’inspecteur de champs indique pour les champs accentués, dans la rubrique SQL : [!] Caractère non autorisé pour un identifiant SQL
Des instructions 4D utilisent elles SQL ? (Jointure,…)

Usage of SQL in 4D is optional.

You can also escape table names in 4D SQL code, so the warning in structure editor does not necessarily mean that your table or field is inaccessible via SQL.

However, external SQL software (Excel, Access, etc.) may not be so understanding and throw errors.

Merci pour cette information précise