Version 5.1
Applications |
|---|
| ||||||||||
|
|
Version 5.1 |
||||||||||||||||||||||||||||||||
|
|
The Web Application Server allows users to "log in", providing a name of some CommuniGate Pro Account and the account password. For each successful login, a Session is started. The session keeps the information about user actions and requests, so all HTTP requests sent to the same session can share and use the same set of session data. To maintain a session, all session requests have URLs in the following form:
The Web Application Sessions have time-out counters. If no HTTP request has been sent to a session during the configurable time-out interval, the Session is closed. The session user can close the session by sending a request for the special Bye page.
The CommuniGate Pro software comes with one Unnamed Stock Skin, providing the very basic and simple HTML and WML interface. It also comes with some Named Stock Skins that provide more visually rich interfaces. This Stock Skins are stored in the application directory, they are parts of the software package, and they should not be modified by server administrators.
CommuniGate Pro installations can also use Unnamed and Named custom Skins. Custom Skins can be created as Server-wide Skins. These custom Skins are available to all users. Each CommuniGate Pro Domain can also have its own set of custom Skins, available only to the users of that Domain.
When a user connects to the Web User Interface service (the HTTP User port), the hostname string specified in a stateless request URL is used to find the CommuniGate Pro Domain. When the Domain is found, its Default Account WebUser Preferences are retrieved and the SkinName (Layout) and Language Settings are used.
The SkinName Setting specified the name of the Skin to use (if that Setting is empty, the Unnamed Skin is used).
If the Skin with the specified Name is not found in the set of the Domain Skins, the Server-wide Skin sets are checked. If the Skin with the specified name is still not found, the Stock Skin with this name is used. If the Named Stock Skin is not found either, the Unnamed Stock Skin is used.
Since Domains can have their own Skin sets, the same request sent to different Domains can display different pages: the Default WebUser Preferences can specified different Skin Names in different Domains, and even if the Preferences are the same, different Skins with the same name can exist in different Domains.
Stateless requests can use any Skin available for the addressed Domain. To use an alternative Skin, a Stateless HTTP request should specify the Skin name using the Skin request parameter.
The Language Setting retrieved from the Domain effective Default Account WebUser Preferences specifies the language to use on the stateless page. To use an alternative language, a Stateless HTTP request should specify the language name using the Language request parameter.
Session-based HTTP requests do not use the hostname string specified in the URL.
Instead, when a user logs in, and a Web Application session is created for the specified
CommuniGate Pro Account, the effective Account WebUser preferences are retrieved.
Those preferences contain the name of the Skin to use (an empty value specifies an Unnamed Skin).
The Skin with the specified name is selected from the Skin set of the Account Domain
(note that the Domain specified with the request URL can be different).
If the Account Domain does not have the specified Skin, the Server-wide Skin is used.
Session-based HTTP requests use the Language specified with the Account WebUser Preferences.
The HTTP module checks the content of the Accept request header field. If this field contains a wml substring, the module assumes that the request comes from a WML browser.
Requests coming from WML browsers are processed using WML Skins. For Stateless requests the name of the Skin to use is taken from the WAP/WML Layout parameter of the Default WebUser Preferences for the addressed Domain. When a user logs in using a WML browser, the name of the Session Skin to use is taken from the WAP/WML Layout parameter of the WebUser Preferences for the user Account.
All Skins with names starting with letters WML are considered to be WML Skins. These Skins appear in the list of available Skins for the WAP/WML Layout parameters, and these Skins are removed from the list of available Skins for the regular Layout parameters.
The HTTP module checks the content if the User-Agent request header field.
If this field contains a DoCoMo substring, the module assumes that the request comes from a Japanese I-Mode browser.
If this field contains a portalmmm substring, the module assumes that the request comes from a European I-Mode browser.
I-Mode requests are processed with special I-Mode Skins in the same was as WML requests are processed with WML Skins. The special I-Mode/cHTML WebUser Preferences parameter is used to specify the name of the I-Mode Skin to use.
All Skins with names starting with letters IMode are considered to be cHTML Skins. These Skins appear in the list of available Skins for the I-Mode/cHTML Layout parameters, and these Skins are removed from the list of available Skins for the regular Layout parameters.
For all pages retrieved for Japanese cHTML browsers the charset is set to Shift-JIS, and all pages are converted into
that charset.
For all pages retrieved for European cHTML browsers the charset is set to windows-1252, and all pages are converted into
that charset.
Initially, when no Domain has any custom Skin, and the Server-wide Skins are empty, all Domains
can use the Stock Skins only. The Unnamed Skin is selected by default.
By uploading files into the Server-wide Unnamed Skin, the Server Administrator can "shadow" the Unnamed Stock Skin files,
and this can change the application look and feel for all Domains.
By uploading files into the Unnamed Skin of some CommuniGate Pro Domain, the Server
or Domain Administrator can "shadow" the Stock Skin and Server-wide Unnamed Skin files and change the
look and feel for that particular Domain.
This hierarchy allows Server and Domain Administrators to use new Skins that are designed "from scratch", or to develop small Skin variation, re-using the already existing Skins.
The Dynamic Cluster installations have two sets of the Server-wide Skins - one set is used for local Server Domains, while the other, Cluster set is used for all Shared Domains in the Cluster. Modifications of these Cluster-wide Skins, as well as modifications of any Skin in any Shared Domain are automatically distributed to all Cluster Members.
A Skin can contain additional, localized Text Dataset files - language.data files, where language is the language name (french.data, japanese.data, etc.). If a non-default language is selected, the Text Dataset from the specified language file is used.
When the selected Text Dataset of the selected Skin does not contain the requested data, the same language Text Datasets are checked in all Skin "parents" (as specified above). If the requested data is still not found, the "default language" Text Dataset is used.
Use the UTF-8 character set to place non-ASCII symbols strings into a Text Dataset file. Check the http://www.unicode.org site to learn more about Unicode and the UTF-8 charset.
The specified file names are always converted into the lowercase letters.
When the Web Application module receives a request for the same file, it is retrieved from the Skin Cache.
If the file has been requested using a Session-based URL, the session time-out counter is reset. This can be used to create a frame in the client browser window, and make that frame periodically retrieve some file using the session URL. As a result, this session inactivity timer can be reset to keep the session alive as long as this frame is displayed in the user's browser.
System and Domain administrators can upload custom files into server-wide and Domain Skins to
modify the Web Application look and feel.
For example, the Stock Skin uses the Logo.gif file for most of its pages. By uploading
a custom Logo.gif file to a server-wide Unnamed Skin you can change the look of the Web Application
pages even without creating and uploading custom page (WSSP) files.
To include a file reference to into a .wssp page retrieved with a Stateless request, use the %%filesRef%% prefix in the .wssp code:
Sessions can used Named Skins, and the session-based pages usually need to refer to regular files in the same Skin. References in the "session realm" (HREF="filename.extension" or HREF="/Session/sessionID/filename.extension" work, but they do not allow client browsers to cache these files between sessions, since each session has its own sessionID, and file URLs are different for each session. To allow client browsers to cache regular files, use the %%SESSION(filesRef)%% prefix for file URLs:
The specified resource names are always converted into the lowercase letters.
The WSSP Scripting section explains the WSSP file format. System and Domain administrators can create custom WSSP files and upload them to the server-wide and Domain Skins to modify the Web Application look and feel.
The section below lists the available Web Application code components, defining the set of WSSP pages that this version of CommuniGate Pro server can generate. It specifies how each component processes the form parameters sent to it, and what data is included into the dataset it generates.
To manage the Server-wide and Cluster-wide Skins, open the Domains realm of the WebAdmin Interface, and click the Skins link.
To manage the Domain Skins, open that Domain page in the Domains realm of the WebAdmin Interface, and click the Skins link. The Domain Administrator should have the CanModifySkins Access Right to be able to create and modify the Domain Skins.
When the Domain Skins Editor page is opened, and there is no Unnamed Skin for the Domain, the page contains the Create Unnamed Skin button. Click this button to create the Unnamed Skin for this Domain.
The Skin Editor page contains the list of all files "visible" in this Skin: it lists files directly uploaded to this particular Skin, as well as all files uploaded to the Skins used as the "default files" source for this Skin:
Files directly uploaded to the Skin have a checkbox in the Marker column. Files from the other skins "visible" in this Skin have the word default in that column.
You can download any of the Skin files by clicking the file name.
You can upload a file to the Skin by clicking the Browse button and selecting a file on your workstation, then clicking the Upload button.
You can delete any of the files uploaded to the Skin by selecting the checkboxes and clicking the Delete Marked button.
If you are uploading a .wssp or a .wssi file, the Editor tries to compile that file first. If the compiler parser detects an error, the file is not uploaded, the source of the file is displayed on the Editor page, with the red <--ERROR--> marker indicating the location of the error.
When you upload a file to any Skin, that Skin cache is automatically cleared. If you upload a file to a Shared Domain Skin or to a Cluster-wide Skin, the update automatically propagates to all Cluster Members.
You can upload a set of files by uploading a TAR-archive (a file with .tar name extension). For example, when you have a TAR-archive with a predesigned Skin you can open the Skin you want to modify (the Server-wide Unnamed Skin or Domain-wide Unnamed Skin or some Named Skin), and upload the .tar file. The Server will unpack the archive and store each file individually, as if they were uploaded one-by-one.
The Editor page for the Unnamed Skin contains the list of all Named Skins:
To create a Named Skin, enter its name, and click the Create Skin button.
To remove Named Skins, use the checkboxes to select the Skins, and then click Remove Marked button. Only empty Skins (Skins without any files) can be removed.
To remove the Unnamed Skin, remove all its files and all Named Skins, and then click Remove Unnamed Skin button.
To open a Skin, click its name. The Editor will display the Skin Name, and it will provide the UP link to the Unnamed Skin page.
The Named Skin Editor allows you to rename the Skin by entering a new Skin Name and clicking the Rename Skin button.
For example, when a Domain default page is requested, the code component called and it produces a dictionary that contains keys such as canAutoSignup, hasMailLists, hasCertificate.
The Web Application module then uses the script code from a WSSP file to convert this data into into an HTML or other markup language page.
This section lists the available CommuniGate Pro code components, specifies when those components are called, explains how the code components process the <FORM> parameters, and specifies the content of the dataset produced by each code component.
The Web Application module checks the Skin HTTP parameter for all Stateless requests. If this parameter exists, the module tries to open a Named Skin with the specified name, otherwise the Unnamed Skin (for the addressed Domain) is used.
The Web Application module checks the Language HTTP parameter for all Stateless requests. If this parameter exists, the module uses it to selected a non-default Text DataSet for the selected Skin.
The Web Application module places certain data into datasets produced with all Stateless Requests code components. The following list specifies these "generic" dataset elements that can be used with all Stateless WSSP pages:
The following sections specify the Stateless URLs, the name of the code component called, the actions taken by the component, the dataset produced with that component, and the name of the WSSP file used to produce the HTTP response.
these URLs are used to process Login operations.
If the request has the DisableIPWatch parameter, the "Fixed IP Address" security feature will be disabled for this session, even if the Account WebUser preferences enable it.
If the request has the DisableUseCookie parameter, the "Use Cookies" security feature will be disabled for this session, even if the Account WebUser preferences enable it.
If the request has SessionSkin parameter with a string value not equal to *, the session is opened using the Skin specified with this parameter. The Skin is searched in the Domain of the logged-in user (which can be different than the Domain used to display the Login page).
If login operation was successful, the HTTP Redirect response is returned, with the Redirect URL pointing to the StartPage wssp page within a newly created Session. The StartPage is specified as the StartPage (wStartPage for WML sessions) Skin string.
If login operation was successful, but the request contained the restoreSessionPage parameter, the resume.wssp (wresume.wssp for WML sessions) page is displayed (as a Stateless one). The Result Dataset for this page contains:
this URL is used to process Password Recovery operations.
this URL is used to process Auto-Signup operations.
The component checks if the request contains one or more PublicInfo string parameters.
The value of the parameter must be one of the Public Info Attributes specified in the
Directory Integration settings. The component than checks if
there is a non-empty request parameter with this name, and adds the parameter value to the
initial Account settings.
Example: to provide a City field on the Auto-Signup
page, include the <INPUT type="hidden" name="PublicInfo" value="City"> control
and the <INPUT type="text" name="City" value="" size=30 maxLength=255> control into
the Signup.wssp HTML code.
If an Account has been created, a new WebUser Session is created, and a request for the "entry page" is sent to the Session (see above).
this URL is used to retrieve the list of the browsable Domain Mailing Lists.
The code component actually uses the generic Mailbox Code Component.
The component checks if the HTTP request contains the PrevMessage parameter with a numeric value. If it exists, the value is interpreted as the unique message ID in the list archive mailbox, and the component tries to find this message in the selected mailbox "view", and tries to find the previous message in the view.
If the next or previous message is found, its UID is added to the dataset (see below) and the generic Mailbox component is not used for processing.
If no next/previous message is found, the generic Mailbox component is used to process the HTTP request parameters and to compose the resulting dataset.
the generic Mailbox code component is used to generate the rest of the resulting dataset.
The code component actually uses the generic Message Code Component.
|
These WSSP pages are processed using datasets generated for all Stateless requests, with the following additional elements:
The disconnected.wssp page is used when an HTTP request was sent to a WebUser Session, but the session has not been found. The page is processed using a dataset generated for all Stateless requests.
HTTP requests to the "Session realm" (requests with URLs started with /Session/) are processed as Session Requests. The second component of the Session Request URL is a unique Session ID, the HTTP module uses it to find the WebUser session.
If the specified session is not found, or the Session has the Fixed Network Address option set, and the HTTP request did not come from the same IP address as the Login request that started the session, the disconnected.wssp page is displayed (see above).
After the Session is found, the Web Application module processes the rest of the request URL as the "request inside this session realm". If the request URL specifies a regular file, that file is retrieved from the Session Skin, and it is sent back to the user browser.
For each .wssp request a code component is called. It processes the HTTP request parameters and generates a result dataset. Then the .wssp file is retreived from the Skin, and it is used to compose the HTTP response.
If the result dataset does not contain the blockAlerts element, the Web Application module checks if there is a pending Alert for the session user. If one or several pending alerts are found, the Alerts code component is called, and the Alerts.wssp file is used to compose the HTTP response.
The Web Application module checks for certain HTTP request parameters and processes them for all .wssp page requests. The following list specifies these "generic" actions:
The Web Application module places certain data into datasets produced with all Session Requests code components. The following list specifies these "generic" dataset elements that can be used with all Session WSSP pages:
If a .wssp request specifies an unknown code component, but the .wssp file with the specified name can be retrieved from the Session Skin, that .wssp file is processed using the dataset with the "generic" elements only, and the result is sent back to the user browser.
The following sections specify the names of existing code components (names for .wssp requests), the actions taken by these component, and the dataset produced with these components.
The code component results are processed using the .wssp files with the same names as the code component names.
Actions
If the HTTP request contains the Create parameter and the NewName parameter is a non-empty
string, the component tries to create a mailbox with the specified name. If this operation fails,
the errorCode element with the error code text is added to the result dataset. If the mailbox
is created, the messageCode element with MailboxCreated string value is added to
the result dataset, and the created mailbox name is added to the list of subscribed mailboxes, if the
Show Subscribed Mailboxes option is selected in the Account WebUser Preferences.
If the request contains the newClass parameter, then the created mailbox is set to the specified class.
If the HTTP request contains the Filter parameter, only the mailboxes with names containing this parameter value are included into the list.
Result Dataset
The code component creates a list of all Account Mailboxes and Mailbox Aliases (if the Show All Account Mailboxes option is selected in the Account WebUser Preferences), or the list of all subscribed mailboxes (if the Show Subscribed Mailboxes option is selected). If both options are selected, these two lists are merged into one.
The HTTP request must contain the Mailbox parameter - the name of the Mailbox to be displayed.
Actions
For each Mailbox, the module creates a session object that contains the Mailbox view parameters. When the object is created, these parameters are initiated with the Web User Preferences values.
The HTTP request Msg parameters are interpreted as "message set elements". A request can contain several parameters, and each parameter should have a numeric value - the Unique ID of a Mailbox message.
If the HTTP request contains the Forward or Redirect parameter and the RedirectAddresses
parameter is not empty, a "message set" is composed using the Msg parameters, and the message set messages are
forwarded or redirected to the specified addresses.
If the HTTP request contains the ListApprove parameter and the mailbox is an "approval" or "requests" mailbox for some mailing list,
the request is processed as the Redirect request with the effective address being the mailing list address or the "subscription" request for that list.
If the operation has been successful,
the messageCode element with the MessagesForwardedInfo or MessagesRedirectedInfo string value
is added to the result dataset. Otherwise, the errorCode element with the operation
error code string value is added to the result dataset.
If the HTTP request contains the Copy or Move parameter and the MailboxName
parameter contains a name of some selectable mailbox, a "message set" is composed using the Msg parameters,
and the message set messages are copied to the specified mailbox. If the Move parameter was
specified, the message set messages are marked as Deleted, deleted, or moved to Trash - depending on the
WebUser Preferences.
If the operation has been successful,
the messageCode element with the MessagesCopiedInfo string value
is added to the result dataset. Otherwise, the errorCode element with the operation
error code string value is added to the result dataset.
If the WebUser Preferences DeleteMethod option is set to Move To Trash, and the HTTP request contains the Delete parameter, a "message set" is composed using the Msg parameters, the message set messages are copied to the Trash mailbox and deleted. If the Trash mailbox did not exist, it is created.
If the HTTP request contains the DeleteAll parameter, all mailbox messages are deleted, using the method specified with the WebUser Preferences DeleteMethod option.
If the HTTP request contains the read, unread, flag, unflag, delete, or undelete
parameters, a "message set" is composed using the Msg parameters, and
the flags for the message set messages are modified. The delete and undelete parameters
are processed in this way only if the WebUser Preferences DeleteMethod option is not set to Move To Trash.
If the operation has not been successful, the errorCode element with the operation
error code string value is added to the result dataset.
If the WebUser Preferences DeleteMethod option is not set to Move To Trash, and
the HTTP request contains the Purge parameter, all mailbox messages with the Deleted
flag are deleted.
If the operation has not been successful, the errorCode element with the operation
error code string value is added to the result dataset.
If the HTTP request contains the NextMessage parameter with a numeric value, the value is interpreted as the unique ID (UID) of a mailbox message, and the component tries to find the next mailbox message. If such a message is found, its UID is added to the Result Dataset as the messageJump element.
If the HTTP request contains the PrevMessage parameter with a numeric value, the value is interpreted as the UID of a mailbox message, and the component tries to find the previous mailbox message. If such a message is found, its UID is added to the Result Dataset as the messageJump element.
If the HTTP request contains the NextUnread parameter and the mailbox contains an unread message, the UID of that unread message is added to the Result Dataset as the messageJump element.
If the messageJump element was not added to the Result Dataset, the code component uses the generic Mailbox component to process the HTTP request parameters and to compose the resulting dataset.
Result Dataset
The generic Mailbox code component is used to generate the rest of the resulting dataset.
Processed in the same way as the Mailbox page.
Processed in the same way as the Mailbox page.
The HTTP request must contain the Mailbox parameter - the name of a Calendar-type mailbox to be displayed.
Actions
For each mailbox, the module creates a session object that contains the mailbox view parameters. When the object is created, these parameters are initiated with the Web User Preferences values. The object also contains the month number for the "monthly calendar" view. It is initially set to the current month. The object contains the day number that specifies the first day to be displayed in the Calendar view. The object also contains the "byDay" flag that controls how the calendar data is stored in the dataset (by days or by time intervals).
The HTTP request prevMonthlyCalendar parameter can specify the number of months to be substructed from the "monthly calendar" month number.
The HTTP request nextMonthlyCalendar parameter can specify the number of months to be added to the "monthly calendar" month number.
The HTTP request JumpDay parameter can specify the "day number in the epoch" that will become the first day to be displayed in the Calendar view.
The HTTP request byDay parameter can specify the new byDay flag value.
The HTTP request Msg parameters are interpreted as "message set elements". A request can contain several parameters, and each parameter should have a numeric value - the Unique ID of a mailbox message.
If the WebUser Preferences DeleteMethod option is set to Move To Trash, and the HTTP request contains the Delete parameter, a "message set" is composed using the Msg parameters, the message set messages are copied to the Trash mailbox and deleted. If the Trash mailbox did not exist, it is created.
If the HTTP request contains the read, unread, flag, unflag, delete, or undelete
parameters, a "message set" is composed using the Msg parameters, and
the flags for the message set messages are modified. The delete and undelete parameters
are processed in this way only if the WebUser Preferences DeleteMethod option is not set to Move To Trash.
If the operation has not been successful, the errorCode element with the operation
error code string value is added to the result dataset.
If the WebUser Preferences DeleteMethod option is not set to Move To Trash, and
the HTTP request contains the Purge parameter, all mailbox messages with the Deleted
flag are deleted.
If the operation has not been successful, the errorCode element with the operation
error code string value is added to the result dataset.
Result Dataset
The "Event elements" are:
The HTTP request must contain the Mailbox parameter - the name of a Tasks-type mailbox to be displayed.
Actions
For each mailbox, the module creates a session object that contains the mailbox view parameters. When the object is created, these parameters are initiated with the Web User Preferences values. The object contains the day number that specifies the first day to be displayed in the Tasks view.
The HTTP request JumpDay parameter can specify the "day number in the epoch" that will become the first day to be displayed in the Tasks view.
The HTTP request Msg parameters are interpreted as "message set elements". A request can contain several parameters, and each parameter should have a numeric value - the Unique ID of a mailbox message.
If the WebUser Preferences DeleteMethod option is set to Move To Trash, and the HTTP request contains the Delete parameter, a "message set" is composed using the Msg parameters, the message set messages are copied to the Trash mailbox and deleted. If the Trash mailbox did not exist, it is created.
If the HTTP request contains the read, unread, flag, unflag, delete, or undelete
parameters, a "message set" is composed using the Msg parameters, and
the flags for the message set messages are modified. The delete and undelete parameters
are processed in this way only if the WebUser Preferences DeleteMethod option is not set to Move To Trash.
If the operation has not been successful, the errorCode element with the operation
error code string value is added to the result dataset.
If the WebUser Preferences DeleteMethod option is not set to Move To Trash, and
the HTTP request contains the Purge parameter, all mailbox messages with the Deleted
flag are deleted.
If the operation has not been successful, the errorCode element with the operation
error code string value is added to the result dataset.
The HTTP request showCompleted parameter can specify the new showCompleted flag value.
Result Dataset
The HTTP request must contain the Mailbox parameter (the name of the mailbox containing the messages to be displayed), and the MSG parameter - the Unique ID of that message in the mailbox.
If the HTTP request contains the Redirect parameter and the RedirectAddresses
parameter is not empty,the message is redirected to the specified addresses.
If the HTTP request contains the ListApprove parameter and the message mailbox is an "approval" mailbox for some mailing list,
the request is processed as the Redirect request with the effective address being the mailing list address.
If the operation has been successful,
the messageCode element with the MessageRedirected string value
is added to the result dataset. Otherwise, the errorCode element with the operation
error code string value is added to the result dataset.
If the HTTP request contains the TakeAddress parameter the message From: address is added to the Account address book.
If the HTTP request contains the TakeCertificate parameter the certificate from the message digital signature is added to the Account address book.
If the HTTP request contains the StoreFiles parameter and the selectedWebFolder
parameter contains a name of the File Storage folder, the file parts of the message (attachments, images) are stored
in the specified folder.
If the operation has been successful,
the messageCode element with the FilesCopied string value
is added to the result dataset. Otherwise, the errorCode element with the operation
error code string value is added to the result dataset.
If the HTTP request contains the read, unread, flag, unflag, delete, or undelete
parameters, the message flags are modified.
If the operation has not been successful, the errorCode element with the operation
error code string value is added to the result dataset.
Then the code component use the generic Message component to process the HTTP request parameters and the compose the resulting dataset.
The optional Operation HTTP request parameter specifies the type of the
Compose operation and it can have the Reply, ReplyAll, Forward, or EditDraft value.
If this parameter is specified, the OrigMessage parameter (with the UID of the
original message) and the OrigMailbox parameter (with the name of the mailbox containing
the original message) must be specified.
If the HTTP request contains the Operation parameter and it does not contain the filled parameter,
the original message header fields are used to compose the Subject, To, Cc, and the message body data for the new message.
Otherwise, the Subject, To, Cc, Bcc, and Body HTTP request parameters are
used as the new message data.
If the HTTP request contains the AddressBook parameter and it does not contain the CloseBook parameter, or if HTTP request contains the OpenBook parameter the generic AddressBook code component is used to process the request parameters and to form some result dataset elements.
If the HTTP request contains the isEvent parameter, the Calendar Event item is being composed. If the HTTP request contains the isTask parameter, the Calendar Task (ToDo) item is being composed. If the HTTP request contains the isNote parameter, the Note item is being composed.
If the HTTP request contains the Send parameter, the composed message is submitted
to the Server Queue. If the HTTP request contains the Save parameter, the composed
message is stored as a Draft in the selected Drafts mailbox.
In both cases all HTTP request Attachment parameters are added to the message
as attachments.
The following elements are added if the item being composed is a Calendar item:
The HTTP request must contain the Mailbox parameter - the name of the mailbox to manage.
If the HTTP request contains the Rename parameter and the NewName parameters
is not empty, the mailbox is renamed. The NewName parameter value is converted into the "UTF-7 Mailbox Name encoding"
format and is used as the new mailbox name.
If the HTTP request also contains the RenameSub parameter, all mailbox submailboxes
are renamed, too.
If the operation has been successful and the Show Subscribed Mailboxes option is selected
in the WebUser Preferences, the renamed mailbox(es) are renamed in the Account subscription list.
If the operation has been successful, the removed element with the Yes string
value is added to the result data set and the code component stops request processing. Otherwise,
the errorCode element with the operation
error code string value is added to the result dataset.
If the HTTP request contains the Update parameter, the code component retreieves all
Acc parameters from the request. Each Acc parameter should have a numeric value.
For each retreieved Acc parameter value nnn, the Znnn parameter is
retrieved. If it contains a non-empty string, all Knnn request parameters are retrieved,
where K is a mailbox access right letter.
The list of Znnn name strings with their Knnn parameter sets are used to
form and set the new ACL list for the selected mailbox.
If the ACL update operation has been successful,
the messageCode element with the Updated string value
is added to the result dataset. Otherwise, the errorCode element with the operation
error code string value is added to the result dataset.
If the HTTP request contains the DeleteAll parameter, all mailbox messages are deleted, using the method specified with the WebUser Preferences DeleteMethod option. If the operation has been successful, the messageCode element with the MessagesDeleted string value is added to the result dataset.
This code component can be called implicitly, if the Web Application module has detected a pending Alert message.
If the HTTP request contains the returnURL parameter, the parameter value is added to the result dataset (as the returnURL element).
If the HTTP request contains the Update parameter:
If the password has been updated successfully, the messageCode element with the PasswordChanged string value is added to the result dataset. If the password update operation failed, the errorCode element is added to the result dataset.
If the Public Info settings have been updated successfully, the messageCode element with the Updated string value is added to the result dataset. If the password update operation failed, the errorCode element is added to the result dataset.
The code component uses the generic WebSite component to process the HTTP parameters and to form the result dataset. Before the generic component is called, the following elements are added to the result dataset:
If the HTTP request parameter Skip exists, it should have a numeric value. This number is used to set the current first message index - the number of the first message to be displayed on this page.
If the HTTP request contains the parameter Next, then the current first message index is increased by the current Limit value.
If the HTTP request contains the parameter Prev, then the current first message index is decreased by the current Limit value.
If the HTTP request contains the parameter Sort, its numeric value specifies the number of "sorting" column (to sort the mailbox view by the first column, the Sort parameter should be 0).
If the HTTP request contains the parameter SDir, its numeric value specifies the sorting order: the value 1 requests ascending order, the value 0 - descending order, the value -1 reverses the current sorting order.
The generic Message component is used to convert the an RFC822 message into an HTML text. It processes simple and multi-part messages, attachements, digests, inline images and other letter components. To build a HTML presentation, the component uses Code Components for Message Rendering.
Message Rendering code components do not perform any actions.
A Result Dataset produced by every Message Rendering code component includes the following fields:
The following Message Rendering code components are implemented:
This code component is used to render a mail message - a message stored in a mailbox or a message/rfc822 MIME subpart of some other message.
Result Dataset
This code component is used to render an RFC822 mail message header.
Result Dataset
This code component is used to render an image or an attachment. Images and attachments can be separate MIME parts, or can be embedded into text parts using UUENCODE encoding.
Result Dataset
This code component is used to render a message/report MIME subpart.
Result Dataset
This code component is used to render a message/disposition-notification MIME subpart.
Result Dataset
This code component is used to render an encrypted MIME subpart.
Result Dataset
This code component is used to render a signed MIME subpart.
Result Dataset
This code component is used to render an iCalendar subpart.
Result Dataset
This code component is used to render an vCard subpart.
Result Dataset
The Server returns the 301 ("Moved") response code with the Location header containing the specified URL.
The Server also processes the <RELREDIRECT> tag at the beginning of the document. It is processed in the same way as the <REDIRECT> tag, but the URL placed into the Location header is prefixed with the http or https prefix, the server name (and, optionally, port number) retrieved from the request URL.