Save as widget

I played a bit with SaveAsWidget and I have some ideas:

(1) Only allow SaveAsWidget on a selected (container) widget, and not allow creating a widget out of the entire contents of the BODY

Right now a user can create a custom widget as follows:

• New HTML File
• Adding widgets, set properties, etc.
• SaveAsWidget And then the SaveAsWidget logic will extract all of the content inside of the BODY is then put side of a DIV.

Instead, I would propose that we force the user to create a container for his custom widget (usually a SPAN or DIV), and that the SaveAsWidget icon (or menu command or whatever) is disabled unless the user has a single widget is selected (i.e., usually the container), and that SaveAsWidget operates on the current selection rather than the entire BODY.

My reasoning:

• Usually, users will only realize they need a custom widget when they are in the middle of a page composition, where they realize "oh, I need to repeat this snippet in other places".
• Some widgets are meant to be "inline" (e.g., dijit.form.Button) and others are meant to be "block" (e.g., gridx). If we always wrap custom widgets in a SPAN, then that will be the wrong action for block-level widgets, and similarly DIV would be wrong for inline-level widgets. So, let's force the user to tell us which one they want be forcing them to define the container element/widget for their custom widget. (This does mean that users will have to learn a little more before creating their first custom widget, but I think that's OK because custom widget creation is going to involve them reading a how-to page anyway for other reasons.)

(2) The create widget dialog should offer these fields, and offer a help (?) button for each of these fields for explanation of that field:

• (Text field) Widget group This becomes the first token in the widget name, and we provide a default value of "MyWidgets" (as in MyWidgets.MyCoolWidget). This also becomes the folder name that we use in the libs/ folder. Help text suggests a name like MyCoolWidget, saying it needs to be unique versus other widgets within the same widget collection, with pointer to relevant section in OAM spec, which is http://www.openajax.org/member/wiki/OpenAjax_Metadata_Specification_Widget_Metadata#widget_element_name_attribute
• (Text field) Widget name This becomes the second token in the widget name, and we do not provide a default value (as in MyWidgets.MyCoolWidget) Help text suggests a name like MyCoolWidget, saying it needs to be unique versus other widgets within the same widget collection, with pointer to relevant section in OAM spec, which is http://www.openajax.org/member/wiki/OpenAjax_Metadata_Specification_Widget_Metadata#widget_element_name_attribute
• (CheckBox) Replace selected document content with an instance of the new widget
• (ComboBox) Widget palette section If not specified, then use the widget group name (eg "MyWidgets") as the widget palette section name. The ComboBox's menu shows the list of widget palette sections that exist in Maqetta at that moment in time (e..g, "Dojo Controls", ...)

(3) We automatically construct the OAM file's widget ID as <userlogin>:<widgetgroup>:<widgetname>

(4) I don't think we are dealing with require() statements properly.

Suppose you have a custom widget "MyCoolWidget" that contains a dijit.form.Button. When you add MyCoolWidget to an HTML page and save that HTML page, the HEAD will contain a require() for MyCoolWidget but not one for dijit.form.Button. I'm pretty sure we need to add dependencies for all widgets used in the template within the *.js file for the custom widget.

This might be a bit tricky when taking into account widget libraries that build upon a core library (e.g., gridx, where one library is dependent on a second library), which of course aren't located in dijit/. For those situations, we might need to also add additional dependency information into the _oam.json file.

(5) Custom widgets should go into <projectbase>/lib/custom.

Right now, we are putting custom widgets into <projectbase>/lib/widgets, and there is also a child "widgets" folder (i.e., <projectbase>/lib/widgets/widgets) I suggest that we use<projectbase>/lib/custom instead of <projectbase>/lib/widgets, and (using my proposed default for widget group) then there would be a child folder <projectbase>/lib/custom/MyWidgets.

(6) Each widget should get its own folder.

Right now, if you create two custom widgets, their HTML template files end up in the same folder next to each other. In order to allow easy packaging and sending of widgets among people, we need to put everything about a particular widget within a single folder. For example, /lib/custom/MyWidgets/MyCoolWidget would contain all of the files for MyCoolWidget. Perhaps the files could be arranged like this:

<projectbase>/lib/custom/MyWidgets/MyCoolWidget/
   MyWidgets/
     MyCoolWidget.js
     MyCoolWidget.html
   metadata/
      MyCoolWidget_widgets.json
      MyWidgets/
          MyCoolWidget_oam.json

Note: the organization within the folder isn't that important. The big thing is to put each widget into its own folder.

(7) (Maybe post-1.0) Allow users to simply download (without bringing up the big download dialog that shows the list of libraries) and upload files

In earlier versions of Maqetta, a user could download files by selecting them in the Files palette and invoke the "Download" command from context menu. This would create a ZIP that contained only the currently selected files. With a recent release (Preview5? Preview6?) that Download command on the context menu has been equivalenced to the download icon on the Files palette toolbar.

By only downloading selected files (and not the libraries), then users can ZIP up their custom widgets to share with others.

But to complete this feature, we also need to offer a corresponding upload feature. (And hopefully find a way to update the widget palette to show the uploaded widget)

(8) (Maybe post-1.0) We offer an "Expand widget into content" command (probably on context menu for short-term).

This allows a user a reasonably easy way to edit an existing widget. Just add a widget to a page, issue a "Expand widget into content" command, modify the content, and then SaveAsWidget a second time.

To make this work reasonably, we will need to attach some of the original widget metadata values to the root node of the expanded widget hierarchy so that when the user invokes SaveAsWidget on the modified widget, the previous values will appear in the SaveAsWidget dialog.

If we also support variables (see (9) below), we might need to extra code to attempt to preserve the variables.

(9) (Maybe post-1.0) The Create Widget dialog should have a second pane that allows the author to list widget properties.

• The widget properties pane would include + and - buttons to add/delete properties.
• Each property would have these fields: name, type, default value
• We put each property on the widget class's prototype (assigning default value onto property's value on prototype), and add property entries in the OAM file.
• Authors who want include make parts of the template into a variable need to hand-edit the template's source code to put ${varname} into the template at the right places. Which leads to...

(10) (Maybe post-1.0) We need to add an "Open With->" feature so that users can open HTML files using the plain source editor (i.e., without visual editor getting involved).

This will allow authors to open the *.html files in lib/MyWidgets in order to add ${varname} entries to the template.

(11) (Post-1.0) We need to figure out how to offer authors the ability to create helper JavaScript classes.

For the future... in case the author wants to offer custom SmartInput dialog or other special features.

(12) (Post-1.0) We need to figure out how to deal with theme metadata so the custom widget can be integrated into the appropriate theme editor.

For the future...