Original Implementation - Alfresco Content Services - 23.4 - 23.4 - Ready - Alfresco - external

The original implementations of the Share web scripts that instantiated client-side widgets have a common pattern:

• The widget is instantiated (sometimes it is assigned to a variable).
• The ${args.htmlid} property is almost always passed as a single instantiation argument.
• A .setOptions(..) function call is chained to the instantiation call. The argument to this call is a single JavaScript object containing all the options to apply to the widget.
• A .setMessages(..) function call is chained to the result of the .setOptions(..) call

The main variables in this process are:

• The fully-qualified name of the widget instantiated
• The name of the variable that the widget is ultimately assigned to
• The options applied to the widget

Not all web scripts are coded this way:

• Not all assign the widget to a variable
• Not all widgets are instantiated with a String as the sole argument
• Not all widgets have additional options applied to them
• Not all widgets have messages applied to them

A template JavaScript object that encapsulated all the metadata that represented the instantiation of a single widget and created a custom FreeMarker directive <@createWidgets/> that could process this object structure and output the JavaScript code that would perform the instantiation.

There are many web scripts, most commonly those that create dashlets, that instantiate more than one widget. Therefore any custom directive developed in the future would need to be able to process multiple metadata objects. Due to this the controller always adds the metadata objects to a list in the FreeMarker model.

So for example, if the following objects were constructed and set in the model:

widgets: [
   {
      name: "Alfresco.Widget1",
      assignTo: "w1",
      initArgs: [ "x", "y" ],
      useMessages: true,
      useOptions: true,
      options: {
         option1: "one",
         option2: two
      }
   },
   {
      name: “Alfresco.Widget2”
   },
   {
      name: “Alfresco.Widget3”,
      useOptions: false,
      useMessages: false
   }
]

This would result in the following JavaScript output:

<scripttype="text/javascript">
   var w1 = new Alfresco.Widget1("w", "y").setMessages(${messages}).setOptions({
   option1: "one",
   option2: "two"
   });
   new Alfresco.Widget2(${args.htmlId}).setMessages(${messages});
   new Alfresco.Widget3(${args.htmlId});
</script>

In the example it has been possible to control exactly how each widget is instantiated:

• Alfresco.Widget1 has explicitly set all properties.
• Alfresco.Widget2 has taken all defaults.
• Alfresco.Widget3 has taken some defaults but has elected not to set options or messages.

Here is a list of the properties that can be set on widget instantiation:

• name: The fully qualified name of the JavaScript widget to be instantiated.
• assignTo (optional): The name of the variable to assign to. Used if additional JavaScript is required to access the widget after instantiation. This can then be used in the post-instantiation JavaScript code.
• initArgs(optional): The majority of widgets take just the unique id assigned to the outer <div> element of the HTML fragment, but this can be changed by providing alternative arguments. This is limited to String values.
• useMessages (optional: defaults to true): Indicates that the i18n messages associated with the WebScript should be passed to the widget by the .setMessages() function call.
• useOptions (optional: defaults to true): Indicates that the options object should be passed to the widget by the .setOptions() function call.
• options (optional: defaults to the empty object): An object containing all the options to pass to the widget in the .setOptions() function call.