Snapp MX Zone

An Introduction to Login and Screen Variables

2007-11-23T12:55:00.000-07:00

There are two types of variables that are typically used within a Snapp MX application. They are called Login and Screen variables.

Login variables are global in scope, available for use in all application screens. They are initialized when a user is authenticated, hence the name. This authentication can take place through a Login screen or via a Pass-through function. You would use Login variables to store data that's required across many screens. An example might be a user's role, security level, or location. Login variables can be used within a Trigger condition statement to control screen access and/or to reconfigure screens. They can also be used to constrain the data presented within a component or list.

Screen variables, on the other hand, are local to the screen that they were defined for. They are either passed in from the previous screen or defined through a special Screen Variables function which is called prior to the screens displayed.

The variables passed in from the previous screen are called the Unique Id., Parent Id., and Other Info. These variables maintain the system's state, ensuring that the proper data is being presented. For example, when a user clicks on a List row, the next screen usually contains a form displaying the details of the selected record. This happens because the Unique Id. of the record is automatically passed to the form.

When data is not directly accessible by a screen, then a Screen Variables function must be created to retrieve it. In support, a Screen Variables function automatically receives the Unique Id., Parent Id., Other Info, as well as, Login variables. It is then a simple matter to create a SQL statement to grab the information required and then assign it to any newly defined Screen variables. An example, an employee's personal details probably would not contain information about how much they expensed that month. If this is the case then a Screen Variables function could be used to retrieve this information, making it also available for display.

For detailed instructions on how to create Login and Screen Variables go to Advanced Tutorials > Variables section within the Snapp MX Tutorials.

An Introduction to Snapp MX Web Services

2007-11-14T13:54:00.000-07:00

Snapp MX interacts with back office resources through two types of Web Services (i.e. Dynamic and Custom). Each has its advantages in certain situations. Please note that as of version 2.5 of Snapp MX "Default Web Services" will be renamed to "Dynamic Web Services".

A Dynamic Web Service automatically generates the query necessary to interact with a target table or view. Dynamic Web Services have always been used by Snapp MX to retrieve the data displayed in Lists and Detail screens. With the release of version 2, they can now be used to insert, update and delete records within Tables.

To perform a database update using a Dynamic Web Service, you simply select the component that the End-User will click on to initiate the web service call (e.g. a button, label, image, tree node, or menu node). You then set the component's "Action" attribute to "Call a Dynamic Web Service". Next, the "DB Interaction" attribute is set to "Insert Record", "Insert/Update Record", or "Delete Record". Finally, the "Action Upon Web Service Completion" is set appropriately if a follow-up screen related action is required. Thats all there is to it. The Dynamic Web Service takes care of the rest.

For more complex situations, Snapp MX also supports Custom Web Services. A Custom Web Service must be used to:

perform a database update when a screen is connected to a View;
validate login credentials;
set login or screen variables;
perform additional processing tasks (i.e. multi-table updates, conditional logic, etc.); or
interact with an external (non-Snapp MX) web service.

To help, Snapp MX has a built-in multi-dialect Code Generator that creates a basic Custom Web Service in the development language supported by the application server in use (i.e. JAVA, C#, VB.NET, PHP or CFML). Here are the steps involved:

The component initiating the Web Service call (e.g. a button, label, image, tree node, or menu node) is selected.
The "Action" attribute of this component is set to "Call a Web Service". The "Web Service Name" and "Function Name" are then auto-filled (these can be changed if need be).
If a database a table/view needs to be updated, then the type of "DB Interaction" (i.e. "Insert Record", "Insert/Update Record", or "Delete Record") is set. This action tells the Web Service Generator to add in the necessary SQL statements. Snapp MX will also add default "Web Service Arguments" (i.e. information that is passed to the Web Service). Additional, arguments can also be added should they be required.
The "Template" button is clicked to generate the Custom Web Service code which then appears in a pop up window.
The code in this window must then be transfered to a text/code editor so that it can be updated to fit the final processing requirements. Once edited, save the code with the filename identified at the top of the code (e.g. UserDetails_9_3.cfc)
If a Java or .NET application server is being used then the code must be compiled before it is ready to use. For more information on compiling go to Snapp MX Tutorials and review Basic Tutorials > Creating a Login Screen > Step 8: Creating a Web Service.
Finally, move the Web Service file to the directory also identified at the top of the code (e.g. f:\www\MyCList\site\1\com).

A Custom Web Service has four distinct sections (i.e. Documentation, Header, Processing, and Footer). The "Documentation" section identifies the file name, as well as, the directory for its deployment. It also contains information about the arguments passed to the web service and various return options. The "Header" is defined by the start of the actual function. This is where arguments are defined and variables are set to their default values. The "Processing" section begins at the "Do Any Processing Here" comment. This is where additional processing logic is added by the Developer. If the "DB Interaction" attribute was set, when the Custom Web Service was defined, then supporting SQL statements ("Insert", "Insert/Update" or "Delete") are also presented within this section. Finally, the "Footer" is where data is structured and then returned to the calling application.

For more information about Web Services, review the Snapp MX Tutorials and/or the Snapp MX Help documentation.

Getting Pushy with Snapp MX

2007-11-09T10:49:00.000-07:00

Want to get "Pushy" with Snapp MX? Well in version 2.5 you'll be able to do just that. We're adding three new Media components that will push data out to your system's End Users. They include a "User List", "Text Chat" and "Video Chat".

To take advantage of these components you'll need to install a free Open Source Communication Server called Red5 (http://osflash.org/red5) and enter its I.P. Address within the Snapp MX configuration file. Upon completion, your Developers will be able to add these social elements into their applications in minutes without any coding.

The User List component identifies all authenticated individuals that have opened the screen that it was placed on. When someone closes this screen, their name is automatically removed from everyone else's list.

The Text Chat component allows people to type messages that can be seen by all others viewing the current screen. A new message is typed into the smaller window (below). When the "Enter" key is pressed, it is then moved to the larger window for everyone to see. To keep things organized each message is labeled to identify its source. The messages can also be time stamped if required.

The Video Chat component is different than the User List and Text Chat, in that you can add multiple Video Chat windows on one screen. One of these windows would typically display what the local camera sees. The others would display video being transmitted by selected peers. Of course, those taking part in a video conference would need a video camera and microphone to transmit, as well as, speakers or headphones to receive.

Adjacent to the Video window there are two icons and a drop-down list. The first icon is that of a camera. If it's grayed out then the video transmission for that window is halted. The second icon is for Audio. No audio is transmitted when it's inactive. Clicking on these icons toggles their state from active to inactive and then back again. Finally, the drop-down list identifies everyone that has the current screen open (similar to the User List component). To engage in a video conference with someone, you simply select their name from this list. It should be noted, that many people can connect to one individual which is useful for seminars.

Adding Red5 support will allow us to incorporate many new functions into Snapp MX that will add tremendous value to all applications. Future functional possibilities for Snapp MX include:

a whiteboard to share ideas;
desktop sharing to aid in system support efforts;
a slideshow for presentations;
video-on-demand (streaming not progressive);
voice-over-ip telephone connections;
voice and video recording capabilities; and
lists and calendars that automatically update.

Adding an Image Column in your Lists

2007-11-01T10:03:00.001-06:00

When an Image component, placed within a Snapp MX screen, is set to be "Dynamic", a connection is automatically made between an uploaded image and the data record being displayed at the time of the upload. Look at a different record and the image changes correspondingly.

No coding or database updates are needed to make this happen. Snapp MX takes care of all the logistics. To support this function, there's a table within the Snapp MX Repository called "TBL_DYNAMICIMAGES". A record is automatically created in this table whenever a new image is uploaded. This record identifies the Application, Screen, Table and Unique Id. of the data record that the image is associated with as well as its file name.

To display uploaded images in a list located on a different screen you'll need to create a database View that connects "TBL_DYNAMICIMAGES" records with their corresponding application data records.

If your application data is stored in a different Database (not in the Snapp MX Repository), then you'll also need to make sure that the Database Server you're using supports queries to external tables.

Here are the steps:

In your detail screen (i.e. the data entry screen for your list):
- Add an Image component.
- Size it appropriately to ensure that it will display nicely in the list.
- Click on the Dynamic Image attribute tab.
- Set the Data Source and Table/View attributes to match the input form values.
Retrieve the following information from the Snapp MX Repository using your database administrator:
- Open TBL_APPLICATIONS and get the APPLICATIONID (e.g. 5 = the Id. of the application that the images are connected to)
- Open TBL_SCREENS and get the SCREENID (e.g. 9 = the Id. of the screen that is used to upload the images)
- Open TBL_TABLEHEADER and get the TABLEID (e.g. 3 = the Id. of table that the images are associated with (i.e. dbo.tbl_YourData))
In your Application database, create the following view (e.g. vw_YourData). This view adds an ImageURL field to the data fields presented in your existing list. This query was designed for MS SQL Server. It's syntax would need to be altered for an alternate database. (Change the URL portion to suit your setup).
SELECT 'http://www.yoursite.com/SnappMX/site/5/images/'
+ SnappMX.dbo.TBL_DYNAMICIMAGES.FILENAME AS ImageURL,
dbo.tbl_YourData.Id,
dbo.tbl_YourData.Field_1,
dbo.tbl_YourData.Field_2,
dbo.tbl_YourData.Field_3, ...
FROM dbo.YourData
LEFT OUTER JOIN SnappMX.dbo.TBL_DYNAMICIMAGES
ON SnappMX.dbo.TBL_DYNAMICIMAGES.UNIQUEID = dbo.tbl_YourData.Id
AND SnappMX.dbo.TBL_DYNAMICIMAGES.APPLICATIONID = 5
AND SnappMX.dbo.TBL_DYNAMICIMAGES.SCREENID = 9
AND SnappMX.dbo.TBL_DYNAMICIMAGES.TABLEID = 3
Make the new view accessible to the application (i.e. File > Administration > Data Sources).

On the list screen:
- Select the list
- Connect the new view to it (e.g. vw_YourData)
- Add a column for the ImageURL.
- Set, the attributes, Table Field (Display) to "ImageURL" and the Field Type to "Image".

That's all there is to it. The record images should now appear in the new column added to the list.

Additional Tips:

If your Database Server doesn't support JOINS to external tables and you really need this functionality just place your application data tables in the Snapp MX Repository.
For DB2 replace the "+" with "concat"
For Firebird and SQLite replace "+" with "||"
For MySQL and Oracle replace
'http://www.yoursite.com/SnappMX/site/5/images/'
+ SnappMX.dbo.TBL_DYNAMICIMAGES.FILENAME AS ImageURL
with
CONCAT('http://www.yoursite.com/SnappMX/site/5/images/',
SnappMX.dbo.TBL_DYNAMICIMAGES.FILENAME) AS ImageURL

An Introduction to Triggers

2007-10-15T10:45:00.000-06:00

Snapp MX Triggers are one of the most powerful tools one has when creating a screen. Basically triggers are a set of actions you would like to do on a screen based on a condition.

There are a ton of actions available to you including (but not limited to): Enabling and Disabling Form Fields and Buttons Showing and Hiding Form Fields, Buttons, Images, Lists, Trees, Charts Clearing, Setting and Copying Form Field Values Refreshing Lists, Trees, Charts Moving (Animation) Objects Renaming Labels and much more!

As you can see, there are many trigger actions that can change not only how your screen will look, but how it will work.There are 3 main types of triggers available for you to use:

On Load Triggers (triggers that run when a screen is first loaded)
On Change Triggers (triggers that run when a form field value has been changed by the end user)
On Click Triggers (triggers that run when a button, image or label has been clicked)

To set up a trigger, first create a screen, then go to Options > Triggers in the Main Menu bar.

Click on the "Add" button corresponding to the type of trigger you wish to create.
Create a Trigger Condition using the Condition generator, and
Add actions based on the Condition being Met or Not Met

Real life examples of what we have used triggers for in the past:

Enabling / Disabling Form Fields (or Buttons) based on who is logged in (or type of user)
- On Load Trigger
- Example: Only the Admin users can click on the "Save" Button
Showing / Hiding Form Fields based on other Form Fields
- On Change Trigger
- Example: Clicking on a Complete checkbox shows the Completed Date Form Field
Refreshing a Chart based on a Button press

On Click Trigger
Example: Chart data based on a Date Form Field, User can change Date, and click a Button to Refresh the chart.

Click here to see some triggers in action!

We hope you enjoyed this introduction, and am sure you are well on your way to understanding and using triggers