Showing results for 
Search instead for 
Do you mean 

Tech Tip: SalesLogix Web QuickForms – Shared logic and Utility methods - Part 1

by Employee ‎11-04-2009 03:43 PM - edited ‎11-04-2009 03:47 PM

Sometimes we cannot escape the fact that for some businesses their data entry and maintenance scenarios are necessarily complex – not because we have over designed, rather the world sometimes is not as simple as we would like it to be.

We frequently have the need to implement solutions that require highly dynamic user interfaces, often morphing considerably based on data entry values supplied by the user. For example, we may have several panels on a QuickForm where certain combinations of panels should be hidden or shown based on the value of one or more fields for the current record – say Account.Type plus Account.Status. As the user selects different picklist values, the user interface must morph; likewise when the user changes records the user interface must morph according to the values of the new current record.

How can we define and utilize shared user interface logic such that the ChangeAction() events for the Account Type and Account Status picklist controls, as well as the Form_OnLoad() event handler, can all make use of shared logic that is defined and maintained only once?

 

Part 1 – Using C# Snippet Action Item (Obsolete) Techniques

For this blog we will assume that you are making use of the C# Snippet Action Item (Obsolete) technique for implementing your Form and Control event handler logic. As the “Obsolete” moniker implies, developers are advised to transition to using Code Snippet Action items and/or External Assemblies.

Note that a future Part 2 Blog will discuss techniques for addressing the Shared logic challenge when using the more preferred Code Snippet Action and External Assembly techniques.

A challenge we face with QuickForms is that we can only write event handler code for specific Form and Control events as exposed by the Form and/or Control properties for OnChange Action, OnLoad Action, etc. Where can we define shared logic usable by more than one control event?

Answer:  ASP.Net \App_Code folder and Helper classes

ASP.Net provides a useful feature – any file that defines a class will be automatically compiled by ASP.Net and those classes will automatically (or as we like to say “automagically”) be available for use in ASPX and ASCX files.  In this way we can create useful Helper classes and methods, not only for the purpose of Shared logic for a single QuickForm, but even more general purpose utility classes and methods.

Well, as it turns out – the code you supplied when defining your C# Snippet Action Item (Obsolete) action items eventually ends up in the generated ASCX file as “in-line” C# code in the ASCX file itself. This means any helper classes and methods that you create by adding a *.cs file to the \App_Code folder can be used inside your C# Snippet Action Item (Obsolete) event handler code.

Within Application Architect (AA), using the Project Explorer, you can find the \App_Code folder at:

\Portal Manager\Sage SalesLogix\SupportFiles\App-Code

You might examine the files ActivityFormHelper.cs and AddOpportunityProductHelper.cs as examples used by the Sage SalesLogix WebClient solution.

Listing 1:  C:\Inetpub\wwwroot\SlxClient\App_Code \AccountFormHelper.cs

 

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Sage.SalesLogix.Web.Controls;
using Sage.Entity.Interfaces;
using Sage.Platform.Application;
using Sage.Platform.Orm.Interfaces;
using Sage.Platform.Security;

/// <summary>
/// Example QuickForm Event Handler Helper Class for Account Quickforms
/// </summary>
public class AccountFormHelper
{
    public void MyTestMethod(Sage.Entity.Interfaces.IAccount account)
    {
       account.BusinessDescription += " MyTestMethod worked!";
    }
}
Listing 2: C:\Inetpub\wwwroot\SlxClient\SmartParts\Account\AccountDetails.ascx

protected void pklStatus_ChangeAction(object sender, EventArgs e)
{
     Sage.Entity.Interfaces.IAccount account = this.BindingSource.Current asSage.Entity.Interfaces.IAccount;
AccountFormHelper afh = new AccountFormHelper ();     
afh.MyTestMethod(account);
}
Caveats:
Code completion intellisense in the Application Architect code editor for C# Snippet Action Item (Obsolete) will not recognize the new Classes and Methods defined in your \App_Code. Consider using MS Visual Studio to edit your ASCX files with full intellisense, but be certain to paste your event handler code back into the appropriate C# Snippet Action Item (Obsolete) event handlers in Application Architect.

As mentioned earlier, you should consider migrating away from using the C# Snippet Action Item (Obsolete) technique for your Form and Control event handlers and instead use the preferred Code Snippet Action and/or External Assembly techniques to be discussed in a future Part 2 blog post.
Message Edited by ToddHardin on 11-04-2009 04:47 PM
Message Edited by ToddHardin on 11-04-2009 04:47 PM

Register Read Guidelines Request Partner or Employee Access

What's New in 8.1

Labels