Action: Assignment

Assigning values to different variable types

By

May 28, 2009

 

 
 

As discussed in the previous section, you can Action:Assignment to assign a value to a runtime or system variable.  Values can be assigned  to any of the following supported types:

  • Session – utilized by most system to support the state of the current users session information. This collection of information is the most widely used destination, but you must be cautious when utilizing this when in a web farm environment.

  • View State – The view state, once utilized in a standard manner, the variable exists within the physical transferred page request objects, and does not exist when the path of the page is not tracked directly
  • Cache –The physical web cache. This is shared collection utilized by the entire application.
  • Context - The physical context of the request. Values stored within this collection exist for the duration of the request.

  • Action – To provide a local variable aspect to ListX, Action variables exist within the context of the module and its request. This means that you can safely create as many Action variables as necessary and these will automatically be cleaned out whenever the request concludes.
  • Cookie - To assign a value to a cookie, select the cookie option from the variable type dropdown.  Default behavior - cookie will disappear at the end of the session. 
    Setting a lifetime for a cookie - You can set a lifetime for a cookie by assigning "name".expires and then setting the expires date in the value.  The date should be  in the following format: mm/dd/yyyy.
    Note: you will not be able to get the value you assigned to a cookie until the next request from the web browser.
  • Module Setting – the standard storage location for all Module settings. This is retained for the module and is utilized by the system whenever the module loads.

  • Tab Module Setting – the standard storage location for all Module settings. This is retained for the module and is utilized by the system whenever the module loads. The difference between this and the Module Setting is that this setting value exists only for this module on the current tab.
  • System – the standard storage location for page info.  More properties will be assigned through system going forward.  To begin, you can assign the Page Meta attributes. For example, if the requirement is to assign the Meta Description for the Page:

    Collection: <System>
    Name: Page.Meta.Description
    Value: This is the description.

    The following meta tags are directly supported by this feature:

    Page.Meta.Description
    Page.Meta.Keywords
    Page.Meta.Author
    Page.Meta.Copyright
    Page.Meta.Generator

    If you don't see the attribute you need to assign, you can simply place it after the Meta node, it can be dynamically assigned:

    Page.Meta.MyCustomMetaTag

    Currently no other System objects can be manipulated through the system collection in this way, however this will be extended in future releases.

  • UserInfo  – facilitating the ability for you to Edit and Create Users for your system, with easy attribute assignment, and without the need to worry about the physical database structures. Assignment is very simple:
  • To Load a User Info object: Leave the Name property empty, and set the Value to the ID of the target user, or the Username of the target user. This will automatically set this as the currently loaded userinfo record.


  • To Create a New User – Leave the Name Property empty, and set the Value to -1. This will automatically set the current userinfo object to a new object, which will create the user upon Save.


  • To Save the UserInfo – Leave the Name Property empty, and set the Value to Save. If you would like to use the resulting UserID for other purposes within the Action scripts, you can set the Name of the Action (Collection) variable to which you want the value stored: Save,myNewContactID. This will assign the value to the [myNewContactID,Action] variable.




    To Mark a user as Not Verified - Assign Membership.Approved the value of False.


  • To Assign a Property Setting – Set the Name of the Property as it appears within the UserInfo object, or within the Membership or Profile structures. All properties are automatically propagated by name. For instance, Email is used in all three tables, and will be automatically assigned, even though you only set the property by name once. (THIS IS CASE SENSITIVE).


  • To Assign a Role to a User – Set the Name of the Property to RoleID. The Value can actually be the Name of the Role for the current portal, or the ID of the Role for the current Portal. If you need to remove the User from a Role, prefix the ID/Name value with a dash. For example: -Registered Users will remove the user from the Registered Users role.

    NOTE: You cannot combine the creation of a User and the Assignment of roles into One Save command. When creating a new user, fill in the profile properties then save the user as indicated. Once the user is saved, Load the User using the resulting ID, assign the RoleID property and then Save the user again. This is because the User is not automatically Loaded upon save of the user, and therefore the UserID is still -1 when the RoleID assignment is attempted. Refer to the following screenshot of a sample user Registration and Role Assignment flow:


     
  • To Log a user off (Logoff) - Assign LOGOFF to the USERINFO object. Leave the "Name" field empty.


  • To Log a user in to DNN via DNN Authentication
    • Finally, Assign the UserInfo variable to LOGIN followed by two parameters – the name of the variable containing the password, and the name of the variable to record the result.

      Example:
      LOGIN,aPassword,aResult

    • The result variable, provided in the screenshot as LoginResult, is accessed like all other action variables. Meaning – for the example [LoginResult,Action] will yield the numeric result. The physical text result is also accessed via the result parameter with .Error appended, as seen in the sample [LoginResult.Error,Action].

      The numeric results possible are as follows:

      One or Greater: UserID of the User (SUCCESS)
      -1: Unidentified Error (FAILURE)
      -2: Duplicate Email, Duplicate User Name, Invalid Email, User Already Registered, Username already exists
      -3: User Rejected
      -4: Invalid Username
      -5: Provider Error, Unexpected Error
      -6: Invalid Password, Password Mismatch



      To Log a user in to DNN via Custom Authentication

    • Next, Assign the user password value to an Action variable. You must have this to utilize the DNN Authentication mechanism. If you want to log the user in without the password, check the Login to DNN via Custom Authentic.
    • First, load the user (above) either by Username or ID.


    • Assign the UserInfo variable to AUTHENTICATE followed by one parameter – the name of the action variable to record the result. For example: AUTHENTICATE,LoginResult.The result variable is accessed like all other action variables. Meaning – for the example [LoginResult,Action] will yield the numeric result. The physical text result is also accessed via the result parameter with .Error appended, as seen in the sample [LoginResult.Error,Action].

      The numeric results possible are as follows:

      -3 No User loaded. This means that the user has not been loaded into the UserInfo
      -2 User Unknown. This means that the user failed to exist in the portal
      -1 User Unapproved.
      0 User locked out (due to password failures).
      1 Success
    • First, load the user (above) either by Username or ID.
  • Page Size – Allows you to clear our or adjust the size of the page (number of records perpage) from within the action script)

  • Page Number – Allow you to control the current page number to display programatically

  • Search – Allows you to override the current Search Option setting

  • Filter – Allows you to control the Search option programmatically as which filter (search) text has been applied.

  • Sort – Allows you to control the Sort option itself, most of the time you would simply assign this to an empty value.


Variable Type - The type of the variable, which will be assigned.

Name - The specific Key Name of the variable within the Variable Type to be assigned.

Value - The new value to store within the variable. You may use the Rendering tags at any time within any section of the ListX administration. Leaving the variable Value empty will result in a nullification of the Variable value, useful for clearing out a configured Checklist.

Average (5 Ratings):
 
Want to help out?
 
 

New York, NY • Baltimore, MD • Vienna, VA • St. Louis, MO • Seattle, WA • 410.327.0007 • info@R2Integrated.com

Bookmark & Share Bookmark and Share