Widget: Creating custom widget classes
+ +
+ This example shows how you can mix and match the WidgetPostion, WidgetPositionExt, WidgetStack and WidgetStdMod extensions to build custom versions of the Widget class, using Base.build.
+
-
+
WidgetwithWidgetStdMod+ + +
+
+ WidgetwithWidgetPosition, WidgetStack+ + +
+
+ WidgetwithWidgetPosition, WidgetStack, WidgetPositionExt+ + +
+
Creating Custom Widget Classes
+ +The Base class provides a build method which can be used to create custom versions of classes which derive from Base by adding extension classes to them.
Widget currently ships with four such extensions: WidgetPosition, WidgetStack, WidgetPositionExt and WidgetStdMod.
+These extensions are used to build the basic Overlay widget, but can also be used individually, to create custom versions of the base Widget class.
Widget with WidgetStdMod support
+ +Adding the WidgetStdMod extension to Widget, creates a statically positioned Widget, with support for standard module format sections - header, body and footer, which maybe useful in portal type use cases, where the positioning/stacking capabilities which come bundled with Overlay are not required.
To create a custom class, we use Base.build, which is described in detail on the documention page for Base.
We pass in Widget as the main class we want to add extensions to, and WidgetStdMod as the extension we'd like added to the main class:
Base.build will:
-
+
- Create a new class which extends
Widget
+ - Aggregate known
BaseandWidgetfields, such asATTRSandHTML_PARSERfromWidgetStdModon the new class
+ - Augment prototype methods from
WidgetStdModonto the new class prototype
+
The first argument to build is the NAME of the new class we are creating, just like the NAME we define when extending the Widget class directly.
Note that the Widget class is unchanged, allowing you to still create Widget instances without any standard module support, along with StandardModule instances which have standard module support.
Testing It Out
+ +The example attempts to set content on an instance of the newly created StandardModule class, using the setStdModContent method which is added by the extension (which would otherwise not exist on the Widget instance).
To verify that no unrequested features are added, we also attempt to move the instance using the move method, which is not part of the base Widget class, and would be added by the WidgetPosition extension. This verifies that the other example classes we'll create, which do create new classes which use WidgetPosition, have not modified the base Widget class.
Note that Base.build adds a hasImpl method to the built class, which allows you to query whether or not it has a particular extension applied.
CSS Considerations
+ +We need to define the CSS which goes with this new StandardModule class we have created. The only rule really required out of the box is the rule which handles visibility (yui-standardmodule-hidden). The "standardmodule" used in the class name comes from the NAME property we set up for the new class, and is used to prefix all state related classes added to the widgets bounding box.
+Since the StandardModule class is not positionable, we use display:none to define the hidden state.
The other "yui-standardmodule" rules are only used to create the required look/feel for this particular example, and do not impact the StandardModule widget's functionality.
+ +Widget with WidgetPosition and WidgetStack support
+ +As with StandardModule, we use Base.build to create the new Positionable widget class. This time we add WidgetPosition and WidgetStack support to the base Widget class to create a basic XY positionable widget, with shimming and z-index support.
We don't add WidgetPositionExt or WidgetStdMod support, so the widget doesn't have extended positioning support (align, center) or standard module support. Hence we position it manually using the move method which the WidgetPosition extension provides.
Testing It Out
+ +We should now be able to invoke the move method on an instance of the newly created Positionable class:
And, as with the StandardModule class, we should not be allowed to invoke any methods from an extension which we didn't request:
CSS Considerations
+ +Since now we have a positionable widget, with z-index support, we set the widget to be absolutely positioned by default, and control it's hidden state using visibility as opposed to display
Widget with WidgetPosition, WidgetStack and WidgetPositionExt support
+ +Lastly, we'll attempt to create a new widget class, which, in addition to basic positioning and stacking support, also has extended positioning support, allowing us to align it with other elements on the page.
+ +Again, we use Base.build to create our new Alignable widget class, by combining WidgetPosition, WidgetStack and WidgetPositionExt with the base widget class:
Testing It Out
+ +We'll attempt to align an instance of the Alignable class, using some of the additional attributes which WidgetPositionExt adds to the base Widget class: align and centered:
CSS Considerations
+ +The Alignable widget class, has the same core CSS rules as the Positionable class, to define how it is positioned and how it is hidden: