The PB UI engineers inventively merged classic PB IDE elements into an innovative design, packaged inside the modern industry-standard MS Visual Studio Shell. I became productive in the new IDE within an hour of installing it. I went over to YouTube, watched a couple of videos on the IDE produced by the product evangelist team, and then jumped right in. I made the decision to delegate mastering all the new IDE features to a background process so I could simulate how long it would take for a classic PB developer to do something useful and productive. I quickly found all my old PB IDE friends in new forms, understood many of the new developer aids, and got right into coding. I discovered that most of the IDE features are intuitive and approachable on an as-needed basis. Figure 1 shows the new IDE.
Building GUIs with WPF
|Figure 2. WPF Painter: The new IDE includes a "screen painter" where you can drag-and-drop and configure elements visually. Behind the scenes, the painter generates XAML code that you can edit manually (if necessary) in a special XAML-code pane.|
WPF is a vector graphics based way of rendering rich, dynamic, adaptable user interfaces. For Win32 app developers, WPF is an entirely new paradigm of UI design, and I confess that I'm still a "babe in the woods" with the technology. But I was able to leverage all I already knew about PB window layout and design when migrating an existing PB WinForms application into version 12 .NET and laying out a new basic WPF GUI (see Figure 2). It was easy to figure out enough about the PB WPF "Painter" to get my business logic coding job done. Of course, I anticipate needing to know lots more about WPF in the future, but not knowing much about it to begin with didn't get in the way of migrating my application or of my .NET language coding activities. Truly mastering WPF will take some time, but because PB has integrated its classic UI elements and can migrate classic code forward, you can delegate WPF mastery to a background mid-priority learning task and get on with your pressing application maintenance needs.
WPF uses a XML-based layout language called XAML, which is standards-based, so you can import WPF XAML code into the PB IDE. The ramification of this for a PB project is that a graphic design specialist can create the GUI code (ala J2EE roles) and programming specialists can then integrate the pre-built GUI code into an application containing business rules and logic.
CLS Language Compatibility
On the language compatibility front, Sybase has transformed PB's platform, integrated toolset and built-in PowerScript language into a .NET-compliant release that offers near complete backward and forward compatibility with existing classic PowerScript code. To understand the importance of this transformation, it's worth including a brief examination of what being ".NET compliant" means. One main goal of the .NET platform is to facilitate seamless language interoperability, which is defined as the ability of code to interact directly with other code written in one or more different programming languages. The goal of interoperability is to maximize code reuse and improve the overall efficiency of the development process.
The .NET common language runtime (CLR) has built-in support for language interoperability. All .NET compliant languages compile to a common format known as Common Intermediate Language (CIL). This has the distinct advantage of allowing data types to be consistent across all languages, because all languages follow common type system rules for defining and using types. Types are discoverable at runtime or at design time, because metadata about types provides a uniform mechanism for storing and retrieving information about them. So the runtime can manage the execution of multi-language applications because all type information is stored and retrieved in the same way, regardless of the language the code was written in.
|Figure 3. IDE Code Editor: This screenshot shows some PowerScript code in the code editor window that includes some .NET framework method calls.|
Interoperability provides two key application design and coding benefits. First, regardless of the implementation language, types can inherit from other types, pass objects to another type's methods, and call methods defined on other types. Second, exception handling is consistent across languages. Code can throw an exception in one language and that exception can be caught and understood by an object written in another language.
PB 12 lets you deploy existing PowerScript code (see Figure 3) as well as develop new code that can interoperate with code written in any other CLS-compliant language. Here's how it works.
First and foremost, the PowerScript compiler emits native .NET assemblies—the compiler transforms native classic PowerScript code into its .NET equivalent as part of the compilation process. You don't need to do anything special in your code for this to occur. Just press the Build button on the IDE toolbar. PB actually provides for three levels of .NET compliance. On the first level, your PB application functions as a .NET consumer because it can:
- Call any CLS-compliant method on any assembly
- Create an instance of any CLS-compliant type
- Read and modify any CLS-compliant variable and
- Access any CLS-compliant property and event.
On the next level, your application can become a .NET extender. A PB application has the ability to:
- Define new non-generic CLS compliant types that extend CLS compliant base types (Inherit from CLS types)
- Implement any CLS-compliant interface on a PowerScript class
- Place CLS-compliant custom attributes on appropriate elements
At the third level, your PB code becomes part of the .NET framework and is accessible to other code. To make your code accessible, you must make sure that any functionality your code exposes is CLS-compliant and then deploy it as a .NET assembly. The process includes:
- Defining all public and protected members of Custom Class User Objects (CCUOs are the PB equivalent of the vanilla Class type) so that any class that inherits from or interfaces to them can access any of their members.
- Making sure that parameter and return types of public methods of your CCUOs are CLS-compliant. The good news is that you can use any non-CLS compliant PowerScript language features inside your implementation and still have a CLS-compliant assembly.
Climbing the Learning Curve
For classic PowerScript developers, the real learning curve involves expanding one's language knowledge by becoming aware of and building applications using existing or extended .NET framework elements. The good news is that this knowledge is not necessary until you need to take advantage of the richness of the .NET framework. I'd suggest purchasing a quality .NET reference book and working your way through the sections and examples. The beautiful thing is that you can code and test most of the examples inside PB. One thing you will have to get used to is the hybrid form of the language, in which the core construct set and syntax are PowerScript, while the method calls and exception types are .NET.
From the other perspective—what it would be like for a professional Visual Studio .NET application developer new to PB to be productive as a developer in PB 12 .NET—I would conjecture they would need to learn these basic PB skills and concepts:
- How to organize PB code into PBLs
- The basic elements of the PowerScript language
- A bit about classic PB-specific IDE elements
- A basic knowledge of the classes in the PowerScript system class hierarchy and their members.
Overall, PB 12 .NET has the potential to give new a lease on life to existing PB mission-critical Win32-based business applications. It allows organizations to expand and integrate both legacy and new PB applications with current and future enterprise computing initiatives. The main challenge for Sybase going forward will not be one of technology, but rather of growing its PB market share in the face of the current competition and a lackluster global economy.