Chasing The Naming Bug Through 4 Templates
I made a large change to my Hackathon app and had to expand the Communications functions from a simple Message to 4 x Templates with 2 choices for the User.
- Main template: Contact
- Secondary template with 2 Non-consuming Choices: Message
- Tertiary template #1: ShortMessage
- Tertiary template #2: LongMessage
I thought it would be helpful to change every sender, receiver, notes to reflect each Template. For the Contact Template, that would be contactSender contactReceiver, contactNotes.
However this seemed to cause conflict when referring to the Parties from one Template in the next template, in the previous template. So, I changed them all back to sender, receiver, notes and predictably are getting references to Ambiguous occurrence ‘sender’
Current conflicting version
{--
import Daml.Script
import DA.Time()
import DA.Date (Month(Apr), date)
--}
{--
| Contact application, might split out
| into it's own module, called Contact.daml
| 4 parts:
|
| Contact; Message; ShortMessage; LongMessage
--}
-- Contact Data Type & Template
--
type ContactId = ContractId Contact
template Contact
with
contactSender : Party
contactReceiver : Party
contactContent : Text
where
signatory contactSender
nonconsuming choice SendMessage : ContractId Message
with
userName : Party
content : Text
controller contactSender
do create Message with
messageSender = userName
messageReceiver = contactReceiver
messageContent = content
-- Message Data Type & Template
--
type MessageId = ContractId Message
template Message
with
messageSender : Party
messageReceiver : Party
messageContent : Text
where
signatory messageSender
observer messageReceiver
nonconsuming choice SendShort : ShortMessageId
controller messageReceiver
do shortContent
create ShortMessage with
shortSender
shortReceiver
shortContent
nonconsuming choice SendLong : LongMessageId
controller messageReceiver
do longContent
create LongMessage with
longSender
longReceiver
longContent
-- ShortMessage Data Type & Template
--
type ShortMessageId = ContractId ShortMessage
template ShortMessage
with
shortSender : Party
shortReceiver : Party
shortContent : Text
where
signatory shortSender, shortReceiver
-- Data Record for LongMessage
--
data LongMessageForm = LongMessageForm -- Detailed contact
with
covid19Vaccinated : Bool -- Currently COVID19 vaccine
patientName : Text -- First Last
patientNew : Bool -- New registration
patientCode : Int -- Next sequential number
patientGender : Text -- Male, Female, Other
patientType : Int -- NZ_Citizen, NZ_Resident, Other
dateOfContact : Date -- Date of consultation
extratNotes : Text -- Additional details, concise
deriving (Eq, Show)
-- LongMessage Data Type & Template
--
type LongMessageId = ContractId LongMessage
template LongMessage
with
longSender : Party
longReceiver : Party
longContent : LongMessageForm
where
signatory longSender, longReceiver
I was able to get the errors down to 1 instance of sender but I think I have a Logic/reference issue.
Not sure if I understand fully what you want to achieve, but Message does not have a sender in the snippet you pasted, it has a messageSender. You either have the party named sender on Message or just be more explicit like in Contact’s SendMessage sender = messageSender.
Thanks @Mate_Varga
Fixed it!
The logic flow was too complex and redundant.
So rm -f message_function then added the Choices & Data Record Types in front of a normal Message-type Template.
I am trying to make made a Message function where a User can send one of two messages types, based on selecting a Choice in the Template:
ShortMessage
Sender : Party
Receiver : Party
Message : Text
LongMessage
Sender : Party
Receiver : Party
Message : LongMessage
covid19Vaccinated : Bool -- Currently COVID19 vaccinated
patientName : Text -- First Last
patientNew : Bool -- New registration
patientCode : Int -- Next sequential number
patientGender : Text -- Male, Female, Other
patientType : Int -- NZ_Citizen, NZ_Resident, Other
dateOfContact : Date -- Date of consultation
extratNotes : Text -- Additional details, concise
The UI rendering looks fugly, there are two repetitive fields but it works. This would make the beginnings of a User Contact Management smart contract.
… oh the potential 
I had seen those examples before and have not made the connection, until now.
