Passing a SSJS Function as a Custom Property to the Bootstrap Modal Dialog Custom Control

In my post on using my Bootstrap Modal Dialog Custom Control, I mentioned that I had yet to figure out how to pass code to the buttons for processing each step in the wizard.   This post explains how to process the contents of each step of your wizard.

With the help of Stack Overflow I was able to figure out how to pass a method name and execute the method in a button of the custom control.   This question/answer explains it well.  Thanks to Per Henrik Lausten for his clear and concise answer, and practical examples.

I am going to explain how I used this did this, in a way that would be helpful to anyone who implements the Bootstrap Modal Dialog Custom Control.  The steps are nearly the same for passing a SSJS function to any custom control.

1)  The first step is to create a SSJS script library to contain all the scripts for the buttons in your modal window.  (Next, Previous, Cancel)

2)  Include this script library as a resource on every calling xpage for each step.  This is the xpage that is never shown to the user.

3)  Create a new custom property for the modalWindow custom control.   Make the Type equal to "javax.faces.el.MethodBinding" and Editor as "Method Binding Editor".

4)  In each calling xpage, pass a value for the "processNextFunction" parameter.  Notice that how the parameter is passed as javascript.   Do not put open and close parentheses on the function name.

5)  In the modalWindow custom control, in the onClick event for the 'Next' button.   Have one line of code to call the function that you passed in (The middle line).

Learning PHP, My Observations and Comparisons to Notes & Domino

I decided a while back, that not only am I going to study topics that I need for my job, that I am going to study the alternatives to what I do.  This past long holiday weekend, I decided that first up, I was going to learn PHP.   I spend a good part of my Memorial day weekend, completing a 5 hour course on Lynda.com, as well as selected chapters of another older PHP course.   I also spend time researching the present state of PHP, and the community behind it.

PHP has been around since the late 90's and rose to prominence around 2000.  It is mature and widely adopted and is used on up to 70% of the web.   Here are my observations in no particular order.

• It is a server-side language like SSJS or Lotusscript
• PHP is the "successor" to CGI/Perl scripts
• It has syntax similar to C and Java, with the use of curly braces, and semi-colons at the end of each line.   
• You mix the code in with your HTML, like JSP and ASP.  It is analogous to using inline javascript using <script> in your HTML instead of having all your code in external files.     (You can include your code and keep it elsewhere, which I would think would be the best practice.)
• It is like javascript in that it is a scripting language, made for a certain purpose.  It is like JS in that you can use a function, before actually writing it in the same page.   
• It has some really weird syntax.   Instead of a dot operator it uses a " =>", and uses a "." for string concatenation.   There are also times where you actually need to leave off the closing tag.
• It is used mainly with Apache servers as a plug in, although it also runs on IIS.   PHP will never be used in conjunction with xpages unless IBM adds it to Domino server and doing so wouldn't make a bit of sense.
• There are loads of built-in functions to learn and use, and you can also make your own.
• Documentation seems to be excellent.
• Debugging looks like it is a major downside of PHP.   Without good standards, it can convoluted and become a maintenance nightmare.   Error messages are crptic (some even contain the Hebrew language).
• PHP uses the confusing term "variable variable" which is I think is the iterator in an array of variables. There is even a special character '%' to signify a variable variable.  After learning this, I thought that they made it harder and more confusing than it needed to be.
• There doesn't seem to be any console for debugging.  You can debug by writing variable values as HTML, and reloading page to see the value. You then remove your debug code when you get it right.
• There are many frameworks that are built on top of PHP, the most popular being CakePHP.
• Wordpress is built on top of PHP
• There are Object Oriented like parts of PHP, in a similar way that there are OO like parts of Lotusscript, but it is not considered an object-oriented language.
• PHP is usually tied together with a MySQL backend database
• The many built in functions are like @Functions in Formula language    Think of it as combining LotusScript and @Functions together in one language.
• You wouldn't use PHP to do anything outside of a webpage.  That is not a limitation, the language is intended that way.
• If I was a PHP developer, I would definitely learn another language like Java or C# as a back up.  
• In some circles, PHP is not considered a real language.  I don't know enough to form that opinion myself, but on the surface it seems untrue.   I will say this, that I think it would take the same effort for a PHP developer to learn Java as it would take for a LotusScript only developer to do the same.  
• PHP is in decline, but will still be used for decades.  
• PHP has a strong community that seems to have begun "circling the wagons' in it's defense.  The proponents seem a bit defensive to me, of course as a Lotus guy I understand that.
• There seems to be quite the rivalry between Ruby and PHP, those that know both prefer Ruby
• Since PHP is free, I don't think the PHP community has too much to worry about.   Good enough free, usually beats better paid in the eyes of most companies.
• The general trend in web development, is for more processing to move to the client-side using javascript and ajax and away from server-side processing like PHP.   I believe that you can use PHP with ajax together.although the course I took didn't cover that.
• It is fairly easy to begin writing PHP, and write code quickly.  Despite its quirks, it looks like a fun language to work with and to learn! 
• Xpages > PHP.  A more fair comparison would probably be xpages compared to a PHP framework, but I do not have the knowledge yet to make that comparison. 

Those are my high level observations of PHP from a Domino/Xpages Developers perspective.   I might spend some time learning about PHP frameworks from here.  Also in the future, I intend to devote extended time to learning Node.js, Ruby on Rails, Wordpress, ASP.net, and especially Sharepoint 2013.

Using Bootstrap Modal Dialog Control to Create a Step by Step Wizard

For my latest project, I finally got the framework complete so I can begin creating content.    As opposed to the demo in the last post, I decided to have a step-by-step wizard for data entry.   The last post showed how you could have multiple buttons on the same page.  I will probably need that technique for editing existing documents later.

I also discovered today that the extension library dialog control <xe:dialog> can be modified to act as a bootstrap modal dialog.   See this link on the new site http://bootstrap4xpages.com  by Mark Leusink for more details.   I really wish I saw this post earlier, but since I already built what I did, I am going to stay with it.

The way this works is that the calling xpage (New_PO) has a button which the user presses to begin the first step in the process.   The button starts by launching an xpage that holds the modalWindow custom control.   The control is automatically launched so that it appears to the user that it opens automatically.  In actuality, I have an unnamed button that is launched using jQuery upon page load. This works really well.   Here is the very simple code:

 $(document).ready(function(){
$('a.btn').trigger('click');
});

Note that there is one of these 'shell' xpages for each step in the wizard.  They are needed because you can't link to a custom control, that really doesn't make sense.   There is one shell xpage per step and they are all the exact same code with the exception of the custom properties.

Since the last few posts, I have needed to make several modifications to fit my current project.  These are the changes I made to the modalWindow custom control.

1. Removed slide effect from the modal window.   The effect, although cool, was a bit of an eye strain, and more importantly caused vertical centering issues on a mobile user agent.    I changed it the button class from class="modal fade hide" to class="modal hide".
2. Prevented the user from closing the dialog by using the escape key.  This is done by adding data-keyboard="false" to the button or anchor that launches the modal window.
3. Likewise, I needed to prevent the window from closing when they click off the window.  This is done by adding data-backdrop="static" to the button or anchor.   
4. Added new custom control property definitions for the nextXPage, and the cancelXPage.   The nextXPage controls which xpage is opened next, and the cancelXPage property takes it back to the beginning xpage.  Without it, the user would be taken to the xpage containing the launch button that they are not intended to ever see.   I will need to add a SSJS function to these as well going forward to process the contents of each window. UPDATE:  I figured out how to add SSJS functions to process the contents of each window, see this post.

I think this solution will be fairly portable, and it is not as complicated as it seems.   Here is a drawing to illustrate.   The blue area is where I begin to develop application specific input fields.  The blue area is where the application specific code will go, the rest will work for any app using this technique (with the exception of the six custom properties).