Xojo Web

Serving static content from Xojo Web

Now available on GitHub is open sourced code to help you serve static files from your Xojo Web application. This is especially useful if you are running standalone or load balanced apps and do not want to depend on another web server.

Check it out here: https://github.com/1701software/XojoWeb_StaticContent

For example at ServerWarp we host many load balanced applications for customers. Many will produce PDF reports for users. In order to serve those PDF reports they have often relied on writing those PDF files to another directory of another domain or subdomain because Xojo Web could not natively serve those files. Technically the "WebFile" class works for this purpose but the user and development experience is a bit subpar especially for mobile clients. You can only access files that way if you have an active Xojo Web session. What if you want to email your user a link to the download?

The problem at ServerWarp is we isolate your apps and domain web servers from each other to protect from vulnerabilities and provide the most secure environment. So it requires extra configuration to get your Xojo standalone app to be able to write to a specific folder of another domain. The other obvious downside is you now need a secondary web server and domain/sub-domain to serve these files. It would be great if you could simply write your static files to a sub-folder inside of your app directory and serve those files directly. That is exactly what we deliver here.

The code we are presenting on GitHub today allows you to easily map folders to the Xojo Web application to be served as static content. It is a drop in module that extends the 'App' object of your Xojo Web project making integrating it super simple.

The example project demonstrates two distinct static folders with a PDF, image, and text file. It demonstrates how to map the folders and the Xojo Web app presents links to test the functionality very quickly. To give you an idea of how it is to integrate check out this screenshot of the 'App.HandleURL' event handler:

Open source upload control for Xojo Web

Plupload HTML web upload dialog control for Xojo Web.

Special thanks to Alexander Marthin @ Lumafilm.dk for sponsoring this project and generously donating it to the Xojo community.

Plupload is a widely used HTML/javascript web upload control facilitating the upload of large files via the web browser. The Xojo Web upload control is not well equipped for large files or when being used in a CGI environment.

Our objective here was to implement a web dialog control that presents a fully featured upload control powered by Plupload. Plupload can upload to any web server but by default provides a PHP script to facilitate file uploads. This repository contains a "www" folder which are the scripts and assets that need to be uploaded to your web server in order to facilitate the uploads. The "www/uploads" folder is where files are saved upon upload (configurable - see below).

To use in your Xojo Web project you want to copy the "Plupload" dialog control to your project. See the "btnShowUploader.Action" event in the example project for details on how to instantiate, configure, and show the control.

MIT licensed. Find it on Github at: https://github.com/1701software/Plupload_Xojo

Xojo in 2017: A Review [Part 2: The Framework]

This is the second part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.

The first part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part1

-----

The truth is you cannot easily make a distinction between Xojo the language from its framework or “standard library” in typical programming language speak. This is because of how Xojo is produced as a commercial product. In most programming languages (especially recent open source ones) the syntax and rules that govern it is distinct from the built-in functionality that the language possesses. Beyond those capabilities is a packaging system or an import mechanism that allows you to draw on additional libraries to complete your desired objective.

In some languages like Swift the standard library is small in scope as most fundamental functionality is already found in the Apple/Next foundation libraries. The cross-platform objectives of Swift are being enabled by duplicating the said Objective-C/Darwin frameworks to other platforms such as Linux. This allows Swift code to more easily be ported from one platform to another. Google Go (or Golang) is the opposite and provides a very extensive standard library capable of powering web servers, performing compression and cryptography for example. A great deal of network code built in Go is ready to be compiled on any supported platform due to the standard library being so robust.

Xojo is like Go except without the benefits of an open source standard library. If you want to build a web server you have no choice but to use the built in TCPSocket and ServerSocket implementation provided in Xojo’s standard library (or framework as they call it). Xojo has no packaging system or central repository of plugins or third party libraries. While the Xojo standard library is quite large it varies based on the platform you intend to use it on. This can make coding difficult because you have an expectation of a method or class being available or working identically on all support platforms but this is often not the case.

More damaging to the process of writing code in Xojo is that the standard library is not the only nuanced aspect of the platform. Core data types that should be iron clad and completely reliable on every supported target can vary wildly in their implementation and support. Feedback item #46943 as of this date is ranked 880th and “Needs Review” despite ample evidence that the new ‘Text’ data type simply does not function on Linux as advertised. For those of you new to Xojo and not aware of what Feedback is we will discuss the pros and cons of this tool in a later review part. You should know that the Xojo community is likely unaware of this bug because if they were it certainly would not rank 879 other bugs to be more important. Without reliable data types the rest of the platform is also unreliable because you cannot predict outcomes of standard type operations.

[ For those of you unable or unwilling to use Xojo Feedback to review case #46943 it demonstrates in a reproducible fashion that the ‘Text’ data type is magnitudes slower on Linux. Specifically using the ‘Text.Characters’ iterator is extremely slow compared to any other target. Fortunately there are other ways to iterate through the contents of a ‘Text’ variable but they certainly are not pretty and basic unit tests should have identified this issue or shown a disparity. ]

If you are not using the new ‘Text’ type on the platform affected then you are unlikely to use caution when using it. You only find yourself in this situation after spending weeks developing your application and then deploying it to the platform to discover it is not running as expected. Oh no!

Now you will tell me “Phillip it’s okay nobody uses the ‘Text’ type yet except for iOS” and you might be right. Except that I do for all my projects because I want to use the new framework so I can write cross-platform code. If I cannot share business logic between my desktop app and my iPad app then the tool has failed at its primary objective. Suddenly we must maintain different business logic code bases because iPad can only accept the ‘Text’ type and Linux cannot use the ‘Text’ type reliably.

Even worse these nuances can vary from one Xojo version to the next. Often with customer consulting projects I am forced to use one release of Xojo for one project and a newer release for another. In a larger project of mine with multiple executables (multiple Xojo projects unfortunately as mentioned in part 1 of my series) must use different Xojo versions for the same ultimate deliverable! Absurd.

There’s two reasons for this: One is old history now and cannot be changed and all we can hope for is Xojo takes my thoughts to heart and reconsiders their strategy for the second reason.

The first reason takes us back to iOS on Xojo. iOS is such a different beast from the rest of their targets requiring IDE enhancements and substantial reworking of many of their classes. Specifically, on iOS few of the core operating system libraries are synchronous in nature so many of the Xojo classes needed to be redesigned to accept this new paradigm. They could have taken the easy route and bolted on overloaded methods and new events to existing classes but Xojo engineers decided that asynchronous operation was the future. Rightfully too as we see languages like Javascript with Node.js, Google Go, and Erlang take off in popularity. However instead of just designing new classes that would either be iOS only or slowly reach all the targets as the “new framework”, they re-designed the entire language.

While the syntax looks familiar every class was touched, name spaced, and even core data types altered. Friendly favorites such as the ‘Variant’ object ceded to the ‘Auto’ type which means “I could be anything including a runtime error that I wasn’t what you wanted when you wanted it.” The new ‘MemoryBlock’ type has countless forum posts asking, “How do I use this thing” and “how do I get Text in and out of a MemoryBlock”. If that weren’t enough it turns out the new data types don’t even work (as addressed above) and aren’t being fully tested in every Xojo release.

Finally, what really will upset you about the new framework is how awfully long it has taken Xojo to implement the classes necessary to utilize it on all platforms. With iOS receiving extremely slow updates to its limited standard library there is little incentive for Xojo to push the new framework when its widely avoided by the community for being cumbersome to use, broken, and/or not available when needed.

This leads me to my second conclusion about why I am often forced to use multiple Xojo versions for any given project. The reality is the IDE only gets better with each release. It gets faster, adds new features, themes, documentation, etc. I want to use the new IDE when it ships and I want to continue supporting the company because I believe the IDE represents how programming should be presented. I absolutely hate having to compile piles of C++ code and switching compiler flags and getting my build environment together. On macOS that could mean screwing around with Homebrew to acquire the Linux-esque packages needed to compile a library or executable. On Linux that means gathering the bits to the compiler toolchain which vary from distribution to distribution. On Windows you have to struggle with Visual Studio project versions and now with Windows 8 & 10 multiple SDK versions that are changing rapidly.

I do love working with Xojo daily. I want to fire up my IDE, write some code, hit compile and have executables that work. Xojo is the closest thing to the perfect environment I have found for all the types of devices in my life and in those of my customers.

Truthfully, I absolutely hate that core data types can be broken in obvious and unbelievable ways. I hate regressions and how Release .1 and .2 are often re-fixing things that were fixed in a previous release. Most of all I hate how the standard library can fail on you entirely in unpredictable ways from one release to the next. You often find yourself in a situation where you are debating the pros and cons of two releases and which is the path of least resistance. Which version will cause the least amount of pain hoping and praying that the next Xojo release fixes it for you. If you file a feedback there is a good chance it might. It will probably break something else though.

What I am trying to say is the quality control at Xojo is not good. I am also saying that if you are patient and understand the complexity of what they are trying to achieve it can be great. However, what is a lengthy rant if not for at least one suggestion:

Open source the standard library.

Xojo does not need to be 100% proprietary. For one it’s absurd in 2017 to be a programming language who safe guards all of your inner workings. You have plenty of intellectual property in your IDE and compiler toolchains. I would subscribe to your product even if it was an IDE for more common languages because I enjoy the experience. Second most of your classes are just rehashes of operating system provided classes that you have written a wrapper around. If not an operating system library then some other open source library like Crypto++. Xojo writes wrappers for other libraries for a large portion of their standard library yet hypocritically denies their users the ability to write wrappers around their framework in the EULA. Huh?

I am advocating and would continue purchasing and supporting Xojo if the standard library was open source. The community could help fix bugs and extend the platform with classes. Xojo could package the “officially” supported version with the IDE but the source and instructions on how to build for all platforms would be available on say Github. If a new release of Xojo breaks the HTMLViewer for example then we could take the version from the last release and compile it for the new IDE.

In fact, we could even mix and match which versions of the library classes we need for a given project. How about exclude classes we would never need to minimize the size of the framework and our executables? The community could do so much to extend the framework beyond its original scope and breathe new life into every release of Xojo instead of playing two steps forward, one step back.

I will cover the Plugin SDK in another part of this series and some of the most popular plugin vendors in the Xojo community. In short: the Xojo standard library suffers extensively from lowest common denominator and an additional investment in third party plugins is essentially required. Xojo wants to move away from the Plugin SDK and to their new LLVM pre-compiled plugins that they have mentioned but never fully scoped out for the rest of us. While I find that intriguing and useful it should not be a binary choice. I want to see the entire standard library turned into one giant Plugin SDK.

-----

For those of you that will tell me I am being overly critical I apologize but I do not accept your premise. I am writing this from the perspective of someone who uses Xojo daily. It is not my job to advertise for Xojo or help them generate more revenue. They market their product as a tool that does cross platform development with a large and useful standard library. I and most consumers using the product will take them for their word and assume the product works as advertised.

My objective in this series is to communicate the pros and cons as a professional Xojo developer making a living with this tool. I want to communicate to the business owner, future client, and forthcoming developer the challenges that they will face. I also hope to build consensus around logical and attainable solutions that would make the product better for everyone. If I did not love using Xojo then I would not take the time to write all of this down so I hope you find my criticisms useful. I also do not want to spend cycles regurgitating content you can find on Xojo’s developer center or marketing materials. I am reviewing the product as it stands in 2017 and where I see it headed in the future. I am not developing a brochure to market it to you or suggest you should not use it.

The truth is that Xojo necessitates this level of scrutiny by staying 100% proprietary. They so far have not wanted users contributing to the core framework or optimizing the product for their own use cases. They want you to use Xojo exactly as they have designed it to be used and unfortunately the right answer probably lies somewhere in the middle.