In this example, i have used five different mode for widget in websphere portal server.
In view:
I am displaying ,Company name as IBM.
From Edit mode to View mode,Company name is changed from IBM to HP.
In view:
I am displaying ,Company name as IBM.
From Edit mode to View mode,Company name is changed from IBM to HP.
HelloWidget.xml
<?xml version="1.0" encoding="UTF-8" ?>
<iw:iwidget name="HelloWidget" id="HelloWidget" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:iw="http://www.ibm.com/xmlns/prod/iWidget"
supportedModes="view edit config personalize help" lang="en" iScope="HelloWidgetScope">
<iw:resource src="HelloWidget.js" id="jsId" />
<iw:itemSet id="attributes">
<iw:item id="company" value="IBM"/>
</iw:itemSet>
<iw:content mode="view">
<![CDATA[
<div>Entering into View Mode</div>
<div id="companydis"></div>
]]>
</iw:content>
<iw:content mode="edit">
<![CDATA[
<div>Entering into edit Mode
<input type="button" value="Switch to primary view" onclick="iContext.iScope().switchView('view');" />
</div>
]]>
</iw:content>
<iw:content mode="config">
<![CDATA[
<div>Entering into config Mode</div>
]]>
</iw:content>
<iw:content mode="personalize">
<![CDATA[
<div>Entering into personalize Mode</div>
]]>
</iw:content>
<iw:content mode="help">
<![CDATA[
<div>Entering into help Mode</div>
]]>
</iw:content>
</iw:iwidget>
HelloWidget.js
dojo.declare("HelloWidgetScope", null,{
onLoad:function() {
},
onUnload:function() {
},
/*
This event signals that the mode for the iWidget has changed to VIEW
*/
onView:function() {
var element=this.iContext.getElementById("companydis");
var selectedValue=this.iContext.getiWidgetAttributes().getItemValue("company");
element.innerHTML=selectedValue;
},
/*
This event signals that the mode for the iWidget has changed to EDIT
*/
onEdit:function() {
this.iContext.getiWidgetAttributes().setItemValue("company","HP");
this.iContext.getiWidgetAttributes().commit();
},
/*
This event signals that the size for the iWidget has changed
*/
onSizeChanged:function(/*com.ibm.mashups.iwidget.IEvent*/ event) {
var newWidth = event.payload.newWidth;
var newHeight = event.payload.newHeight;
},
/*
This event can be generated by either the iWidget, supplying a new
value for its "navigational state", or by the iContext, signaling
that some user action has changed the iWidget's "navigational state"
to a previously defined value.
*/
onNavStateChanged:function(/*com.ibm.mashups.iwidget.IEvent*/ event) {
},
switchView:function(newView)
{
this.iContext.iEvents.fireEvent("onModeChanged",null, "{newMode:'"+newView+"'}");
}
}
);
WebDAV
Register HelloWidget.xml with portal server
ConfigEngine register-iwidget-definition -DIWidgetDefinition=dav:fs-type1/iwidgets/HelloWidget.xml -DWasPassword=wasadmin -DPortalAdminPwd=wasadmin
Behaviour IWidget in websphere portal server:
When you register an iWidget in your portal, most sections of the iWidget definition and microformat are stored in the portal model as portlet preferences of a copy or clone of the IWidgetWrapper portlet.
Each iWidget definition corresponds to a distinct copy of that portlet. The portlet preferences carry a prefix com.ibm.portal. This identifies them as parameters that are used internally. Values of iWidget attributes, that is items of the attributes item set of an iWidget are stored without prefix. Instead, the item identifier is used as a key to the item value. This way you can easily distinguish iWidget attributes from other preferences when you want to customize their values after registering an iWidget in your portal. This is useful to preconfigure an iWidget definition that is integrated on different portal pages by using the corresponding iWidget microformats.
Another important aspect of iWidget attributes and their corresponding portlet preferences in the portal model is that the update behavior can be specified, which allows for use cases when you want to retain customization across updates of an iWidget definition.
Each iWidget definition corresponds to a distinct copy of that portlet. The portlet preferences carry a prefix com.ibm.portal. This identifies them as parameters that are used internally. Values of iWidget attributes, that is items of the attributes item set of an iWidget are stored without prefix. Instead, the item identifier is used as a key to the item value. This way you can easily distinguish iWidget attributes from other preferences when you want to customize their values after registering an iWidget in your portal. This is useful to preconfigure an iWidget definition that is integrated on different portal pages by using the corresponding iWidget microformats.
Another important aspect of iWidget attributes and their corresponding portlet preferences in the portal model is that the update behavior can be specified, which allows for use cases when you want to retain customization across updates of an iWidget definition.
ScreenShots
Click here to download the code
No comments:
Post a Comment