Class |
Description |
AConditionType
|
Condition Type interface. Condition Types are needed for two reasons: 1) To determine whether whether a condition of its type is met. This involves finding the current value and comparing it to the condition's value. For example: Checking to see whether a condition the user's IP address involves getting the current user's IP Address from the http request and checking to see if it matches the IP Address stored in the expression. 2) Display the conditions of its type that have been created. Each expression contains a list of conditions, one for each condition type. The list for conditions of a certain type could have a display as simple as a textbox with the condition value inside, or more elaborate involving a tree picker and row icons. |
AGuestConditionType
|
There are two things to consider before deciding whether to extend the AGuestConditionType or the ARegularConditionType: 1) Will conditions of this type be used to determine which subportal with a particular guest to use when there is no valid session available? The reason is that certain condition types does not make sense during the Guest/Login Phase. For example, a condition on the user's group has no meaning during the Guest/Login Phase since no user is logged in yet. A condition on the client's IP address would be valid since this has meaning on bothe the Guest/Login and the Regular Phase. 2) Is the Activity Space NOT needed to get the current value of the condition type? A condition the current community a user is on needs the activity space to determine the current value. However, during the Guest/Login Phase, the activity space has not been initialized. Therefore, there is no way to determine what community the user is in. Since the current value cannot be determined during the Guest/Login Phase, a condition on community is only valid during the regular Phase. A condition on the URL Domain, on the other hand, only needs the XPRequest to figure out its current value. Therefore, it is safe to have a condition on the user's URL domain during the Guest/Login Phase. |
ARegularConditionType
|
There are two things to consider before deciding whether to extend the AGuestConditionType or the ARegularConditionType: 1) Will conditions of this type be used to determine which subportal with a particular guest to use when there is no valid session available? The reason is that certain condition types does not make sense during the Guest/Login Phase. For example, a condition on the user's group has no meaning during the Guest/Login Phase since no user is logged in yet. A condition on the client's IP address would be valid since this has meaning on bothe the Guest/Login and the Regular Phase. 2) Is the Activity Space NOT needed to get the current value of the condition type? A condition the current community a user is on needs the activity space to determine the current value. However, during the Guest/Login Phase, the activity space has not been initialized. Therefore, there is no way to determine what community the user is in. Since the current value cannot be determined during the Guest/Login Phase, a condition on community is only valid during the regular Phase. A condition on the URL Domain, on the other hand, only needs the XPRequest to figure out its current value. Therefore, it is safe to have a condition on the user's URL domain during the Guest/Login Phase. |
ConditionTypeManager
|
|
ValidationFailedException
|
An Exception used by ConditionType objects. It is thrown when the value retrieved by the GetConditionValue() method in AConditionType is invalid. |
XPLimitedRequest
|
Wrapper class for the XPRequest in the openfoundation jar. This class does everything except for certain methods which reads the body of the request and causes the gateway to fail. |