So, where do we go from here (e.g. WebForms)?
As you’re probably already well aware, the .Net WebForms target was removed from PowerBuilder beginning with the 12.5.2 maintenance release. The reason it was removed was because of a third party control that was implemented in the later versions of it (11.5.x, 12.x, and 12.5.x) which SAP is no longer authorized to distribute. As a result, they had to pull it from the product as well as remove any EBFs or maintenance releases that contained it.
The question that came up quite a bit in the “Latest News from the PowerBuilder World” webinar, and which I’ve recieved by email since, is “what do we do now?”. This document is an attempt to address that.
Note that I’ve created it as a document rather than a blog post so that others can contribute as well. If you know of a good alternative solution, feel free to add it.
Please don’t feel compelled to criticize the suggestions made by others though. Let’s leave it to the end user to make their own evaluation of the pros and cons of the various approaches relative to their own environment. Just because a solution works best for you doesn’t mean it works best for everyone else.
1. Stay with WebForms. If you are already using WebForms, there is no need to stop using it. As noted in the release notes for 12.5.2, subsequent EBFs are configured so that they can be applied to both the original 12.5.1 MR and the 12.5.2 MR. If you want to continue to use webforms, simply don’t apply the 12.5.2 MR.
2. Appeon. Appeon is a third party tool that takes PowerBuilder Classic (soon to be renamed to PowerBuilder Native) code and coverts it to a web application. They recently also released a mobile version of their product that supports deployment to iOS as a native app with plans to expand the capability to Android and Windows Mobile in the near future. Because the tool takes existing PowerBuilder code and converts it, you continue to do development using the PowerBuilder IDE, minimizing the amount of code rewrite necessary to support the web platform.
3. Use RDP. One of the presentations at last year’s PowerBuilder Developer’s Conference by Dimitri Joosten was entitled “VHG-Tools Platform PowerBuilder .NET, Expression Blend, Web and Cloud”. He later did a similar presentation on PowerBuilder.TV. The approach was to move the application to PowerBuilder.NET in order to modernize it’s appearance, and then use products like 2X to allow access to the application via the web and/or mobile devices.
4. Rewrite to provide services to be called from HTML5. Another of the presentations at least year’s PowerBuilder Developer’s Conference by Marcelle von Wendland was entitled “How to use PowerBuilder .NET to Architect Powerful Mobile Apps for Mobile Workers”. She also did a series of articles for the ISUG-TECH journal outlining the approach. The approach was to migrate the application to PowerBuilder.NET and convert it to web services which are then accessed through a new HTML5 based front end.
5. Create visual assmblies and then use those in a WPF Browser Application. Unfortunately, PowerBuilder.NET’s support for WPF doesn’t extend to WPF Browser applications. There are ways that it can be tweaked to support them, but the approach is risky. However, with the release of 12.5, PowerBuilder.NET does support the generation of visual assemblies, and those can be used as the basis for a WPF Browser application written in Visual Studio. I demonstrated a rather simple example in a recent blog post.
6. ASP.NET MVC Framework with PowerBuilder generated assemblies
Convert your business logic into assemblies using transactions and datastores (non visual only).
Use XML export templates to render data in HTML, map protect column property to the new contentEditable HTML5 attribute, different templates could address different devices. Use XML import templates and possibly XSL validation to import data into datastores.
Needs a lot of rewriting, good knowledge of .net and web techniques.
PowerBuilder engineering has a long history of developing features that are missing a few things to make them actually usable in the real world. Then they go on to the next version and never revisit the earlier feature that isn't quite done.
WPF Browser Apps is probably one of those features. They spend a huge amount of time and money developing PB.Net as a WPF only environment and then won't spend a week or two making the new version usable in a browser, something that developers have been asking them to do for many years. They remind me of the dogs in the movie UP! when a squirrel walks by mid sentence.
[embed width="425" height="350"]https://www.youtube.com/embed/xrAIGLkSMls[/embed]
Hi Roland;
Actually, I believe that Sybase originally believed that WPF would be a stepping stone to SilverLight - which would be PB's web savior. I am not sure how MS ever convinced them of this but this was stated at many OSUG events by various Sybase people (heard first hand).
That has been a downfall of Sybase engineering and / or marketing for quite some time in that they believe the rhetoric that MS puts out and then hangs their hat on it only to get burned. MS of course got burned on SL - but, they have the development resources and money to just throw a technology away and move on to something else whereas Sybase does not.
It seems to me that SAP might be a little smarter and more wary of Microsoft. It will be interesting to see what they really think of PB.net when the detailed road-map finally comes out. For now though, the interesting aspects on PN 15 in the last PBTV webinar this week stated that most of SAP's engineering resources for PB 15 were now focused on PB Native (aka PB Classic).
You do bring up a great point though on Sybase's track record for "not finishing what they start on".
Regards ... Chris
If you do decide to stay with web forms, don't forget to keep your installation media safe as you'll never be able to get another "authorized" copy. However, even that may be problematic. If you need to fire up new computer with an authorized version of PB, will you be able to generate a working license (shared and/or standalone) for anything before 12.5.2? I do not know the answer to that question, just something to think about.
Reading the fine print of the announcement though, it does appear the absence of web forms is temporary in that it will be added back in a future EBF. ? Right?
As far as i know, the SYSAM licenses are the same for any flavor of 12.5.x.
No, that's not correct. Later EBFs will include patches for WebForms, but they would have to be applied to a 12.5 or 12.5.1 install that already includes the feature. That is, you would have to have already recieved the controls in question. They won't be added back into the product again at any point.
Hi Bruce;
That is a great list of alternatives for the deprecated Webforms feature!
I have a few personal comments / additions on your points as follows:
1) personally, I would not encourage anyone to plan to stay on Webforms. It does not support IE10, Sybase has not enhanced it since PB 11.2, the EBF's are just "shoe string" repairs and often not fully effective, etc. In actuality, Webforms has not been enhanced since PB 11.2 and even Sybase have been vocal for many years they have no intent on developing it any further.
2) Appeon Web would be my 1st choice. I suspect that if the Webform application works well today that there is a 90-99% chance that it will work just as well under Appeon Web with little or no code changes.
3) I think RDP is s great alternative for small applications or ones that have a low concurrent user usage. If a high concurrent load is anticipated - I suspect that the RDP solutions will suffer performance wise (unless they pursue a server farm approach).
4) This is another twist to using WS's like have done for over a decade with EAServer - where a PB NVUO + HTML DW serves up HTML to JSP/ASP/PHP/etc based web front ends. Unfortunately, the Web DW is still HTML4 based and the new HTML5 DW (now to be called iDW I believe) is not rendered by PB at all. It is actually another application outside and unrelated to PB that will render the HTML5.
5) I do not have a good feeling for this technology direction for the long term. I think the PB developer will get burned if they opt for this route. Of course, I could be OTL on this one if my crystal ball is off calibration <bg>.
Regards ... Chris
I asked Dave Fish about the HTML5 DataWindow he had been showing at various events and unfortunately, it is .Net only. I'm not sure if he explicitly said this but I get the impression it is more of a IM.Net type reporting tool than a PB.Net web app.
Hi Roland;
Yes, iDW (aka HTML5 DW) is actually an ASP.Net application that will import DWO's from PB.Net (or maybe even PB Native). The resulting new ASP.net application will render the DWO's using HTML5 syntax.
The iDW will be read only, have no DB updating and no scripting capabilities - at least in release 1.0 that OSUG was told about. However, since quite a bit of time has transpired since the initial demos of iDW to OSUG - I am not sure if the feature's specifications have changed since then.
In some respects, it does sound like a InfoMaker wannabe for the web but without the forms capability IM has today. What puzzles me is this features ROI for the PB world.
Regards ... Chris