Packaging should be an important consideration when developing. There are some small tips you can follow which can save you a ton of hassle when you’re attempting to move your custom development. I’ve gone over some of the basics in my first blog post, and my second blog post on the topic covers ways to avoid issues when adding to existing ItemTypes. In this blog, I’ll be going over some packaging tips related to forms.
Form Basics
Forms are commonly used to interface with a linked ItemType, but can be created without linking to an ItemType. This can be useful for creating dialogs which are shown to the client during an action or client-side method. Here's a blog we've written which goes over utilizing forms for dialogs. Forms are related to ItemTypes via the “Views” relationship. Here you can relate one or multiple forms to a single ItemType, and they’ll be displayed when looking at the form. If two forms share the same type, the one with lower Display Priority will be displayed.
You can define forms for specific item classifications, which allows you to keep only relevant information available on the form.
Modifying the Form
For this example, following our last packaging guide, we’ll be modifying the part form. This is something that is central to many modifications I’ve seen. It’s also part of a core package, so we’ll go over some of the challenges related to packaging custom forms for standard ItemTypes.
As mentioned previously, there are multiple approaches to packaging modifications to a form. You could edit and package the fields, but that can get overwhelming quick. The method I’ve had the most success with is also quite simple. We’re going to create a copy of the existing form, make our changes to that, and then attach it to the ItemType with a higher display priority. This allows us to export both our form and view, and when we attempt to import it into the new instance, there will be no conflicts.
In our previous blog post [Link] we added an “Example” property on the part ItemType. To ensure people can interact with and provide a value for this property, we’ll add it to the part form!
To start this process, we’re going to find our Part Form on the main search grid, and create a copy of it like the image below.
Once we’ve done this, we’ll have an exact copy of our original form we can work with. Now go ahead and make any modifications you’d like to your new form. I’m going to add a box to add a value for the new example property. Once you’ve made your changes, go ahead and attach it to the Part ItemType through the Views relationship.
Make sure your new form is attached through the View relationships and has a higher display priority than the default. Once you’ve verified your new form is the default, we’re ready to package! We’re going to be making use of the "CUI Add to Package" Community Project. Since the ItemType already exists in every instance, we’ll end up packaging the relationship between the ItemType and the form, as well as our new form. This will import cleanly on any instance, and always leaves the option to revert the form if necessary. It’s important to note that you need to package the View and the Form. The form can be packaged by right clicking it directly on the main grid and adding to a package. The View needs to be packaged from the relationship tab, using the button shown in the screenshot below.
Once you’ve added both components to a package, export from one instance and import into another. The steps for export/import can be found in this blog.
Conclusion
This is one of many ways which you can package your changes. Like mentioned previously, creating a copy of the form and editing it is an easy way to make your changes and make sure they can be transported easily. If you have any suggestions for packaging topics to cover please let us know. If you have a different way you approach this, let us know about that too! We’re always interested in hearing interesting ways people are approaching package management.