Tabular Interface for Building Simple Domino Form and View

[JoelProminic]

In #646, we have been working on updating the Visual Editor to build a Domino form. However, in the general use case, the user doesn't really care about the specific layout - they just want to quickly populate the form with list of fields, and then create a corresponding view to populate these documents. We would like to create form to populate this form and view.

This form would be available for On Disk Projects. We have been working on an On Disk Project template for #646, but this will need to be separated out from the Visual Editor code. The Form and View will be generated into DXL (Domino XML) format, and then the code in the On Disk Project can handle importing them into a Domino database.

The new form should have the following inputs:

• Form Name
• View Name
• Web Accessible? (a checkbox). If the user does not intend for the form or view to be accessed directly from the web, we should add some settings to restrict this
• A list of Fields
• NOTE: there are many more options we could include here, but I want to keep this simple for now

The field list should be a datagrid or a list that is populated with a subform. The user should be able to order this list as they prefer, and it will determine the order of the fields in the form and view. Here are the options I expect us to provide for each field:

Option	Required	Notes
Name	Yes	The name of the label. Alphanumeric and underscores only. Must be unique
Label	No	A label to display for the field. Let the user leave it blank to default to the Name
Description	No	A longer description to display for the field
Type	Combobox	The type of the field: text (default), richtext, number, datetime (and more in the future)
Multivalue	Checkbox	Determine whether this is a multivalue field. Applicable for all types except richtext
Editable	Combobox	Determine whether the field editable or computed. Possible values: editable, computed, compute on compose, compute for display. The field should be editable by default. UPDATE: only "editable" and "computed" are available for richtext fields in Domino Designer
Formula	For non-editable fields only	A default value or computed value written in the Domino formula language
Include in View	Checkbox	Whether this field should be included in the view
Sort options	Combobox	Control if this field is sorted and/or categorized. Options: No sorting, Ascending, Descending, Categorized (Ascending), Categorized (Descending)

Here are additional fields that we will want to support in the future. I think we can exclude them from the initial version to simplify the interface.

Option	Required	Notes
Advanced Control	No	Make this field an advanced control (i.e. a checkbox group, combobox, or radio button)
Value Selection	For advanced controls only	A colon-separated string list, or a Domino formula. Use a '|' to define a display and actual value (i.e. "display | value").

The form should then be generated as a table with three columns:

• Label
• Field
• Description

The generated form and view should also have reasonable shared actions applied from the On Disk Project template.

We will create an example of forms and views in Domino and provide screenshots and example DXL files.

EDIT: Another feature that we should consider for this is the ability to convert an unmodified form and view generated from this tool back into the original parameters, so that it can be edited and regenerated. If there are user modifications, they would be lost when converting back, if we could even parse them correctly. This doesn't need to be a feature with the initial release, but we should start thinking about how we could convert back when building the DXL output.

EDIT: Here is an explanation of how the Sort Option value converts to DXL attributes:

Sort Option	sort	categorized
No sorting	none	false
Ascending	ascending	false
Descending	descending	false
Categorized (Ascending)	ascending	true
Categorized (Descending)	descending	true

[JoelProminic]

Here is a mockup to clarify what is expected for the interface:

If you want to update the mockup to suggest modifications, here is the mockup file:
2020_03_04__NotesFormBuilder.bmml.zip

[JustinProminic]

@JoelProminic please be sure that the table of field rows that the user adds can be edited again to add more fields, or edit existing fields. it would then one-way export the results to the ODP. No round-tripping is needed, but we do want to make sure that the table is basically just a visual representation of some XML that defines it.

[JustinProminic]

@JoelProminic I suggest we build a Domino database that we can export to XML which defines the rules for mapping the fields into DXL. This way, the information is not hard-coded. We could then publish to XML the results of our database for embedding into Moonshine, OR we could actually have Moonshine retrieve dynamically the conversion process so that we can fine tune it on the server side without having to push out new Moonshine IDE releases each time we want to fix or enhance the DXL generation.

[JustinProminic]

@JoelProminic I do think we are going to need to add support for computed field options, and we need a CDATA tag around them so that the user can enter in whichever optional language they want for these -- probably @function most of the time, but possibly in some cases LotusScript, or SSJS (server side java script) for XPages centric users. We don't need to do anything fancy - just add a multi-line text input and then whatever the user enters gets wrapped into CDATA and put into the DXL. If there are errors with it, then the DXL build will simply fail.

[Aszusz]

@JustinProminic

I suggest we build a Domino database that we can export to XML which defines the rules for mapping the fields into DXL

Do you mean xml schema?

[JoelProminic]

I discussed the DXL mappings with @JustinProminic and @dpastov.

We want to define a DXL template for fields with each valid combination of the below options:

• Type: Text, Number, DateTime, RichText
• Multivalue: true, false
• Editable/Computed: Editable, Computed, Computed For Display, Computed on Compose

The template should have basic insertion parameters like:

• %FieldName% - the name/ID of the field
• %ComputedValue% - the computed text/formula, or default field value.

We'll build a database of the different templates, and return it to Moonshine in a configuration file or by a URL.

[JoelProminic]

@JoelProminic please be sure that the table of field rows that the user adds can be edited again to add more fields, or edit existing fields. it would then one-way export the results to the ODP. No round-tripping is needed, but we do want to make sure that the table is basically just a visual representation of some XML that defines it.

To clarify this idea, the information from the Moonshine form (at the top of my mockup above) should be saved as an XML structure representing the Form and Field properties, in addition to the generated DXL form. Then, the user should be able to open the Mooonshine form again using that XML configuration, make modifications, and then generate the form again.

We want to do it this way instead of trying to open the generated DXL directly. The user may choose to update the form in Domino Designer to improve the format, and even minor changes could make the DXL unreadable for editing with the above Moonshine table. This option will overwrite any changes made to the form in Designer (or the DXL), but it will be available in case the user feels it will be easier to update the DXL and Domino Form from our interface rather than using Domino Designer.

I don't have strict requirements format for this XML file, but we should try to design it so that we can safely add addition form and field properties later.

[JoelProminic]

@dpastov has built a database of DXL mappings for the fields in this database (not accessible to everyone - this is for my reference):

Server: domino-1.dmytro.cloud/DmytroDev
Database: A55F0D/DXLTemplates.nsf

Next, we'll need to generate a configuration file based on this that will let Moonshine lookup the DXL by the field type, multivalue, and editable/computed properties. We'll also need to given an example (or configure) a wrapper table.

Currently, the database uses formatted DXL (i.e. ). The ODP (#669) uses the raw note DXL instead (). @feather812002 and I noticed some trouble when using the formatted DXL, but we'll need to investigate if some other factor caused the problem.

[JoelProminic]

@dpastov will be helping with the DXL side.

To summarize the plan for this:

1. The user will populate a list of fields they want to include in a Flex form. They will define additional settings for the fields
2. On submission Moonshine will generate an XML file representing the user's selections. This file can be used to reopen the form
3. Moonshine will also generate a DXL file defines the Domino form.

@rat-moonshine and @piotrzarzycki21 can build the Flex interface and generate the XML file, but they don't know the DXL format. To populate this, they need an XML file that maps the different field types to a DXL template. The DXL templates should be looked up by these properties:

• Type
• Multivalue
• Editable

In addition, they'll need guidance for building the surrounding elements of the form. The form should be a simple three-column table showing the Label, generated field, and Description. We'll need templates for these elements:

• The header
• The Label and Description text
• The table
• The table row and cells (so that we can add an arbitrary number of additional rows).

The templates could be configured in a simple XML file, initially. We also want to consider getting the XML from a simple agent, so that we can update the UI look and feel without pushing a new release of Moonshine.

I updated #669 with some instructions to build an On Disk Project from Moonshine.

[piotrzarzycki21]

1. The user will populate a list of fields they want to include in a Flex form. They will define additional settings for the fields

What kind of fields should be presented initially ?

[piotrzarzycki21]

I discussed the DXL mappings with @JustinProminic and @dpastov.

We want to define a DXL template for fields with each valid combination of the below options:

• Type: Text, Number, DateTime, RichText
• Multivalue: true, false
• Editable/Computed: Editable, Computed, Computed For Display, Computed on Compose

The template should have basic insertion parameters like:

• %FieldName% - the name/ID of the field
• %ComputedValue% - the computed text/formula, or default field value.

We'll build a database of the different templates, and return it to Moonshine in a configuration file or by a URL.

This is the initial list ?

[JoelProminic]

No, I defined a list of the required field and form properties for the UI in the original description. I just edited it to move a couple field properties to the Required section.

The DXL lookup will be by Type, Multivalue, and Editable/Computed. Name and Formula (%FieldName% and %ComputedValue% in my comment) will be insertion parameters in the Field DXL. Label and Description will be used when generating the table row. Include in View and Sort Options are used for generating the view.

[piotrzarzycki21]

Thanks @JoelProminic . @rat-moonshine I have to ask you to start looking into that issue instead of me. I may not be enough active in the next 2 days as I wanted to, maybe you will get something done for that. I believe you may be more efficient in cooperation with Bing.

I think you should use his branches when you reach the point of conversion to DXL. I would use in MockupVisualEditor his branch https://github.com/prominic/MockupVisualEditor/tree/features/issue_646_ve_notes_domino_support and in VisualEditorConverterLib. We in theory should use part which he implemented to create those Forms. I will assist you in checking the code and coordinates anything. I'm sorry for this one.

[rat-moonshine]

I think you should use his branches when you reach the point of conversion to DXL. I would use in MockupVisualEditor his branch https://github.com/prominic/MockupVisualEditor/tree/features/issue_646_ve_notes_domino_support and in VisualEditorConverterLib. We in theory should use part which he implemented to create those Forms. I will assist you in checking the code and coordinates anything. I'm sorry for this one.

[Edited]
I shall need to look into the implementation into https://github.com/prominic/MockupVisualEditor/tree/features/issue_646_ve_notes_domino_support and VisualEditorConverterLib to support #646 and how they can contribute to this new tabular-interface needs.

We still need a plan to blend #646 stuff into #669 . Perhaps we can implement this into #669 branch (or a sub-branch of it) using the https://github.com/prominic/MockupVisualEditor/tree/features/issue_646_ve_notes_domino_support and https://github.com/prominic/VisualEditorConverterLib/tree/features/issue_646_ve_notes_domino_support, and when #669 already has particular type of file-extension (.dfb) management etc. What do you think?

Furthermore, what sort of initial support you want me to put in for this first stage. i.e. creating interfaces based on needs, initial object structuring etc. ? I'll be glad to help, anyway.

[JoelProminic]

To help further illustrate the design that @JustinProminic and I described, I created a basic template using the #646 build. The insertion parameters have the format "%Identifier%".

In HCL Notes:

The form template looks like this. The note and noteinfo attributes are probably populated by the On Disk Project code, so we'll need to clean these up for the actual template:

<?xml version="1.0" encoding="utf-8"?>
<note class="form" version="9.0" maintenanceversion="1.4" replicaid="4825808B00336E81" xmlns="http://www.lotus.com/dxl">
  <noteinfo noteid="2116" unid="27C118EDE31483CB86256C6900644875" sequence="8">
    <created>
      <datetime>Wed Apr 8 12:30:37 GMT-0500 2020</datetime>
    </created>
    
    <modified>
      <datetime>Wed Apr 8 12:30:37 GMT-0500 2020</datetime>
    </modified>
    
    <revised dst="true">
      <datetime>Wed Apr 8 12:30:37 GMT-0500 2020</datetime>
    </revised>
    <lastaccessed>
      <datetime>Wed Apr 8 12:30:37 GMT-0500 2020</datetime>
    </lastaccessed>
    <lastaccessed>
      <datetime>Wed Apr 8 12:30:37 GMT-0500 2020</datetime>
    </lastaccessed>
    <addedtofile>
      <datetime>Wed Apr 8 12:30:37 GMT-0500 2020</datetime>
    </addedtofile>
  </noteinfo>
  <item name="$Info" sign="true">
    <rawitemdata type="1">hhgBAIAAAAAAgAAAAQABAP///wAQAAAA</rawitemdata>
  </item>
  <item name="$Flags">
    <text/>
  </item>
  <item name="$TITLE">
    <text>%FormName%</text>
  </item>
  <item name="$Fields">
    <textlist>
      <text>FieldName</text>
    </textlist>
  </item>
  <item name="$Body" sign="true">
    <richtext style="width:700px;height:700px;" class="flexHorizontalLayoutWrap flexHorizontalLayoutLeft flexHorizontalLayoutTop">
      <pardef id="0" align="left"/>
      <par def="0" class="flexHorizontalLayout flexHorizontalLayoutLeft flexHorizontalLayoutTop">
        <run>
          %FormName%
          <font/>
        </run>
      </par>
      <table>
        <tablecolumn/>
        <tablecolumn/>
        <tablecolumn/>
        <tablerow>
          <tablecell>
            <par>
              <run>
                Field
                <font/>
              </run>
            </par>
          </tablecell>
          <tablecell>
            <par>
              <run>
                Value
                <font/>
              </run>
            </par>
          </tablecell>
          <tablecell>
            <par>
              <run>
                Description
                <font/>
              </run>
            </par>
          </tablecell>
        </tablerow>
        %InsertRowsHere%
        <tablerow>
          <tablecell>
            <par>
              <run>
                %Label%
                <font/>
              </run>
            </par>
          </tablecell>
          <tablecell>
            <par>
              <field value="%ComputedValue%" type="text" kind="editable" width="100" height="30" bgcolor="#ffffff" name="FieldName"/>
            </par>
          </tablecell>
          <tablecell>
            <par>
              <run>
                %Description%
                <font/>
              </run>
            </par>
          </tablecell>
        </tablerow>
      </table>
    </richtext>
  </item>
  <item name="FieldName" summary="false" sign="true">
    <text>FieldName</text>
  </item>
</note>

The rows (%InsertRowsHere%) would then have their own template:

        <tablerow>
          <tablecell>
            <par>
              <run>
                %Label%
                <font/>
              </run>
            </par>
          </tablecell>
          <tablecell>
            <par>
              %InsertFieldHere%
            </par>
          </tablecell>
          <tablecell>
            <par>
              <run>
                %Description%
                <font/>
              </run>
            </par>
          </tablecell>
        </tablerow>

And then the field (%InsertFieldHere%) would be looked up from an XML file/agent provided by @dpastov. Each template might look something like this:

              <field value="%ComputedValue%" type="text" kind="%Editable%" width="100" height="30" bgcolor="#ffffff" name="%FieldName%"/>

[rat-moonshine]

• Open mechanism of a new view in MockupVisualEditor, from Moonshine (working.. @rat-moonshine )
• Constructing new UI in MockupVisualEditor in details (working.. @rat-moonshine )
• Constructing code structure to manage objects related to the new tabular interface in MockupVisualEditor (working.. @rat-moonshine )
• Saving and retreiving of local XML describes the tabular interface view (Moonshine involvement) (@rat-moonshine )
• Saving as DXL (Working.. @rat-moonshine )

[rat-moonshine]

This issue is now now merged into 'master'. Following repositories are in effect:

• Moonshine-IDE
• MockupVisualEditor
• VisualEditorConverterLib

[piotrzarzycki21]

Did you have any conflicts?

[rat-moonshine]

No.

[piotrzarzycki21]

@rat-moonshine Did you build and update VisualEditor and all the libs which are required to be updated ? I have now when I'm trying to build Moonshine.

Error:(26, 69) [MoonshineSharedCore]: Type was not found or was not a compile-time constant: TabularInterfaceEditorWrapper.

[rat-moonshine]

I mainly updated the branches to build correctly on Bamboo. I re-updated the local SWCs now. Please, give a test.

[piotrzarzycki21]

I mainly updated the branches to build correctly on Bamboo. I re-updated the local SWCs now. Please, give a test.

I have tried today and I'm not able build Moonshine. I have same error as above.

[piotrzarzycki21]

I have resolved issue. If I broke something let me know.

[rat-moonshine]

I have resolved issue. If I broke something let me know.

This probably a leftover, thanks for the removal. I see Bamboo build without a problem so the change shouldn't cause any trouble.

[piotrzarzycki21]

Moving this for next release. No announcement in CHANGELOG

[rat-moonshine]

Moving this for next release. No announcement in CHANGELOG

This also same as #669 and included in 'master', so it doesn't make sense to push back to v3.1.0 unless we have a problem that needs some time to address. Justin also suggested pushing these features in v3.0.

[piotrzarzycki21]

@rat-moonshine Same story as I commented here -> #669 (comment)