Wednesday, April 27, 2016

Creating Bootstrap Widgets Using Dojo at ATLUG

Thanks to Lisa and Darren Duke, I will be presenting at ATLUG on May 19, 2016 on combining my two favorite open source frameworks, Twitter Bootstrap and Dojo, to create widgets that your can use in your web-based application. This presentation is not XPages specific. The presentation will be held at the IBM Technical Exploration Center in Atlanta. So if you are a web developer using or thinking about using Dojo and Bootstrap come join me or to just listen to me rant and rave.

IBM Corp (Building A)
6303 Barfield Rd., NE
AtlantaGA 30328
Technical Exploration Center

Creating Bootstrap Widgets Using Dojo
Twitter Bootstrap is one of the most popular responsive CSS frameworks available. Dojo is one of the most comprehensive and powerful JavaScript framework available. However, Bootstrap only comes with jQuery-based widgets by default. But if you can only combine Bootstrap and Dojo together, you as designers and developers will have an extremely powerful and flexible framework to build your applications.
Join Richard Moy from Phora Group for this fast pace learning experience on how to create your own custom Bootstrap widgets using Dojo to extend your set of tools. This session will guide you through the process of creating individual widgets, the pitfalls to watch out for, and how to add them in any Web-based application.


Monday, April 25, 2016

Registration for MWLUG 2016 is now open.

We please to announce that registration for MWLUG 2016, Austin Texas is now opened.  The eighth MWLUG conference will be held at the Four Seasons in downtown Austin, Texas from August 17 to 19, 2016. We expect this to be our biggest MWLUG conference with many exciting events and learning. 

We are planning two pre-conference events for which registration will be open soon, including a tour of the IBM Design Center in Austin plus a trip to the Alamo and the San Antonio Riverwalk.

http://mwlug.com/mwlug/mwlug.nsf/register.xsp

Special thanks to Mike McGarel for creating our brand new redesigned web site.

Abstract submission for MWLUG 2016 is currently opened for potential speakers. Abstract submission will close on May 27, 2016. 

http://mwlug.com/mwlug/mwlug.nsf/sessionabstract.xsp

We are now open for sponsorship. Diamond and Platinum Sponsorship are closed, but we still have Gold, Silver, and Bronze sponsorship available. If you are interested, send me a note.

Monday, April 18, 2016

MWLUG 2016, Defining the Art Collaboration - Abstract Submission is Open

Abstract submission for MWLUG 2016 is now open.  Mike McGarel and his team worked hard on our new redesigned conference web site.  Abstract submission will close on May 27, 2016.

Are you new to speaking? Well here is your chance to speak at a conference on a topic that you know well. Every year we reserve a number of speaking slots for new speakers. So take this unique opportunity to speak at a MWLUG conference and submit an abstract.

To submit your abstract go to: http://www.mwlug.com/mwlug/mwlug.nsf/sessionabstract.xsp

We look forward to getting everyone's abstract.

Wednesday, February 24, 2016

Announcing MWLUG 2016: Defining the Art of Collaboration


We are please to officially announce that MWLUG 2016 will be held on August 17-19, 2016 at the Four Seasons in Austin Texas. We have secured a special rate for this event. With all the new innovations that IBM and IBM Business Partners are creating with our favorite technologies, we are "Defining the Art of Collaboration" which is our theme for MWLUG 2016.

We are expecting an even greater turnout this year at MWLUG 2016.  We are planning many activities and new formats to make this a special event.  For attendees that are interesting in coming earlier, we are also working on a special event on Tuesday, August 16, 2016.  We will need to determine if there is enough interest before we book this event.  More information will be coming soon.

Sponsorship for MWLUG 2016, will be starting very soon with presentation abstract submission in April.  We look forward to seeing everyone in Austin.

And yes, we are cooking up a few surprises.


Sunday, February 14, 2016

My Final Thoughts on IBM Connect 2016

Today I was able to spend an hour writing up my thoughts about IBM Connect 2016.  I have had no time in the past few months to blog and continue my current series, but made a special effort to write this article. Like many, I had low expectations this year for IBM Connect given the venue from last year.  For me the greatest asset of IBM Connect for many years has been networking with the ICS community whether they are IBMers, IBM Business Partners, or IBM Customers. Most sessions in the past became just IBM marketing sessions. This year, I was glad to see less of that and more sessions that I can learn and benefit from.

Moving IBM Connect to the Hilton was a big plus not just in the layout, but also for us who always stayed outside the main hotel. It was much easier to get to.  The Dolphin and Swan was getting very old and arrangement for attendees who stayed outside was a pain.  I hope they do it again at the Hilton Orlando.

I know some did not like the newspaper style agenda, but I liked it very much. I like to browse through and get a big picture of the agenda layout. I did not use the Connect app since I have a Blackberry Passport and did not want to spend the time to side load it. My suggestion for the Connect 2017 web site is to have a view just like what was available on the newspaper.  I don't like searching using filters, one needs to get a big picture for each day, before I decide which sessions that I will be attending.

Thanks to Amanda Bauman and her team and Tim Clark for organizing the World Alliance User Group booth and the support that they are providing to user group conferences like MWLUG.

If you did not attend any of the Design Thinking sessions at IBM Connect, whether you are management, admin, or developer, you missed out.  I thought this year, the sessions were done much better.  But if you missed these sessions at IBM Connect, there will be opportunities at MWLUG 2016. More information and announcements will be coming on this.

As an IBM Business Partner, the Business Partner Appreciation beer event was most welcomed. Special thanks to Penny Hill and her team for this event.  However, it was also depressing for me, since I was on meds and could not enjoy the wonderful beers that were available.  Of course I was off the meds a few days afterwards.  Damn planets were not aligned for me. I need to make it up in Austin.

Having the lightning sessions at the Expo has a very bad idea.  I understood the concept, but the sound quality was not good and sometimes defocused the presentations.

I thought the IBM Business Partner OGS speaker was very good.  The OGS presentation about how East African entrepreneurs were using IBM Domino/XWork to create a fair trade environment alone justified me attending IBM Connect.  I disliked the OGS Guest Speaker from the Brain Games.  He seem to be shouting the entire time and showing video of himself as part of the presentation which was very strange.  The closing session with Erik Wahl was very good and a great transition and inspiring message to the direction that IBM is heading.

As many of your know, our company's main focus has been our Domino-based iPhora technology which after IBM Connect and seeing the future direction of ICS will continue to remain our focus and growth. Continue improvement to the Domino platform is extremely important to us as an ISV. After attending a few of the Watson and Bluemix sessions, I see opportunity to extend our iPhora solutions with Watson and BlueMix. More to come about this in the future.

My overall experience with IBM Connect 2016 was very positive and IBM Collaboration Solutions is back and more focused. Just execute the plan in a timely matter. I was extremely happy with the name change back to IBM Collaboration Solutions. I have high hopes for the new General Manager, Inhi Cho Suh. Hope to see you next year at IBM Connect 2017. Remember to continue the ICS conversation both online and by attending the many up and coming user group conferences to learn more, network and share. Hope to see everyone at MWLUG 2016, Austin TX.

  • DNUG 2016
  • Engage 2016
  • Inform 2016
  • ICS User Group Conference 2016
  • ICON UK 2016
  • MWLUG 2016
  • SnoUG 2016
  • Social Connections 2016
  • SUTOL 2016

I apologize if I missed one.

Monday, November 23, 2015

Our Adventures into Creating a Secure MVC Framework - Part 3 - Experimentation

Now that we have defined our design requirements, we needed to determine the tools and approach that we would use to create our framework.

We had created previous versions of iPhora Touch using Dojo and wanted to start from scratch on what tools we would use to create our framework. Everyone that I talked to asked me why I was using Dojo since it is big and slow.  So we started looking at different options.  Do we take one of the existing more bare bones MVC framework like Backbone and take components from them to create our framework or do we start totally from scratch using JavaScript or jQuery.

There are so many frameworks out there it is amazing. You can find many examples of MVC frameworks in action at todomvc.com. It was very difficult reading up on each framework, understanding them, and experimenting with them to see if they would work for us. Since we were already familiar with Dojo, we decide to start from there.  We found a couple of articles and frameworks that others had already done. However, as usual documentation was lacking.  What we did find was a very basic framework created by Christian Hoegl called Dojorama, dojorama.org and this served as our starting point. However it was built using version Dojo 1.9 the AMD version of Dojo.

Though we have been using Dojo for many years, we were using the non AMD version of Dojo and to us the new approach was like reading a foreign language. The structure of Dojo AMD and how it is used is totally different than previous versions of Dojo.  You had to type so much more code in order to do the same thing.  It seems ridiculous to us at that time. We struggled to make sense of what Christian was discussing. It seem to be too much work.  So we drop Dojo as a possible approach.

We tried Backbone, but we had to rewrite many of our widgets that we already created in Dojo.  In addition, we had to write more code to integrate with Backbone. Therefore, we dropped Backbone and went back to Dojo. So we spent many weeks learning and understanding the AMD approach used in newer versions of Dojo. Like always, most articles only presented simple examples.  We were struggling to understand the newer approach since our mindset on how to approach a problem was totally different.

https://dojotoolkit.org/documentation/#tutorials

As a precursor to further our discussion, we need to talk about Dojo widgets. A Dojo widget is a collection of HTML template and JavaScript. One hot topic of discussion in the Web development in recent years has been the concept of web components.  However, in Dojo this concept is no more than just a Dojo widget. Therefore, the concept of view/controller, it is just a Dojo widget.

A Dojo widget does not need to be a combobox or a field, it is can be as simple or comprehensive as you want it to be.  The class inheritance nature of Dojo widget makes it possible to extend the Dojo widget concept from being just a simple widget to a container widget or even something bigger and much more complex that inherits behavior from parent widgets.  The critical part that Dojo provides is the ability to create classes, superclasses, and class inheritance without having to create your own structure. This is one of the biggest advantages that most developers using Dojo have never utilized. Unless one has created complex Dojo widgets, one probably would not be familiar with these features. The OOP nature of Dojo with classes forces you to follow structured design patterns which makes it much easier for others to follow and manage your development process.

When a Dojo widget starts up it goes through a series of lifecycle methods including:
  • constructor
  • postscript
  • create
  • postMixInProperties
  • buildRendering
  • postCreate
  • startup
https://dojotoolkit.org/documentation/tutorials/1.10/understanding_widgetbase/index.html

This lifecycle methods define how a widget is created, initiated, and displayed. A Dojo widget can inherit the behavior and functionality from superclasses or from other widgets.  In addition to these 7 lifecycle method for creating a widget you also have one method to destroy the widget.
  • destroy
For almost all cases the only one you normally would be using are:
  • constructor
  • postCreate
Most of the time, if you are using a multiple page application, you would never need to call the destroy method since the widget will be destroyed as a you navigate between pages. For a single page application however, the destroy method is critical. What we learned as we will discuss later, the standard Dojo lifecycles was not sufficient for us and we had to create many of our own in order to make everything work the way we needed to.

With this body of knowledge and experience we went back to the Dojorama framework to see if you can utilize any of the concepts presented by Christian to create our framework. Christian treated a web page simply as a Dojo widget.  As one navigates between pages you were displaying a different widget. The Dojo widgets (pages) were containers with simple HTML element inside. He used Javascript within each container to controller the behavior of the elements within each view.  This immediately hit us that the use of Dojo widgets in creating our MVC framework was the right direction.

Since we wanted iPhora Touch to be a multi-pane single page application, the structure need to be far more complex while being more robust.  The HTML components within a Dojo widget page needed to be complex Dojo widgets and they themselves can be containers contain widgets.  So we came up a layered Dojo widget based architecture that had the following structure.


Each layer was a Dojo widget starting from the core application layer all the way up to a widget like a combobox.

Next time:  Creating the Architecture - Dojo Widget Galore








Thursday, November 12, 2015

Our Adventures into Creating a Secure MVC Framework - Part 2 - Design Requirements


When we created iPhora Touch version 2, it was a multiple page application that utilized Dojo 1.53 and Bootstrap 2.32.  The interface worked well on desktops but broke down when used on tablets. It was totally unusable in a phone environment.  Since it was a multiple page solution each page needed to reload Dojo as you jump from page to page. Since we wanted a secured environment, pages could not be cached. However, this slowed down the loading and response of each page.  Since we were using Dojo 1.53 at the time we did not benefit from any form of AMD.


iPhora Touch V2 Community Home Page

We wanted to redesign the interface to work well with mobile devices and desktops, have better performance, but at the same time to be a secured environment.

Though our iPhora Touch solution is a social community-based solution, we designed it to be a closed environment by default and it is assumed that you are not allowed access to anything, which is contrary to how most social collaboration platform are designed.  Social collaboration no matter how any analyst or others spin it, is all about data. Who has access to this data needs to be securely controlled. Being openly social and with no control leads to data breaches. Security is not just about SSL, firewalls, and encryption.

So for any community you may have access to one piece of information at any given state, but in another one you may have no access or limited access.  This holds true not only within a community but all the way down to individual web containers and components part of a community.

So the challenge was to create an infrastructure and interface that met these requirements. Over the course of many months, we looked at many interfaces and did not find anything that we thought was appropriate. I asked my oldest son who is an industrial designer on design, but that was of no avail.  So it was a struggle to find something that would work.

My youngest son is a big user of Pandora and was listening to music when I noticed their application on his iPad.  I thought to myself this is a nice and simple interface, but very powerful. So I borrowed his iPad and played with Pandora for hours trying to understand its functionality. Unfortunately, there was a number of things that I thought was not usable for us, but it was a good starting point, a design inspiration. The multiple pane approach is what we needed, but how in the heck do we implement something like that. Many of the cool things it did we did not need or I was not sure we could even do on a web browser-based interface.

So using my favorite mockup tool, Balsamiq, I moved forward in laying out what the next version of iPhora Touch would might look like.  So we came up with a multiple pane environment that is shown below.  Depending on the state of the application some panes would be hidden and some not.  Many application used a similar approach including applications like Facebook on the phone.

This was the easiest part.  The challenge was to create a multi-pane single page application framework and make it work.

So we came up with our design requirements and they were as follows:
  • The JavaScript library that would be used to drive iPhora Touch need to utilize AMD to reduce the loading process
  • The JavaScript library components needed to only load once during a session and when needed.
  • Each pane needed to have its own independent security environment but at the same time could be dependent on the state of a different pane and controlled by the application developer
  • The content of each pane had to handle multi-state of existence:
    • Fully Cached, where both the view and scope is cached
    • View Cached, where only the view is cached and scope is destroyed after use
    • No Cached, where both the view and scope are destroyed after use.
    • Defined Cached, where the existence of view and scope is programmatically controlled by the application developer or the server
  • No data can be stored locally on the client, but create the illusion that data is local
  • The MVC framework had to handle not only the defined pane structure shown above, but needed to function in any multiple pane layout that one can come up with. For example, it should easily function in a three pane environment shown below.
  • All web container and components had to inhere to iPhora multiple level state environment. What this means is that for any web component there is a number of possible state of existence and the state in which it exist varies depending on the level of user access at any given time within its parent.
  • The MVC framework had to use dynamic routing. Since the state of any content within a pane is dynamic and ever changing, routing needed to be dynamic so static hash tag routing was totally out.
  • Data binding for components needed to be controlled by the application designer rather than being automatically performed by the system.
  • Web containers and components within a pane had to inherit the security of its parent container
  • All web containers and components needed to be generated dynamically and can not pre-exist since it is dependent on what a user is doing as it interacts with the application.
  • The MVC framework had to function with the iPhora RESTful APIs controlled by the Gatekeeper on the server.
  • The framework had to be lightweight and as small as possible
  • It needed to function in all favors of web browsers, both desktop and mobile devices (modern versions)
  • It needed a responsive UI.


Alternative Multi-pane layouts



So these were the design requirements and which there are many.

Coming next time, Part 3 - The Experiments

Friday, November 6, 2015

Our Adventures into Creating a Secure MVC Framework - Part 1 - Introduction

As I was writing this series, it cause me to rethink some approaches and redesign part of our MVC framework. Therefore, it took me a bit longer to start this series than I thought. But here goes.

Introduction
The concept of Model-View-Controller MVC can be implemented in two ways, using a server-side component framework that generates the Web application interface/view or as a JavaScript framework that gets data from the server and generates the Web application interface/view .

In this series, we will be discussing how we created and implemented a JavaScript MVC framework. If you a Java developer and would like to implement a server-side MVC framework, Vaadin is a good server-side MVC framework to look into.  For developers in the XPages community, Ulrich Krause and Paul Withers has been blogging about Vaadin.

Each approach has its advantages and which approach you use is based on your development skills, tools, and architecture of your web application. If you are a XPages developer and plan to continue implementing web applications strictly on the server-side, I suggest you seriously look into Vaadin and move away from the whole XPages approach.  Vaadin provide you a more standardized and reusable approach.

What is an MVC Framework?
The goal with most MVC framework is to separate the application into 3 primary components that are use to generate the interface used to interact with the data, the model (data), the view (presentation), and the controller (manipulator).

If you are using a server-based approach, everything is done on the server. For a JavaScript-based MVC, the client retrieves the data and templates from the server. The controller facilitates the binding process and interface manipulation to generate what you see on the device. One addition component is the router which facilitates the communication between the client and the server.  For our architecture, the router is a separate component layer.  In some frameworks it is part of the model.

They are many different derivatives of the MVC concept. Some are very basic and some more encompassing. The model can reside both in memory and in local storage. In some approaches, the model structure is a directly reflection of the data on the server and the data is automatically synced. The controller always accesses the model locally whether in memory or local storage. As a result, any changes to the local data propagates back to the server.




MVC frameworks can implement either a one-way or bi-directional binding of the model with the view. Bi-directional binding significantly reduces the need to manage the data. One of the best examples of MVCs utilizing bi-directional binding is Angular. At this time, it is the most popular JavaScript-based MVC framework. Marky Roden has done a number of blogs and presentations at MWLUG and IBM Connect relating to Angular. Angular makes it easy for you with the help of some CSS create some very nice applications. Dojo also provides the ability for this two-way binding process, but it requires must more coding than Angular.

Two-way binding is great, but what happens when you start applying strict security rules on read/write/delete access that dynamically changes during a session. Well, the beautiful bi-directional binding falls apart and everything you do becomes a hack.

Secure MVC framework
As I mentioned in my prologue, our goal was to create a secure MVC framework. So what constitutes a secure MVC framework versus a regular MVC framework? A secure MVC framework has to perform like a regular MVC framework, but must take into account that data and information security trumps over the user interface. At no time can data reside locally on the client. It should only be in memory and if it is no longer needed it should automatically be destroyed. It needs to work in an environment where user access to any particular data at any instance is dynamic, access level is dynamic and may be revoked at any time during a session. It needs to respond accordingly to handle multi access level from the application level all the way up to the widgets level.

In addition, our framework needed to be server technology agnostic and work in a multiple pane environment where user access rights maybe different for each pane. So that was our goal.

Coming Part 2, Design Requirements