SuperContainer Tips Tricks and FAQ

SuperContainer Documentation

SuperContainer Companion Plug-in

Troubleshooting and Known Issues

Advanced Configs, Tips, Tricks, and FAQ

PHP Documentation

Tips and Tricks

Using port 80 with standalone SuperContainer deployment

In order to use the standalone SuperContainer applet, which by default runs on port 8020, on port 80 you will need to configure some settings within your Apache Tomcat server.

First, you will want to navigate on your machine to the Apache httpd.conf file:

Mac OS X:

/private/etc/apache2

NOTE: This may be hidden on Mac OS X and can be reached by using "Go" -> "Go To Folder..." in the Finder.

Windows:

C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf

Now, add the following two lines to the httpd.conf file after the appropriate "DocumentRoot" as shown below:

DocumentRoot "/Library/WebServer/Documents"

ProxyPass "/SuperContainer" "http://localhost:8020/SuperContainer"
ProxyPassReverse "/SuperContainer" "http://localhost:8020/SuperContainer"

The ProxyPass and ProxyPassReverse are two Tomcat directives that allows remote servers (SuperContainer in this case) to be mapped into the space of the local server (Tomcat). You can find more information on these directives by visiting: http://httpd.apache.org/docs/1.3/mod/mod_proxy.html#proxypass

Then, you will need to restart your Apache server:

Mac OS X:

Open Terminal and type:

sudo apachectl restart

Windows:

Easiest way to control Tomcat on Windows is to use the Tomcat Monitor tool. This is available by selecting Start -> All Programs -> Apache HTTP/Tomcat Server -> Monitor Apache

Finally, launch the standalone SuperContainerServer.jar file as normal and navigate to:

http://localhost/SuperContainer

to ensure SuperContainer is running on port 80.

SuperContainer for hosting providers

You can run SuperContainer version 1.72 or later for your clients in Tomcat by following these steps:

• Please see the Tomcat installation instructions here
• Each client will need to purchase a separate license of SuperContainer, or you may purchase a license for them.
• Modify SuperContainer/WEB-INF/web.xml file and put in valid values for the 'activationCode' and 'registeredTo' settings for your client.
• Change the name of the SuperContainer folder to that client's name and put it into the webapps folder. The URL will become whatever you name the folder, so if you change the folder name from 'SuperContainer' to 'ClientX', the URL to access SuperContainer will be http://yourServer:8080/ClientX/Files.

List of hosting providers

The following companies have told us that they are set up or willing to configure their servers to host SuperContainer. They are listed in order of when they first contacted us:

• Joseph Grimaldi, ODI Technologies ( http://www.oditech.com/ )
• John May, Point in Space ( http://www.pointinspace.com/ )
• Scott Karch, Nimbus ( http://www.nimbushosting.net/ )
• Foxtail Technology ( https://www.foxtailtech.com/Index.php?page=sc )
• Dan Weiss, Adatasol ( http://www.adatasol.com/ )
• Joshua Paul, Neo Code Software ( http://store.neocodesoftware.com/ )
• Lee Lukehart, SavvyData ( http://savvydata.com/ )

Enabling OS X Core Image resizing

***The following section is obsolete. Core Image library is enabled by default.***

In it's normal configuration, SuperContainer can generate thumbnail images of JPEGs, PNGs, GIF files, and most TIFF files. It will not generate thumbnails for PDF files, CMYK JPEG or TIFF files, RAW files, or Photoshop files.

There's a mac-specific feature that lets SuperContainer use native OS X image processing libraries for its image handling. This means it can generate thumbnails of PDFs, as well as just about any other image type you throw at it. This only works if you're running SuperContainer server in standalone mode on an OS X box. It will not work on a Windows server, or when running in Tomcat. It doesn't matter what the client machines are using, however.

Just create a new file at the following location:

/Library/Preferences/com.prosc.supercontainer.properties

The contents of the file should be the following line:

coreImageEnabled true

And then restart SuperContainer. Thumbnails will now be generated using OS X image libs, and PDF will appear as thumbnails instead of icons.

Enabling QuickLook

***The following section is obsolete. QuickLook library is enabled by default.***

OS X 10.6 Snow Leopard and newer

/Library/Preferences/com.prosc.supercontainer.properties

You will need to create this file if you have not done so before.

It should contain this single line:

quickLookEnabled true

Plugin auto-update info

See the section on Plugin autoupdate

Compatability matrix

Accessing SuperContainer from FileMaker Pro

	Version 7	Version 8	Version 8.0v4	Version 9	Version 10	Version 11	Version 12
FileMaker Pro: Access with a Web Viewer	X	X	Y	Y	Y	Y	Y
FileMaker Pro: Using optional plugin	Y	Y	Y	Y	Y	Y	Y

	Version 7	Version 8	Version 8.0v4	Version 9	Version 10	Version 11	Version 12
FileMaker Pro Server, Custom Web Publishing	X	X	X	Y	Y	Y	Y
FileMaker Pro Server Advanced, Instant Web Publishing	X	X	Y*	Y	Y	Y	Y
FileMaker Pro Server Advanced, Custom Web Publishing	Y	Y	Y*	Y	Y	Y	Y

Note: * = FileMaker Server / Server Advanced 8.0v4 on OS X will not work with the optional SuperContainer Companion Plugin. It will work on Windows, or on 8.0v1 - 8.0v3

SuperContainer is fully compatible and tested to work with FileMaker 10.

Configuring where SuperContainer saves files

By default, SuperContainer saves files in /Users/Shared/SuperContainer on Mac OS X and C:\Documents and Settings\SuperContainer on earlier versions of Windows and C:\Users\SuperContainer on later versions . You can set this to any path you want, such as an external drive or network volume. If you are running in standalone mode (ie. double-clicking on SuperContainerServer.jar), that can be configured by clicking 'options'.

If you are running in Tomcat or with FileMaker Server, you can configure that by editing the web.xml file. With Windows, modify both the "windowsFilePath" and "vistasFilesPath" to point to the location that you want. After you have made modifications to the web.xml file, stop and start SuperContainer using the 360Works Admin utility for the changes to take effect.

Change the 'macintoshFilesPath' for OS X

	<context-param>
		<param-name>macintoshFilesPath</param-name>
		<param-value>/Users/Shared/SuperContainer/Files</param-value>
		<description>This is where the files will be stored when running on the Mac platform.</description>
	</context-param>

'windowsFilesPath' for XP

	<context-param>
		<param-name>windowsFilesPath</param-name>
		<param-value>C:\Documents and Settings\SuperContainer\Files</param-value>
		<description>This is where the files will be stored when running on the Windows platform.</description>
	</context-param>

'vistasFilesPath' for Vista or later

	<context-param>
		<param-name>vistaFilesPath</param-name>
		<param-value>C:\Users\SuperContainer\Files</param-value>
		<description>This is where the files will be stored when running on the Windows Vista and Windows 7 platform.</description>
	</context-param>

Set this to where you want the files to be stored. Be sure to configure file permissions appropriately for the folder you're storing to, especially for network volumes.

Locking the SuperContainer Registration

Entering information in the .../SuperContainer/Registration page will set your registration, but it can be changed from that page as well. If you want to lock in the SuperContainer registration so that it cannot be changed from a browser you should enter your license key in the activationCode and registeredTo values in the web.xml file (the same place you can set a username and password). Enter your values, save the file, and restart the SuperContainer Server and SuperContainer will read the value from the web.xml file, rather than from what is entered into the registration page.

Uninstalling SuperContainer

• When deployed in FileMaker Server's Web Publishing Engine: If you have installed SuperContainer to run in FMS WPE, you can re-run the MacInstaller.app or WindowsInstaller.exe file and click "Remove" to uninstall from the Web Publishing Engine.
• When deployed on Tomcat: If you have installed SuperContainer to run in a standalone version of Tomcat, you can simply remove the SuperContainer folder from the webapps folder of in your Tomcat directory.
• When deployed in standalone mode: If you have deployed SuperContainer to run in standalone-mode (i.e. SuperContainerServer.jar file), you can simply delete the .jar file.

NOTE: SuperContainer saves its preferences in a file on your computer (when running in standalone mode by double-clicking the .jar file). On a mac, this is located at /Library/Preferences/com.prosc.supercontainer.plist. Remove this file to remove any stored preferences.

Removing Registry Entries

Windows: Search the registry for all keys which include "supercontainer" and remove them. Mac: Look for a file /Library/Preferences/com.prosc.supercontainer and remove it.

Is opening the file to view it different with the noapplet parameter?

Yes, when not using the Java applet, SuperContainer will open files through the default web browser. For Mac OS X, this is Safari. For Windows, it is Internet Explorer. Each browser operates slightly different with various file types. Some browsers are able to render certain files (PDFs for example) like Safari, while others are unable to by default, like Internet Explorer and Firefox and instead download the file to the user's temporary or "Downloads" directory.

As a workaround you could use FileMaker's "Open URL[]" script step to open the file in the native application (ex., Adobe Acrobat for PDFs). An example of this is offered in our documentation for SCDownload() and attach this to a button on your layout. (See: "Opening a file in it's native program without Java Applets" below)

SuperContainer Security and Web Hosting

This is an issue and question that surfaces consistently. While operating under a web interface, it can be extremely difficult for someone to be able to access the file(s) directly, especially if those files are placed outside of the website's root file directory. Unless there is FTP access enabled, then only if the setup is sloppily done with no real security.

One good piece of advice about security when using SuperContainer and the web -- since the S.C. interface uses a 'web address' to pull the file and display it on the web browser -- DO NOT use sequential numbers to identify your files. The reason for this is that if someone was paying even the slightest attention, they would notice that the web address will display the ID of the file, like this -

http://www.yourServer.com/SuperContainer/Files/PDFs/1024/

Nothing is stopping them from manually typing in the address bar

http://www.yourServer.com/SuperContainer/Files/PDFs/1025/ 
http://www.yourServer.com/SuperContainer/Files/PDFs/1026/ 

and so on to view documents/pictures you didn't intend for them to see. Use a highly unique identifier instead, like a UUID. It'll increase the size of your web address/URL, but this also makes it near impossible for someone to "guess" an address.

Opening a file in it's native program without Java Applets

You would want to use the SCDownload() function in conjunction with the Open URL script step. The SCDownload will grab the file from the SuperContainer server and place it on the user's local machine. Then the OpenURL script step will open the local document in whatever program it would natively open in:

Open URL [SCDownload("Photos/12345")]

As seen above, the only thing needed in the SCDownload() function -- as with most SuperContainer plug-in functions -- is the folderPath (everything after the "/Files" piece) that points to the file on the server. Also as seen above, is that there is no explicit file name that is passed in (as it should be). So, by following the above, you should be able to get your solution to work as expected.

Link to SC Companion plug-in function (SCDownload()): http://static.360works.com/plugins/SuperContainer/plugin-documentation.html#SCDownload

Single record linking to multiple web viewers (ie. multiple URL's for a single record)

For the purposes of this example assume that we have a contact record that has to files attached to it, one file is the picture of the contact and the other file is contact biography Word file.

In order to have both files linked to the same record they both need to have some common piece of information, such as a record ID. As well, they both need a differentiating attribute, file type is a good candidate.

Example URLs:

http://serverAddress:portNumber/SuperContainer/Files/recordID/FileType

http://192.168.2.1:8020/SuperContainer/Files/12/image
http://192.168.2.1:8020/SuperContainer/Files/12/document
or
http://192.168.2.1:8020/SuperContainer/Files/12/contact_image
http://192.168.2.1:8020/SuperContainer/Files/12/contact_bio

Using SuperContainer with portals

Here is a link to a sample FileMaker database file that uses SuperContainer with portals, container fields, and integrates multiple files/documents in a related record:

static.360works.com/SuperContainerDemo/PortalUseAdmin.fp7

Viewing multiple page PDFs within the web viewer

There are two ways to accomplish that in SuperContainer.

1.

This requires that SuperContainer is running in 'standalone' mode on Mac. In this mode SuperContainer will automatically render the first page of the PDF. To get a preview of another page just use the page parameter in your URL. EX: http://localhost:8020/SuperContainer/Files/multi/page/PDF?page=1 http://localhost:8020/SuperContainer/Files/multi/page/PDF?page=4

2.

This method requires that the system browser on user's machine is able to render PDF files. On Mac this is built in functionality, on Windows this can be accomplished by installing Adobe Acrobat plugin for IE or the equivalent. To load the PDF file in the webviewer use the following URL: http://localhost:8020/SuperContainer/RawData/multi/page/PDF

Using the context RawData tells SuperContainer to return the actual file stored instead of displaying a Java applet or HTML form to present the file. And if the browser is able to render the PDF then it will be available to the user right in the webviewer. Note that this method loads the complete PDF into the webviewer where the first method load just preview of a single page.

Industry-specific tips

• Using SuperContainer in the Legal field

Getting the file name of a SuperContainer file

Very simple with the SuperContainer Companion plug-in. Take a look at the following example:

GetValue( SCGetInfo( folderPath ) ; 1 ) 

Where folderPath is the path to the file that is located on the SuperContainer server. If your web viewer URL is:

"http://servername:8020/SuperContainer/Files/Employee/Document/" & Document::ID

your folderPath would be: "Employee/Document" & Document::ID

This uses the GetValue() function and grabs the first line from the SCGetInfo() return-separated list. The first line (1), being the file name.

Using image transparency with SuperContainer

To use image transparency with SuperContainer, such as with a .png file, you must add "?style=noapplet" to the end of your supercontainer URL. Using this mode, you will not have drag and drop capabilities, so if you need this, you can have one web viewer on one layout without this parameter for dragging and dropping, and then the other web viewer on the layout that needs transparency. Consider that SuperContainer will not automatically detect width and height in this mode, and so you will also need to add "width=x&height=y".

Example:

http://yourServer/SuperContainer/Files/path/to/files?style=applet&width=250&height=275

Storing the filename of an uploaded file in a FileMaker field

If you want to store the name of an uploaded file into a FileMaker field, first ask yourself whether it's really necessary. The way that SuperContainer is designed, FileMaker does not need to know the filename in order for the user to upload, download, view, print, or delete the associated document. However, FileMaker does need the filename in order to do searches on it.

If you decide that you need to store the filename in a field, there are two approaches, which both involve the optional SuperContainer Companion Plugin.

• Option 1: Do not use the Web Viewer to upload files - instead use the SCChooseFile plugin function to get the path of the requested file. Then you can extract the name of the selected file into a FileMaker field, and use SCSetContainer to upload the document to SuperContainer. This option is very reliable, but will not work with the Web Publishing Engine (because the SCChooseFile function does not work on the web).
• Option 2: Use the Web Viewer to upload the file, and then have a 'save' or 'continue' button that the user clicks after completing the upload. This can then use the SCGetInfo plugin function to get the name of the file and store it into a FileMaker field. This option is the one to choose if you need this to work with the Web Publishing Engine.

Preview TIFF images

Run SuperContainer on a Mac in standalone mode, by executing SuperContainerServer.jar file

Using SCScanDirectory()

Set Variable [ $setBaseURL ; SCSetBaseURL() ]

Set Variable [ $files ; SCScanDirectory( pathToDir ) ]

Set Variable [ $counter ; 1 ]
Loop
Set Variable [ $upload ; SCSetContainer( folderPath ; MiddleValues ( $files ; $counter ; 1 ) ) ]
	If [ $upload = "ERROR" ]
		Show Custom Dialog [ "EROR" ; SCLastError ]
	End If
	Set Variable [ $counter ; $counter + 1 ]
	Exit Loop If [ $counter = ValueCount ( $files ) ]
End Loop

Why can't SuperContainer store multiple files in a single directory?

One of the original design goals of SuperContainer was that it would work without requiring any plugins. This led to a series of decisions:

• FileMaker is not capable, without plugins, of knowing the name of a file on the hard drive.
• Therefore, it is logically impossible to embed the name of the file into a Web Viewer using only features built into FileMaker.
• To solve this problem, we made it so that instead of representing the file name, the URL would just represent the folder that the file is stored in. This can be picked by the developer without regard to the actual name of the file.
• Since this folder reference needs to unambiguously identify a particular file, it follows that a 1 folder must equal 1 file. If you reference a folder in SuperContainer that contains more than 1 file, it will just retrieve the first file it finds, ignoring any others in the same folder.

Some of our customers do know the names of the files that they are storing, and it seems natural to them to store many files in a single folder. In this case, we make the following recommendations:

• Don't worry about it - just go ahead and use the file name in the URL. This will result in the file being nested one level deeper than necessary, but it doesn't hurt anything. For example, let's say you have a file called 'MyFavoriteFlower.jpg'. If you set your URL to '/SuperContainer/Files/images/MyFavoriteFlower.jpg', then it will be stored with this path on the server: images/MyFavoriteFlower.jpg/MyFavoriteFlower.jpg. Other than being a little annoying to know about this is harmless.
• Drop the filename from the URL - SuperContainer will still store it just fine on the server. So for the above example, let's use the record ID (let's pretend it's record #17) instead of the filename: '/SuperContainer/Files/images/17'. This will be stored on the server as images/17/MyFavoriteFlower.jpg. This is a better approach than the first option, because if you have another different file called MyFavoriteFlower with record #18, it will be stored in images/18/MyFavoriteFlower.jpg with no name conflicts.
• Remember, in SuperContainer 2, you upload entire directory structures to SuperContainer, so if you have a folder on your desktop named 'CoolStuff' that contains 'MyFavoriteFlower.jpg', 'MyFavoriteTree.jpg', and 'MyFavoriteBug.jpg', you can upload that folder into a single folder in SuperContainer. If your URL is /SuperContainer/Files/19, it will be stored on the server as a single zipped file in 19/CoolStuff.zip.

Using /Single File instead of /Files

• Using /SingleFile in the SuperContainer URL enables you to point to a particular file within a directory. If you know the filename that was present within a record - say, "myAsset.jpg" - then you could use SingleFile/ to point directly to that file. For example:

http://yourServer.com:8020 /SuperContainer/SingleFile/Asset/4321/myAsset.jpg

Your FileMaker calculation would look something like this

"http://yourServer.com:8020/SuperContainer/SingleFile/Asset/" & myTable::ID & myTable::filename

Apache upload limit

Edit the "server.xml" file located in your Apache Tomcat Directory. Add/Edit the "maxPostSize" attribute in the "Connector" element to increase the size.

<Connector port="8080" maxHttpHeaderSize="8192" 
maxThreads="300" minSpareThreads="25" maxSpareThreads="75" 
enableLookups="false" redirectPort="8443" acceptCount="1024" 
connectionTimeout="20000" disableUploadTimeout="true" 
compression="on" 
maxPostSize="104857600" /> 

Here is a link with more detailed instructions:

http://tomcat.10.n6.nabble.com/Setting-max-file-upload-size-td2010633.html

IIS upload limit

http://ajaxuploader.com/large-file-upload-iis-asp-net.htm

iis config file: %windir%\system32\inetsrv\config\applicationhost.config

<system.webServer>
       <security>
           <requestFiltering>
               <requestLimits maxAllowedContentLength="524288000"/>
           </requestFiltering>
       </security>
</system.webServer>

Moving SuperContainer Contents to a New Location

I've deployed SuperContainer to one location, and now I need to move SuperContainer, along with all of the associated assets, somewhere else. What's the best way to do this?

• Move the Files directory

If you have access to the SuperContainer "Files" directory, the easiest way to move assets is to simply move the SuperContainer/Files/ directory to your new SuperContainer location. Upon deploying and configuring SuperContainer at the new location, SuperContainer will create a Files directory at the default location. See this page for default locations. Replacing this Files directory with the existing directory will maintain all of the assets and relationships from the current deployment.

• Use the Companion Plugin

After setting the base URL at the new location, using SCGetContainer to retrieve the SuperContainer asset from the old location. Then use SCSetContainer to upload the asset to the new deployment location. You'll likely want to embed this in a looping script that will iterate through all of the SuperContainer assets. You can view a video about this process here.

Language Localization

Changing Language

The language SuperContainer uses is determined by the default browser language. If a user loads the page on a browser with the language set to Spanish, SuperContainer will display the Spanish localization to them. Please refer to your browser's documentation for instructions on changing the default language.

Supported Languages

• Dutch
• English
• English US
• French
• German
• Italian
• Japanese
• Russian
• Spanish

Thumbnail Naming Convention

Currently, we use a structure for naming generated thumbnails with SC:

<width>x<height>@<resolution><transparencyFlag>.png/jpg

The ‘o’ or ’t’ at the end of the thumbnails stands for whether they have transparency to them. If a thumbnail is not transparent, it will be labeled ‘opaque’ or ‘o’. If a thumbnail is transparent at all (even by 1%), it will be labeled ‘transparent’ or ’t’.

The .jpg format is for thumbnails that are not transparent (or cannot be transparent), and the .png is for thumbnails which are (or could be) transparent.

Advanced Tips

Creating custom styles

Advanced users can also define custom styles by editing the custom.css file in the SuperContainer application directory. You can also contact us for support if you'd like help with customized styles.

Revision Tracking

You can control your own version tracking by appending a revision number to your SuperContainer URLs, like this:

http://yourServer.com:8020/SuperContainer/Files/Asset/4321/revision2?style=nodelete

Since SuperContainer treats each slash in your URL as a folder, this will cause it to reference the 'revision2' subfolder inside folder '4321'. By removing the delete option, you can use this to make sure that a history all files is kept.

• Always use the nodelete in your URL to prevent users from deleting any resources
• Initially, a supercontainer resource is empty, and shows an upload form
• When a user submits a resource, the upload form disappears. The nodelete style hides the delete button.
• If a user wishes to replace the resource, she clicks a button in the FileMaker layout, which you would script to increment the revision number for the current record.
• The change in the revision number changes the SuperContainer URL, so the upload form appears again.
• The file has not actually been deleted, but appears to have been. Now the users uploads a new file.
• To see historical documents which were "deleted", just decrement the version number.

See the SuperContainer Example file for a demonstration of this technique.

View Types

In the example URLs above, notice the "/Files/" portion after the application base URL. This specifies the view type to use. 99% of the time you will be using the Files view type for your URLs. If you want to return the raw data for a resource, you can use RawData instead. This can be handy if you are referencing a SuperContainer resource from another URL, or using some tool to get the contents of a SuperContainer resource file. The companion plugin uses the RawData view type to pull data from SuperContainer.

Leveraging the Plugin

For fine-grained control over your workflow, you can set all your web layouts to use the readonly style, and use the plugin for all editing purposes. This allows you to build custom actions into scripts that occur whenever an item is uploaded. This makes implementing revision tracking much easier (see above). You could also utilize something like the 360works Textractor plugin to store the text of any uploaded documents in FileMaker.

Here are some example scripts you can integrate with your solutions. These illustrate error-checking best practices, and helpful ways to utilize the plugin functions.

Checking for plugin installation

If the user does not have the SuperContainer plugin installed, you may choose to exit the script, or take her to a different layout which uses a web viewer to upload/download files instead of the plugin. To check whether the plugin is installed, use the following method:

# Exit if plugin is not installed
If[SCVersion = "?"]
	Show Custom Dialog ["SuperContainer Plugin is not installed."]
	Halt Script
End If

Setting the base URL

You must always set the SuperContainer base URL before calling other plugin methods. A good time to do this is in your startup script.

Set Variable[$result; Value:SCSetBaseURL("http://yourServer.com:8020/SuperContainer/Files")]
If [$result = "ERROR"]
	Show Custom Dialog ["Could not connect to SuperContainer Server!"; SCLastError]
End If

If you have additional parameters to add such as "selfSignedSSL" then you must include empty quotes for the username and password values because the order matters when supplying additional parameters.

Set Variable[$result; Value:SCSetBaseURL("http://yourServer.com:8020/SuperContainer/Files"; "" ; "" ; "selfSignedSSL=1")]

Example upload dialog

Use the following script to upload a file to SuperContainer using the plugin. This shows a file chooser dialog. When a file is selected, it is uploaded to SuperContainer, and the web viewer is refreshed to show the new file. This demonstrates usage of the plugin functions SCChooseFile, SCSetContainer and SCLastError. Note that you need to give your web viewer a name ("webviewer" in this example) for the Set Web Viewer script step to work correctly.

# Do the upload
Set Variable [$result; Value:SCSetContainer(Get ( LayoutTableName ) & "/" & ID ; SCChooseFile)]
# Check for error during upload
If [$result = "ERROR"]
	Show Custom Dialog ["Could not upload file"; SCLastError]
End If
# Refresh the web viewer to show the new file

Set Web Viewer [Object Name: "webviewer"; Action: Reset]

Example download dialog

If you wish to open a SuperContainer file locally instead of opening it in the user's browser, you can use the plugin to look for the file on a mounted volume, or download it to the user's local hard drive. You might make the web viewer a button which triggers the following script to download the file. The following script demonstrates uages of the plugin functions SCGetFileURL and SCDownload.

Set Variable[$folderPath; Value: Get ( LayoutTableName ) & "/" & ID]
If [IsEmpty ( SCGetInfo($folderPath) ) ]
	# There is no file to open
	Exit Script
End If
Show Custom Dialog ["Do you want to open the file in your web browser, or download it to your local drive?"]
If [Get(LastMessageChoice) = 1]
	# Open in web browser. Note we reference "RawData" instead of "Files"
	Set Variable [$url; Value: "http://myServer.com:8020/SuperContainer/RawData/" & $folderPath]
Else If [Get(LastMessageChoice) = 2]
	# Download a local copy of the file and open that. This will be a "file://" url.
	Set Variable [$url; Value: SCDownload( $folderPath )]
	If [$url = "Error"]
		Show Custom Dialog ["An Error occurred while download the file" ; SCLastError]
		Exit Script
	End If
Else
	# User clicked 'cancel'
	Exit Script
End If
Open URL [$url]

Portals

Web Views cannot be embedded in portal rows. If you want to display SuperContainer files in a portal, create an unstored calculation in the portal table whose type is "container". Set the calculation to

LeftValues ( SCGetInfo("path/to/my/record" ) ; 1 )

This calculation will use the plugin to display the name of the resource in the portal.

If you're sure that only images will be used in a container and you want to display thumbnail views of the images, you can use the following calculation instead:

SCGetContainer("path/to/my/record" ; 64 ; 64)

Adjust the path, width, and height for your needs. The drawback with this is, if the container contains non-image data, the entire file will be downloaded each time the portal is displayed!

Tying into FileMaker account privileges

By default all FileMaker users have equal access to SuperContainer. Even if a user has read-only access in FileMaker, SuperContainer has no way of knowing that, unless you specify additional parameters in the URL.

To disable uploading and deletion for FileMaker users with read-only access, you can use a calculation like this to generate your SuperContainer URL:

"http://yourServer.com:8020/SuperContainer/Files/" & Get ( LayoutTableName ) & "/" & ID & "?style=" &
If (Get(PrivilegeSetName) = "[Read-Only Access]" ; "readonly" ; "")

The above appends a "readonly" style name if the FileMaker user is in the Read-Only Access privilege set. You can also use this technique to allow all users to upload, but only admins to delete (by using the nodelete style).