good question.
In the situation where you are associating an object instance from another object instance (in this case perhaps from a Note to a NoteType), the default widget Skyve will propose for the view will be a lookupDescription (the drop down in your screenshot). NoteType is a document which may have many attributes - the lookupDescription widget has a descriptionBinding - this is usually set to bizKey but can also be set directly to one of the attributes of NoteType. The bizKey in a document defaults to be the same as the document's singular alias until you set it, resulting in what you see above.
Take for example that NoteType has 3 attributes, an code (text), a typeName (text) and a description (memo).
e.g., Note Types:
| code |
typeName |
description |
| NWS |
news |
a news item for the team |
| ALT |
alert |
an urgent alert |
| COM |
comment |
a general comment |
| RAN |
random |
a fun item not related to work |
- in this case it is not obvious what to show in the drop down or lookupDescription. Perhaps you may want to use the code attribute ("NWS", "ALT" ...) or the typeName attribute (e.g. "news", "alert" ... ) in the drop down, or a mashup of several of the attributes of NoteType like typeName and code (e.g. "NWS (news)", "ALT (alert)" ...).
Whereas in Java you can specify a .toString() method, in Skyve you specify a bizKey - see https://skyvers.github.io/skyve-dev-guide/documents/#bizkey.
For this example, I could specify the NoteType document bizKey attribute like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<document name="NoteType" ...>
<persistent name="NoteType"/>
<singularAlias>Note Type</singularAlias>
<pluralAlias>Note Types</pluralAlias>
<bizKey expression="{code} ({name})" />
<attributes>
<text name="code" >
<displayName>Code</displayName>
<length>3</length>
</text>
<text name="typeName" >
<displayName>Type Name</displayName>
<length>50</length>
</text>
<memo name="description" >
<displayName>Description</displayName>
</memo>
</attributes>
</document>
where bizKey has the expression "{code} ({name})" yielding "NWS (news)", "ALT (alert)" ... this uses Skyve expressions which will be re-evaluated as part of the bean lifecycle and saved as the special database field bizKey.
You can also define the bizKey in Java - for an example of this, check the Contact document (Contact.xml file) in the admin module in your project.
The bizKey attribute is required by Skyve - so when you create a project in Skyve Foundry, the bizKey attribute in the project xml is generated to default to the singular alias (or document name) - in your case "NoteType" to make sure it will have a value.
The bizKey is required by Skyve so that there is always a way for the application to refer to an instance of a document. This is especially important for no-code situations where the developer may not yet have got around to specifying things precisely but wants to be able to start to use the application as a proof of concept.
The bizKey attribute is persisted (saved) in the database for performance reasons - so that Skyve can rapidly retrieve and filter rows based on bizKey values, rather than attempting to calculate them as a derived expression (which would require conversion of expressions or Java code to dialect-specific SQL and also add extra processing every time bizKey values were retrieved).
This means that if you have created data with a different bizKey definition, you'll need to resave your NoteType records. You can do this easily by:
- signing in to your Skyve application as an administrator (or the setup/bootstrap user if you have one)
- navigate to admin->Devops->Data Maintenance and choose the Data Refresh tab
- select the NoteType document, choose the Option "Save" and press "Refresh Persisted Document Data"
For reference:
https://skyvers.github.io/skyve-dev-guide/documents/#documentxml-sections
https://skyvers.github.io/skyve-dev-guide/expressions/
https://skyvers.github.io/skyve-dev-guide/skyve-persistence-mechanisms/