LookAndFeelView Interface
- public interface LookAndFeelView
extends MarkupBasedView
"Views" are deep copy immutable objects. Unlike "Definitions" and "Instances" Views cannot be modified by the developer.
A Instance or a Definition however can always be obtained from the view. The persistence APIs provides course grain
and fine grain getters but only fine grain setters. If you are interested in an object and all its children then
retrieve the View, if you are only interested in the immediate object and don't care about its children then retrieve the
Definition.
View class for a look-and-feel.
Related Topics
View
-
All Superinterfaces
-
MarkupBasedView
, Serializable
, View
DEFAULT_SKELETON_ID
public static final String
DEFAULT_SKELETON_ID
- The name of the default skeleton.
DEFAULT_SKELETON_PATH
public static final String
DEFAULT_SKELETON_PATH
- The path to the default skeleton.
DEFAULT_SKIN_ID
public static final String
DEFAULT_SKIN_ID
- The name of the default skin.
DEFAULT_SKIN_PATH
public static final String
DEFAULT_SKIN_PATH
- The path to the default skin.
getDefinitionLabel() Method
public String
getDefinitionLabel()
Return the unique moniker given to this look and feel in the look and feel file.
This method will return the same value as the "definitionLabel" label attribute in
the .laf file.
Returns
- a non null label for this look and feel
getLocalizationResourceView() Method
public LocalizationResourceView
getLocalizationResourceView()
The Localization resource contains the localized title and description for this look and feel.
Returns
- a non null LocalizationResourceView customized per the request.
getLookAndFeelDefinition() Method
public LookAndFeelDefinition
getLookAndFeelDefinition()
Retrieve the associated LookAndFeelDefinition
from this LookAndFeel View. LookAndFeel Views are immutable but
LookAndFeelDefinitions are not. Therefore it is often necessary to retrieve the definition from the view in
order to update its values and then in turn call the persistence API. The LookAndFeel Definition is constructed and
updated via it's .laf file. If you create a new .laf file then a new LookAndFeel Definition is created in the
database. If you edit the file the changes are automatically seen in the database. (during dev time we poll
the file system and in production we update the database whenever the webapp is redeployed.
Returns
- a non null LookAndFeel Definition
getLookAndFeelDefinitionId() Method
public LookAndFeelDefinitionId
getLookAndFeelDefinitionId()
Getter for lookandfeel definition id. The lookandfeel id is the primary key value for the
lookandfeel definition in the PF_LOOK_FEEL_DEFINITION table. Unlike Book Pages and Portlets LookAndFeels
do not have instances. The admin or end user can still change his or her lookandfeel but they
are customizing the desktop not the lookandfeel.
Returns
- a non null unique definition id. This value should never be null as views are constructed
via the persistence API.
getLookAndFeelFile() Method
public String
getLookAndFeelFile()
Retrieve the file name used to create this look and feel. Look and feels are
created via .laf files
Returns
- the file name associated with this look and feel.
getWebAppName() Method
public String
getWebAppName()
Return the name of the webapp that this look and feel is associated with. All resources in the portal framework database
are scoped to the webapp.
Returns
- a non null webapp name.
isDeleted() Method
public boolean isDeleted()
If isDeleted is true then the look and feel has been removed from the file system. It was not out right deleted
from the database because it is in use by some desktop somewhere in the system. Either
restore the file and this flag will go back to false or remove/replace this look and feel via the admin tools.
If this flag is set on an object the admin tools will display the object with a different icon to denote that
it has been removed from the file system
Returns
- true if this file hase been deleted from the files system.