How to: create a list with both predefined options and free input

Creating the list structure (continued)

To be able to create our list with predefines, we will need to make use of the * AND grammar. Why is this the case?

When the user chooses an option, ClauseBase must enable some text (i.e. the actual plain text containing the CP language) based on this option. These options will be implemented as predefines inside of a list of texts type datafield. This way we can make the text of each bullet (each asterisk in our grammar) conditional on the relevant predefine being selected.

Technically we could reach the same result with the {AND! | … | …} grammar. Further on in this tutorial, however, we will discover why this is not the ideal solution.

Tailoring the subparagraphs with predefines

As mentioned above, we want our end user to be able to select CPs from a predefined list which will be implemented in ClauseBase making use of a “list of texts” type datafield. Create such datafield called conditions-precedent in the concept #loan-agreement.

If you are working in the Assemble Document mode, you don’t have to switch to the Browse Files mode to edit concepts (or other file types). A quicker way to edit a concept is to open it by double clicking on that concept in the list below your clause editor.

We want to assign a predefine for each option, i.e. for each CP. Let’s create three predefines for the conditions-precedent datafield:

  • corporate-docs for the board resolution CP
  • security-docs for the executed security document CP
  • legal-opinion for the final legal opinion CP

Leave only the predefined values can be stored (no free values) unchecked for now.

Having made the predefines, we can continue writing our clause grammar. Each subparagraph should be subject to the condition that the relevant predefine was included in the datafield #loan-agreement^conditions-precedent. In ClauseBase grammar, this looks as follows: {"predefine" in #loan-agreement^conditions-precedent: text that should be shown}.

Note that the grammar for writing conditions is different for the text type datafield and the list of texts type datafield. This is due to the fact that the latter type may contain more than one input, while the text type datafield can only contain one input.

Implementing this for our CP predefines, the grammar will look like this:

1. #Lender's obligations under #┬░loan-agreement are subject to the fulfilment of the following conditions precedent: 


* {"corporate-docs" in #loan-agreement^conditions-precedent: a resolution of the board of directors of #borrower approving the transactions contemplated by #finance-document} 

* {"security-docs" in #loan-agreement^conditions-precedent: certified copies of #security-document, validly executed by #borrower} 

* {"legal-opinion" in #loan-agreement^conditions-precedent: a legal opinion from #borrower's legal counsel confirming that #borrower validly entered into #finance-document and that #finance-document are binding upon #borrower}

Before starting work on the possibility for free input of new CPs, we will be looking at ways of fine-tuning our clause grammar to make sure it will adapt to various different contexts.

Was this article helpful?
How to: create advanced party introduction clauses
How to: make automatically numbered annexes or schedules