Reason #1: Superior Developer Productivity versus C#, ASP, or Java

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Reason #1: Superior Developer Productivity versus C#, ASP, or Java

I'm starting a series of articles for those deciding between Magic eDeveloper or uniPaaS to .NET conversion by upgrading and Magic eDeveloper or uniPaaS to machine code generators to C#, ASP or Java. The topic for today is developer productivity.

Many longtime followers of the advantages of Magic development will recall that Magic developers repeatedly won the international development competitions of the 1990s. Not only did Magic teams win multiple years in a row, they also were winning every place in the contests. They had to stop having the contests because the advocates of defeated languages stopped showing up. Why bother? Magic developers had proven themselves superior in all respects.

Everyone knows that the environments for the development of business applications have grown increasingly complex in the two decades since those amazing victories. And while it is tempting for followers of C#, ASP and Java to try to put forth claims that they have caught up to Magic’s development capabilities. The reality is that the gap has widened. As environmental complexity has increased, the Magic paradigm of platform based metadata development has become even more essential to development efficiency.

To understand this, one needs to consider the COCOMO II Model of software estimation perfected at the USC Center for Software Engineering. (Go Trojans!) The COCOMO II model can be simplified as follws:

Effort = (Team) x (Tools) × (Complexity)^(Process)

The concept is fairly simple. As you increase the number of developers (team), effort increases. As you increase the number of programming languages needed (tools), effort increases. And as you increase the functional requirements of the application to be delivered (Complexity), effort increases. The relationship between these three components of effort is factorial. Why do you think third party companies are offering so many different conversion paths for Magic (C#.NET, ASP.NET, Java, etc.)? Because to replace all of the development capabilities of Magic require not one new tool but an entirely new set of multiple tools. Migrating to .NET by converting to .NET with a  code-generator instead of migrating to .NET with an upgrade to .NET with Magic xpa will create a bubble in the center of the COCMO II formula above the number of tools needed for enterprise application development goes from Magic xpa to:

·         C#.NET            or Java J2EE for Server Side Apps

·         ASP.NET or Ruby on Rails or PHP for Web apps

·         Java J2ME for BlackBerry client apps

·         Java J2SE for Android client apps

·         Objective C for iPhone and iPAD client apps

·         Microsoft Silverlight or Adobe Flex for RIA clients

 Now consider that you can accomplish all of the above with one toolset: Magic xpa Application Platform. The Magic xpa Application Platform can create client-server apps; Web apps; BlackBerry, iOS, and Android mobile apps; and RIA apps. Magic xpa = all of the above. As a result, the value of “Tools” in the COCMO II model is 1. In essence, Magic xpa adds zero effort.

Lest you conclude that you should just stay with eDeveloper or some older version of Magic, however, let me remind you that Magic xpa is a huge improvement over eDeveloper. In essence, upgrading to Magic xpa brings the value of Tools to less than 1, further reducing effort.

Magic xpa introduces development productivity enhancements that dramatically decrease new function development time, and increase maintainability for existing functions. These are only a few examples of the many enhancements developers enjoy when using Magic xpa:

o   New IDE look and feel – By grouping dataview and logic statements under different tabs and allowing collapsible code snippets, developers find it easier to navigate the code

o   Functions – By enabling developers to create functions, developers can create cleaner and leaner code, increasing reutilization of code snippets.

o   Debugger – The new enhanced debugger allows stepping through code, adding break points, variable watches, and real time debugging, dramatically enhancing maintainability and bug fix delivery times.

o   XML integration – By exposing XML files as data sources, Magic xpa enables developers to consume and provide web services, completely removing the need to read, write and analyze XML files.

o   The Project File – Magic xpa utilizes XML source files. This creates a faster development environment, eliminates the need for a RDMS system to manage code, and enables usage of standard version control systems.

o   Web Services – Magic xpa differs from eDeveloper in the way it implements and consumes web services, to facilitate an enhanced web service offering Magic xpa leverages Web Services standards for SOAP and RESTful Web Services.

o   SubForms – The subform is a new UI control in Magic xpa which revolutionized the way developers create, develop, design and call subtasks.

o   Argument Matching – Magic xpa has full argument matching on task calls and automatic parameter creation on event handlers which eliminate code syntax errors

o   Line Level Comments – Allow eliminating inline documentation, therefore enabling cleaner and more readable code without forgoing documentation and allowing hint and developer help creation,

o   Studio and Runtime Separation – Allows developers to test application crashes without breaking the development studio therefore creating stronger and more robust applications.

o   Multi Tasking – By allowing parallel execution of programs, Magic xpa allows developers to create a productive user interface for application customers.

o   .NET Controls – Magic xpa is fully .NET based therefore creating a better looking and native looking user interface for the application customers.

For additional information on how an upgrade to Magic xpa is superior to Magic eDeveloper or uniPaaS to .NET conversion please convert here. 

End Programming Nightmares: Event-Driven Programming with Magic xpa Application Platform

Have you ever had that nightmare where you arrive late for an event and don't know how-to handle yourself? Everyone else seems to know what's going on, but you haven't a clue. Here's how-to avoid programming nightmares with Java and C#: Don't program in Java and C#. Magic xpa Application Platform avoids these nightmare programming scenarios and gives you a platform for an event-driven dream come true instead. 

Event-driven programming in the Magic xpa Application Platform allows for the flow of the program execution to be triggered by events and handled in a desired manner. Event-based software development in Magic xpa is based on the very powerful Magic xpa engine.

The Magic xpa engine distinguishes the Magic xpa Application Platform from other approaches to application development and deployment. With pre-built capability to perform complex data manipulations that are transparent to the developer and end-user, the Magic xpa engine is key to the productivity and performance provide by Magic Software’s approach to application development and deployment.

The engine includes a set of operations for the developer’s use in creating applications. It also serves up a structure of execution steps called logic units, which work with the operations to perform tasks for the end-user. The developer doesn’t have to tell the Magic xpa Application Platform how-to do its job. The engine already knows how to perform such actions as opening files, reading records, sorting, displaying data on the screen, and more.

Contrast this with traditional 3GL and 4GL languages where the developer has to provide detailed instructions through program code to tell a program how-to implement each and every step, regardless of how tedious and repetitive they are. Programmers developing in Java, C# and other languages get very frustrated by the fact that they have to repeat programming done hundreds if not thousands of times before by others. Many throw up their hands on the whole process of programming and say “Been there, done that” while others almost seem to enjoy being slaves to their code. By contrast, Magic xpa saves the developer considerable amounts of time by supplying these built-in operations and execution steps.

Naturally, the Magic xpa engine includes extensive support for event driven programming. Events, triggers and handlers are built in concepts. Magic xpa lets you define the Magic xpa logic as a response to implicit and explicit events that may occur during the execution of a task.

In Magic xpa, an event is an abstract indication to the runtime engine that something has occurred within the running application. The runtime engine can either choose to ignore the event or respond to it. For example, a mouse click on a control issues an event in the runtime engine that a click has occurred. The runtime engine can then respond to this event accordingly.

Every event is triggered when the application runs. Some events can be triggered as a response to an external activation, such as when a key is pressed or when the mouse is clicked. Other events can be triggered when a certain stage in the application is reached, such as an elapsed time period. Some events can be defined as triggers of other events.

A handler is a logic unit that runs when an event has occurred. A handler is defined to handle a specific event.

For the Magic xpa developer, an event is simply a logical definition of an occurrence. An event can be handled by an event handler to perform a flow of operations that the developer chooses. An event can also be assigned as a trigger of another user-defined event. When the triggering event is raised, it triggers the user-defined event. But Magic xpa isn’t just aware of events, it also allows the developer to handle events very specifically. In Magic xpa, a handler is a set of operations designated to be performed when a specified event is raised.

There are a number of different event types managed by Magic xpa.

System events are triggered by defined keystroke combinations. Magic xpa developers can define keystroke combinations for system events in a dialog box.

A Magic xpa internal event is usually handled by Magic xpa itself. But you can define a new or additional handler for these internal events.

Additional user events can be defined in the Event repository by the developer.

Timer Events within Magic xpa are based on durations, so that for every time interval of a specified duration, the event is invoked.

Expression Events are vents that are triggered when an expression evaluates to True. If the expression evaluates to false, then the event is not triggered.

Error Events are invoked when database-related errors occur such as a duplicate index or record that has been changed by another user.

ActiveX events are still used in some programs that use COM objects and Active X. An ActiveX event is raised for COM objects. If the event has built-in variables, they are created in the handler. It should be noted that ActiveX events are not supported with rich client tasks.

.NET events are preferred in rich client mode, where Magic xpa includes full support for .NET variables and events. When an event has built-in variables, they are created as parameters in the handler with the relevant .NET type. You can also define an event handler without defining a variable. In such a case, you can write the object from which you want to select the event.

Magic xpa events can be project-related events, triggered during the execution of any of the project's programs or task-related events confined to a specific task in which they are defined or to the task and its subtasks.

An event can have more than one trigger and more than one handler. Each trigger can raise the event in a different scenario. One or more handlers can handle the event for each scenario. This allows for complex event driven programming while avoiding the complexity of line-by-line coding. An event handler logic unit is the actual response to an occurring event.

When an event is triggered, the runtime tree is scanned from the bottom-most task up to the Main Program for a handler that corresponds to the triggered event. (The runtime tree is the collection of all the tasks that are currently running under the same context. The task order in the runtime tree is the order in which they were opened.) The engine sequentially executes the operations defined for the handler once it has been found. After executing the last operation in the handler, the engine continues up the runtime tree looking for another matching handler. After reaching the Main Program and executing any handlers found, when the triggered event is an internal event, the engine looks for internal engine handlers for the triggered event. The Main Program is the parent program of all other programs in the project, and it is always at the top of the runtime tree at runtime. This means that a handler defined in the Main Program is a global handler for the entire project.

Handlers of the same event, which are defined in the same task, are executed according to their location in the Task Editor from the bottom upwards.

End Programming Nightmares. The Magic xpa application platform is available commercially from Magic Software Enterprises.

Developing for the Web: Merge Technology

Who does the heavy lifting in a Magic xpa application mashup? Is it HTML5, CSS3, JavaScript or the Magic xpa Application Platform? 

To better understand mashups in Magic xpa, we need to remember that Magic has supported merge applications in general and HTML merge specifically for nearly two decades. The basic idea is not new, but all the players have been improved.

As readers of this blog know, Magic xpa Application Platform’s hybrid deployment capability provides support for a wide range of deployment architectures. On the client, these include on-premise (client/server), desktop, Web (HTML5), browser-independent Web 2.0 rich Internet applications (RIA), cloud-enabled software-as-a-service (SaaS), and multiple mobile platforms, including Android, iOS, BlackBerry and Windows, and on the server, Microsoft Windows, Sun Solaris, IBM AIX, Linux and IBM i. All of the various deployment modes are defined in the same application metadata and development project—meaning that application changes can be done once and are automatically propagated in any deployment mode.

Magic xpa’s Studio and ready-made business application engine utilize and interface with all major frameworks, such as Java and .NET, all major databases, and all communication standards and protocols. The question is, with so many options, how do we use Magic xpa to produce HTML5 mashups, or more accurately, HTML merge applications?

HTML Merge-based Applications

Magic xpa lets you design and develop an application for the Internet or Intranet by using: HTML and Java-based interfaces. Any HTML browser on any platform can access a Magic xpa application based on HTML Merge functionality. The Merge technology lets the developer create dynamic Web pages on the server side as a response to HTTP requests.

Concept

Using a set of tokens that are embedded in a regular HTML/XML file, the Magic xpa Application Platform Enterprise Server can merge any application data into the HTML or HTML5 file to produce a dynamic Web page. Magic xpa also uses form models to simplify the inheritance of GUI and other properties across multiple merged Web pages. You can also use any HTML5 editor to create your HTML5 template pages. Magic xpa

Every request for a dynamic Web page activates a corresponding batch program. This program can receive data from the request, such as submit form variables and cookies, process the application data according to the request information, and process the application logic to produce the merged Web page result.

From the Form editor, you can edit the HTML directly, either by zooming on the form from a Merge program, or by clicking on the HTML Editor in a browser-client program. By default, Notepad is the editor that appears.

However, you can choose which editor you want to use. Using an editor designed specifically for HTML, such as Front Page or Dreamweaver, can be useful.

Characteristics

Page Mode Execution

The interaction between the browser and the server is usually manifested in the retrieval of new pages as a result of a request submitted by the previous page.

Compliancy with All Browsers

The developer can choose the HTML/XML version for the application’s Web pages and any other use of client-side scripts and modules. The developer can decide on the level of Web browser compliance by choosing the HTML/XML version and additional modules.

Application Logic

The logic for merging application data into standard HTML files is server-side logic. Any client-side logic required for the application can be integrated with the Magic xpa-generated dynamic Web pages in the form of client-side scripts, such as JavaScript or VB script, and client-side modules, such as ActiveX controls and Java applets.

Controlling the Interaction

The fact that the application logic executed by Magic xpa is server-side only and that the developer determines the client-side logic, including the available hyperlinks, provides full control of the level of interaction between the client and the server.

Context Management

Any request handled by the Enterprise Server is handled independently with no correlation to previous requests submitted by the same application context for a given end user. This means that the application flow context management should be constructed and maintained by the developer.

Considerations

The Merge technology is suited for lightweight interaction between the browser and the server. This technology is designed for applications that mainly receive whole pages on each request.

Network Throughput

The number of interactions between the server and the client is relatively low and the amount of information passed from the browser to the server in every interaction, for example an HTML form’s submitted information, is also low.

However, the result page for every request may be large as the page always returns not just the new processed data but also the entire HTML portions that define the interface and design.

Given the fact that the volume of information passed from the client to the server, i.e. the uploaded data, is usually low, excluding file transfers, there is no need for a large throughput from the client to the server, i.e. the upload rate does not need to be great.

You should try to make your pages as light as possible or make sure that the end user machines have sufficient download capabilities.

Client Machine Requirements

Unless the developer chooses to enhance the pages with various objects, such as ActiveX controls and Java applets, no special requirements are set for the client machine.

Unknown Users

The ability to create applications supported by all browsers lets you freely distribute a Merge-based application with no need to know the end-user machine specifications or count licenses.

Client-side Scripting Skills

If the Web application requires client-side logic, the developers need to acquire knowledge and skills in client-side scripting. Alternatively, the HTML can appear inside the Magic xpa client, such as a Magic mobile client.

So this leads us to the question we started with? Who does the heavy lifting? I think each technology plays its role in a mashup or merge application. Magic xpa does the heavy lifting in terms of the data layer and the logical layer. Familiar web technologies such as the browser, HTML5, CSS3 and JavaScript can be used for client side interactions. 

Quite often, a pure Magic xpa rich client application can replace the need for HTML merge. Increasingly, we are seeing RIA apps on the Internet that allow a single developer to build the client-side and server-side apps without scripting approaches. Whenever this is possible, it is preferred and Magic xpa does all the heavy lifting, leaving HTML5, CSS3 and JavaScript in the dust.