Skip to main content

Creating the MWLUG 2010 Web Site Using UX Pages version 0.4

Last year I was working on a new thing that I called the UX Pages and DLEX Engine. It was based on the XML declaration language used by Adobe Flex. UX Pages is similar to the approach now used by XPages but has a number of advantages.

I did not have the time to devote to it last summer given all the work that had to be done for the Midwest Lotus User Group Conference plus my full-time job. So I never moved forward on developing the technology any further. However, this has changed.

This year, NEOLUG is handling a big portion of the effort for MWLUG 2010 so I have more time. In addition, I needed it for building a number of customers applications. Therefore, I have a major incentive to develop it further especially since we are developing more and more Web applications and moving away from developing Notes client based applications. Does this mean that I will not develop using XPages. Not at all. I would like to have developed the Web applications using XPages, but the applications that we are developing are not suitable with XPages at this time.

So for the past two months, I have been working on building the features of the UX Pages engine. I have been incorporating components of Dojo and JQuery into the engine. One feature that I have added the past week is the ability to version and archive the web application. This feature has already saved my butt this week.

The new MWLUG Conference 2010 site MWLUG 2010 is currently running v0.4 of the UX Pages Engine on Domino 6.5. I could easily have set up a Domino 8.51 server, but I did not want to spend the time and resources. Since it does not depend on XPages rendering, I can build the web pages using the UX Pages XML declarations and have the compiled version run on any version of Domino 6.5 or higher.

The previous version, v0.3, relied on Web agents to handle a great part of the work. The latest version, v0.4, eliminates agents to generate the web pages and runs faster. The next version v0.5 will fully incorporate Dojo and JQuery into its architecture.

One may ask why I am doing this. First, XPages does not give me all the control that I need. Second, I wanted the generated code to be cross platform so that I can easily convert the web application to work with other data sources besides Domino. Third, the process forces me to learn Dojo and JQuery. Also, I can use the latest versions of Dojo and JQuery if necessary instead of replying on the version that IBM has put into Domino. Fourth, I can still use the Notes Basic client to generate the Web application since the UX Pages tool runs as a Notes client application. The Domino Designer 8.51 is still too slow for me even with a fast Dual Core and 2 GBytes of memory. So stay tuned hopefully for some Camtasia video of UX Pages.

Comments

Popular posts from this blog

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a

The iPhora Journey - Part 4 - JSON is King - The How

  The iPhora Journey - Part 1 - Reimagining Domino The iPhora Journey - Part 2 - Domino, the Little Engine that Could The iPhora Journey - Part 3 - Creating an Integrated UI Framework The iPhora Journey - Part 4 - JSON is King - The Why The iPhora Journey - Part 4 - JSON is King - The How As we mentioned yesterday, in reimagining Domino, we wanted Domino to be a modern web application server, one that utilized a JSON-based NoSQL database and be more secure compared to other JSON-based NoSQL platforms. A Domino document existing within a Domino database is the foundational data record used in iPhora, just as it is with traditional Domino applications. But instead of just storing data into individual fields, we wanted to store and process the JSON in a Domino document.  However, text fields (AKA summary fields) in Domino documents are limited to only 64 KBytes, and that is a serious limitation. 64 KBytes of JSON data does not even touch what the real world typically transfers back and fo