Using iPortable

Adding Import / Export Capabilities to your modules

DotnetNuke provides a common interface for Exporting and Importing content from one module to another via iPortable. This interface is made evident from within each module by a set of options available within the drop down menu of the OpenWebStudio module. The options, labeled "Import Content" and "Export Content" work in a rather simple manner.

How it works within DotNetNuke

Exporting Content

First, the user Selects "Export Content" from the provided Action Menu.

Next, the user selects the target folder where the exported content will be stored and the Name of the file that will contain the export.

Finally, the user clicks the "Export" link, completing the process.

Importing Content

To Import templates into new or existing modules, click Import Content from the Action menu

Next, select the source folder, followed by the source file.

Finally, click "Import" from the links provided, completing the import process. 

How to Extend Portability in Modules

Standard OWS modules support the ability to export anything stored within the Module Settings. With the advent of 2.1.19, the iPortable has been greatly extended to support the Export and Import of not only the Module Settings, but also the resulting values from Query and Assignment Actions to the Action collection.

The logic necessary to complete the operation now only requires a few simple steps where it used to require custom .Net development of additional providers. The most difficult part is identifying exactly What the module should be exporting. Once that has been solved, the rest of the process straight forward.

To begin, consider that you will need to split a Query operation into 2 steps. The first step - selecting the data you want to export, and the second step - inserting that data into your target module. It's best to lead by example here, so taking from our existing library of samples, lets assume we have a module which produces a Graph. The Module Settings interface provides a simple grid to allow the user to enter each point that will be presented on the graph, and the records are therefore stored in a table created with the following statement:

OWS_Graph (GraphID int identity(1,1), ModuleID int, Label varchar(255), Value int)

Each record contained within the OWS_Graph table will therefore contain a ModuleID which is unique to the current module. With the GraphID as the primary key, that leaves only the Label and Value columns required for export.

How to Implement the Export

To provide export of the necessary table, only two specific actions are necessary: a Region  and a Query action.

  1. Add a Region to the Configuration, typically placed at the root level.
  2. Edit the Region, checking the box labeled "Include Action Sequence in Export" as seen here.
  3. Next, add a Query action as a child of the previous Region. This query will now be executed ONLY when a Export has been requested. As noted above, the logic must export the content of the dependent table, OWS_Graph, containing all records which are specific to the current module.
  4. Edit Query Action, providing a statement which will fulfill the desired requirement. In this sample the current ModuleID is obtained through the ModuleID System token.
     
  5. That concludes the Export logic. If more tables are required for export, simply add more Query actions. The idea behind this logic it to make export and import as simple as selecting and inserting. Once complete, the operation looks something like this:
     

How to Implement the Import

To provide import of the provided table, only two specific actions are necessary: a Region  and a Query action, however, due to the standards, a Query Variable will be created for each of the three columns which need to be populated within this sample. Keep in mind that this is meant to logically break Export and Import into two halves of the same basic logic: Selecting the records and Inserting them into the table.

  1. Add a Region to the Configuration, typically placed at the root level directly after the Export region, again because it makes more sense logically.
  2. Edit the Region, checking the box labeled "Include Action Sequence in Import" as seen here.
  3.  Add a Variable as the first child of the Import Region, defining it as the Variable which provides the ModuleID for the current module.
  4. Next, the crucial step of the Import process, add the other half of the Export Query action. This is done by Adding a Query action with the same Name as the query from the Export process, but providing now statement to execute. Like all Query actions, this indicates that the configuration must recycle an existing cached result from a previous action of the same name. In this case, the previous execution occurred during the Export process.
     
  5. Now, as if the query had been executed at the present time, the only necessary step is to execute an INSERT query for every query from our resulting Export. Add a set of Variables to provide the values exported from the original query, "Label" and "Value". Making these children of the Import action.


     
     
  6. Now, with the provided variables in place, a Query must be executed to insert the provided records into the target database. 
  7.  This concludes the Import process, the action block should look like this upon completion:
     

 

 

 


 

 

 

 

Average ( Ratings):
 
Want to help out?
 
 

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

Bookmark & Share Bookmark and Share