Hiya - I've been working on a project that is accessed via WebDirect and uses a web viewer to display Javascript-generated charts and tables. Before 21.1, I needed to encode the html into Base64, and then use ""data:text/html;base64" in the web viewer to decode the encoded html.
Interestingly I could never get this to work in iPadOS or iOS when using Base64Encoding, and it of course would take extra processor cycles on the desktop, so I've used variations of the following code:
If ( PatternCount ( Lower ( Get ( ApplicationVersion ) ) ; "web" ) ;
The good news is that FM Server 21.1 no longer requires the use of Base64Encode or decoding for WebDirect solutions. Indeed, it no longer seems to work with Base64 encoding in WebDirect. But not having to do the encoding and decoding at all results in meaningfully faster interaction with the web viewer.
That's very interesting. To put it another way, earlier versions of FMS were not able to encode and/or escape the code contained in a webviewer. The base64 encoding/decoding ensured that the web viewer got to see the code you intended it to see. FMS v21.1 is now able to handle the code without mangling it. That's very good news.
I'll have to take a closer look the next time I am at my work machine. I seem to recall using web viewers in web direct (in less recent versions), and it was always sufficient to just use:
"data:text/html," & ...
without any Base64-encoding.
It could be that I simply forgot that I used Base64 encoding. I suppose it's also possible that the code and library that I have been loading into the web viewer don't provoke the same behavior, or perhaps the behavior didn't surface due to browser choice. Regardless, it sounds like things took a turn for the better, which is certainly nice.
I'm assuming that it is a question of what you put into the web viewer. I experienced lots of problems. I was a big fan of web viewers from the outset but the experience of using them in production environments was sobering. I was able to use them when I carefully tailored the inputs. I was never able to rely on the behaviour through version changes, and even dot point updates could cause a web viewer component to blow up.
Ever since IWP came out in FMP 4.0, I've been tempted to use the web as the primary access means to my hosted FM databases, but with every release up until 21.1, the rendering glitches (especially if anything was stacked in a layout) or lack of feature parity between WebDirect and desktop access (like Card Windows before v19) made it a deal killer.
Now, in my "retirement", I'm running a small foundation with about 50 volunteers, and I have no control over what devices users use to access our FM solutions. Absent a ChromeBook-friendly version of the FM client, WebDirect is the only way I can assure universal access to my FM solutions (or at least near-universal - I really wish WD would support FireFox).
Happily, 21.1 is a big step forward, and in addition to no longer requiring Base64-encoding, it renders my webviewer javascript libraries beautifully (mainly charts created using D3) and in many cases is even more performant than if the client was used. It allows me to completely hide the menu bar from users, including the Tools menu (I really wish I could do this with the FM client). The only remaining issue I see is some continued issue with rendering CSS in tab panels and sliders. Otherwise, I am really, really pleased with how well WebDirect works.
Thanks for replying to this thread. I appreciate your perspective.
I think your memory serves you correctly. I started playing around with web viewers around v17, and in my initial attempts I can't recall anything about Base64-Encoding. It was only after v19 and its ability to use card windows in WD that I started using WebDirect again, and that's when I ran up against the encoding issue. Thankfully Soliant and others have some really helpful blog posts on this subject.