Interacting with Multiple Iteration forms is the most complicated ScriptLink task by far. This is due, in large part, to the data model not being intuitive at first glance and limited documentation. Over the next few weeks, we will be looking specifically at some basic multiple iteration interactions. This week, modifying a value found in an existing row.
There are a number of reasons that you might want to set or change the value of a field in myAvatar: Setting default values dynamically, storing a computed value, or even correcting or appending a value. In my ScriptLink work, I have had each of these use cases. In the previous articles, we looked at how to read field values. Now, let’s set them.
Last week, we read a value from a myAvatar Form and based on that value changed the message returned to the user. This method works well for most myAvatar forms, however, there are additional considerations to make with forms that contain one or more multiple-iteration tables. That’s what we will cover today.
While a “Hello, World!” example may be good for demonstrating how a solution is built, it typically isn’t very useful. This certainly describes our ScriptLink project so far. We can provide the myAvatar user a popup that reads “Hello, World!” and that is about it. For the next few articles, we are going to look at working with the form data from myAvatar. Today, we are going to read a value from a myAvatar form.
Last week, we added NLog to our .NET ScriptLink project to generate debugger log entries. Having NLog now configured and in place we can consider additional targets for the log entries. These targets include: the console, file, mail, databases, and more. Today, we are going to expand our configuration to use a file target, setup filters, and auto-archiving.
Our solutions will often behave unexpectedly. To understand how and why the behavior occurred requires information. Without it we may find ourselves in the position of a reported issue that cannot be understood let alone replicated. This is where logging comes into play. When done well logging can provide the information you need to identify and correct issues without compromising performance.
In my last post, we looked at using interfaces to support the multiple versions of the OptionObject without writing duplicated code. Interfaces are great for creating methods that can consume or return multiple concrete classes such as our OptionObjects. However, in C# at least, you can’t implement any common functionality through interfaces. They are simply contracts that define what the concrete classes are to implement. What if there was a common method that we wanted to extend our OptionObjects with? Welcome abstract classes.
I first started working with myAvatar ScriptLink during the days of the OptionObject (v1). Shortly after, an updated version, OptionObject2, was released with some additional valuable properties. I completely missed the announcement of this version and didn’t stumble on it until well after the OptionObject2015 version was released. So I was using OptionObject in production, but I wanted to upgrade to a newer release without writing duplicate code. Inheritance became my solution and a foundation of the design of the AvatarScriptLink.NET library.
We solve problems every day. We have ideas and a desire to make things better. The solutions we create may seem mundane or even profound. They may not support monetization, contribute to a corporation’s bottom line, or raise a society’s GDP, yet that doesn’t reduce its value or significance.
Congratulations! You have created your “Hello, World!” ScriptLink web application, tested it with Unit Tests, tested it on your development web server, and submitted your code to a source control solution. Next, we will be looking at various methods for deploying our .NET ScriptLink applications. This will enable us to setup our Test server to use with UAT or other myAvatar Test environment and later the Production server to use with our LIVE or other production myAvatar environment.