SyteLine IFS Framework Development Guide

IFS Form Architecture and Lifecycle

Every SyteLine form follows a defined lifecycle: initialization, data binding, user interaction, and disposal. During initialization, the form loads its layout XML, instantiates components, and establishes IDO connections. The binding phase populates components with data from the IDO layer.

Understanding this lifecycle is critical because many customization issues stem from executing code at the wrong lifecycle stage, for example, trying to access data before binding completes or modifying components after they are disposed.

• Hook into the correct lifecycle event: use InitializeForm for layout changes, LoadForm for data operations
• Never access IDO data during component initialization, wait for the binding phase to complete
• Understand the form mode (Add, Edit, View) and condition component behavior accordingly
• Use the IFS debugger to trace lifecycle events and identify timing issues in custom code

Component Development and Data Binding

IFS forms consist of standard components, grids, text fields, dropdowns, buttons, and tabs, bound to IDO properties. Custom components can extend the base IFS component classes, but most requirements are met by configuring existing components with expressions, visibility rules, and custom actions. The grid component deserves special attention as it is the most complex IFS element, supporting inline editing, row-level coloring, custom cell rendering, and virtual scrolling for large datasets.

• Bind components to IDO properties declaratively in the form XML rather than programmatically
• Use IFS expressions for computed fields instead of event handlers for better performance
• Configure grid virtual scrolling for collections exceeding 500 rows to prevent memory issues
• Implement grid row coloring through the GridRowFormatting event for visual status indicators

IFS Development Best Practices

Productive IFS development requires a structured approach to form design, testing, and deployment. Always start with the standard form as a baseline and layer customizations using form personalization before resorting to code-based extensions. Use the form XML diff tool to understand what changed between versions.

Test forms across all supported browsers since IFS rendering can vary, particularly with grid components and date controls.

• Prefer form personalization over coded customizations for maintainability across upgrades
• Use the IFS form XML comparison tool to track changes between development and production
• Test forms in Chrome, Edge, and Firefox as IFS rendering differences exist across browsers
• Document custom IDO methods and their form dependencies in a central technical specification