ajaxPhosphorus.five has many nice traits. One of its really nice traits though, is its ability to give you complete control over the HTML from the server-side, using pf.lambda, and Hyperlisp. In this tutorial, and the video embedded further down, we will go through most of the properties you can use when consuming pf Ajax Web Widgets, such that you have a reference guide for Ajax in regards to Phosphorus.five and its Ajax capabilities.

As promised in the above video, here is an almost complete list of all the different properties you can use when consuming Ajax Web Widgets in Phosphorus;

  • [widget] – Changes the type of widget, default is “container”. Out of the box legal values are “container”, “literal” and “void”, but you can actually create your own extension widgets yourself here, if you wish.
  • [element] – Changes the type of HTML element your widget is rendered with. Can be any legal HTML element name, such as “p”, “div”, “video”, “ul” and “address”.
  • [innerValue] – Only legal for widgets of type “literal”. Defines the innerHTML of your widget.
  • [widgets] – Only legal for widgets of type “container”. Defines the children widget collection of your widget.
  • [render-type] – Defines how your widget HTML tag should render. Legal values are “normal”, “immediate” and “open”. Default value is “normal”.
  • [visible] – Defines if your widget should be initially rendered as visible or not. Legal values are “false” and “true”. Default value is “true”.
  • [invisible-element] – Defines which HTML element to render your widget with, when it is invisible. Useful when you have invisible “li” element for instance, inside of visible “ul” or “ol” elements. Helps you avoid breaking the HTML standard when having invisible elements on your page.
  • [has-id] – If false, will not render the ID attribute of your widget. Useful for for instance “option” elements inside of “select” widgets. Default value is “true”.
  • [parent] – Declares the parent widget’s ID. This can only be the ID of an existing “container” type of widget, and will make sure your widget is rendered as a child of the widget you supply as a parent.
  • [before] / [after] – Defines where in the parent collection your widget should be rendered. Must be an ID to an existing element from within the [parent] widget you choose for your widget.
  • [has-name] – If false, will not render a “name” attribute automatically for you. Default value is “true”, and means that if your widget is a FORM element, then it will have a name automatically assigned, matching its ID attribute.
  • [oninitialload] – pf.lambda code to execute when widget is created and initially loaded. Useful for providing initialization code with your widget.
  • [onXXX] – Handles the “xxx” DOM event, and allows you to supply a piece of pf.lambda code to be executed on the server-side once the “xxx” DOM event is raised.
  • [xxx] – Declares a generic attribute for your widget, allowing you to supply any attribute for your widget, not handled in any of the special cases above.

You can also supply an [events] segment for your widget, allowing for creating “local Active Events” for your widgets, but that’ll be a subject for a later tutorial.

In addition you can also declare “client-side JavaScript DOM event handlers” for your widgets, if you have JavaScript that should be executed during a DOM event, instead of server-side pf.lambda code. If you wish to do so, you must append the text “-script” after the name of your event, for instance “onclick-script”, for then to supply the JavaScript to be executed, either as an expression, or a piece of text, being the value of your “onclick-script” node.

But both of the two latter subjects will be examined in later tutorials.