How many times do you want to open a recent or commonly used object like an action diagram, procedure step or work set and have to waste time scrolling through a long list of objects to find it? Conversely, how many times do you use the ability to 'pin' frequently used documents in products like Word or Excel, or use the Recent Files options available in many tools?
If like me the answer is often, then you will enjoy the new feature in the Model Explorer to maintain a recently used objects list
Tuesday, 23 October 2018
Monday, 22 October 2018
Studio Developer Cool New Feature #8 - New UI Designer
Studio Developer contains all new designers for both GUI windows and block mode screens which make significant improvements to the Gen UI design capability, based on user feedback and enhancement requests provided by the Gen community.
Key features of the new UI Designer include:
Key features of the new UI Designer include:
Friday, 19 October 2018
Studio Developer Cool New Feature #9 - Model Explorer
At the heart of Studio Developer is the Model Explorer which provides access to objects in the model via a tree
structure.
At the top-level there are entries for the most commonly used object types, for example
At the top-level there are entries for the most commonly used object types, for example
Thursday, 18 October 2018
Studio Developer Cool New Feature #10 - Modern IDE
At number 10, we start off our series on the 10 cool new features with "Modern IDE".
More and more developers learn to code using a modern IDE and so when they start using CA Gen's current toolset, or have to switch between Gen and a modern IDE, the contrast between the user experience of the Gen toolset and the modern development tools
Studio Developer Cool New Features
With the recent announcement of the availability of the new Studio Developer from IET on 31st October, we thought we would count-down to this milestone date by previewing 10 cool new features in Studio Developer. Each day a new feature will be highlighted, so visit this blog every day until launch on the 31st of October!
Friday, 17 March 2017
Bye Bye TIREVENT
Gen GUI logic allows you to invoke an event handler via a USE of a dummy action block called TIREVENT. For example, to invoke the event handler called "CLICK_LOGIC" you could define an event called "CLICK" in the window and then invoke it as follows:
SET temp_tirevent.ief_supplied.command TO "CLICK"
USE tirevent
WHICH IMPORTS: temp_tirevent.ief_supplied TO Work View in.ief_supplied
SET temp_tirevent.ief_supplied.command TO "CLICK"
USE tirevent
WHICH IMPORTS: temp_tirevent.ief_supplied TO Work View in.ief_supplied
This use of a dummy action block TIREVENT has always seemed a bit strange and unnecessary, so for a Rapide application, you can now invoke the event via an API call:
INVOKE temp.rapide.object . postEventToSelf( "CLICK" )
However you would still need to create the event in the window design, which again seems unnecessary, so you can now also just directly post an event to invoke the event handler by its name:
INVOKE temp.rapide.object . postEventByName( "CLICK_LOGIC" )
Simples...
Auto Suggest Fields
A new feature in Rapide allows you to define an auto-suggest field.
In the example below, the entry field for a country is supported by an auto-suggest list that shows the list of countries that start with the current value of the field.
Unlike a drop-down selection which has to contain a fixed set of data and which, if triggered by a keypress event, would slow down typing in the field, the population of the auto-suggest can be handled by an asynchronous thread in the client p-step and hence the data could be retrieved from a much larger dataset (for example from a database table via a server or web service) without affecting the user's ability to continue to type in the desired value.
In the example below, the entry field for a country is supported by an auto-suggest list that shows the list of countries that start with the current value of the field.
Unlike a drop-down selection which has to contain a fixed set of data and which, if triggered by a keypress event, would slow down typing in the field, the population of the auto-suggest can be handled by an asynchronous thread in the client p-step and hence the data could be retrieved from a much larger dataset (for example from a database table via a server or web service) without affecting the user's ability to continue to type in the desired value.
Wednesday, 21 October 2015
Inline Code Example
In CA Gen the in-line code statement allows you to enter native code without needing to create an external action block.
In genIE we have a requirement to create a UUID which for the C clients was implemented in an external action block.
The equivalent implemented for Java using in-line code was very simple and only took a few seconds to code.
Friday, 17 July 2015
Managing Web Services
CA Gen Studio provides an option to define custom web service interfaces to server procedure steps. You can then use Gen Studio to generate the WSDL and XSL files for the web service and then assemble these into a WAR file for deployment to an application server.
We were recently asked by a GuardIEn customer whether they could use our XOS (External Object Support) add-on to manage the generated WSDL/XSL files so that as they promoted a change through the life-cycle, these files could be 'migrated' to the next environment along with the object migration of the procedure steps.
Whilst this would have been possible, it raised an interesting point about whether generated code should be copied between environments or re-generated from the model in the next environment,
I don't think it is a good idea to copy the generated source code from an uncontrolled environment like the first development model. The reason for this is that the state of the model and in particular the synchronisation between the model and the generated code is difficult to establish. This is especially true for code generated from the toolset, since it could be generated without uploading the changes to the encyclopaedia, or the model could be changed without re-generating the code.
At IET we recommend that the Gen objects are migrated to the next environment's model(s) as part of a controlled 'system update'. When using GuardIEn, the automated impact analysis will ensure that all of the code affected by the migrated objects is regenerated and installed. Generating direct from the encyclopaedia ensures that the model and generated code are synchronised.
A further complication arises because the web service definition can contain interfaces to multiple procedure steps. The wsdl and xsl files are tied to the import and export views for the procedure step and need to be regenerated when the procedure step's interface changes. What happens if you have a web service for multiple procedure steps, change the interface to two or more of them and then only migrate one of the changed procedure steps to the next environment? If you copy the entire web service, the result is that interface definitions in the web service do not match the view structure for the procedure steps in the next environment.
It therefore seemed a bad idea to copy the generated wsdl/xsl files from the toolset and the same principle of re-generating code from a stable model should be adopted. The problem though was that the web service generation feature of CA Gen was only available from Gen Studio and not the encyclopaedia generation.
In consultation with the customer, we decided that the best approach would be to develop a new web service generation feature in GuardIEn so that the web services could be properly managed via re-generation from the model as part of a GuardIEn system update. This new feature is now available in the latest service packs released yesterday.
We were recently asked by a GuardIEn customer whether they could use our XOS (External Object Support) add-on to manage the generated WSDL/XSL files so that as they promoted a change through the life-cycle, these files could be 'migrated' to the next environment along with the object migration of the procedure steps.
Whilst this would have been possible, it raised an interesting point about whether generated code should be copied between environments or re-generated from the model in the next environment,
I don't think it is a good idea to copy the generated source code from an uncontrolled environment like the first development model. The reason for this is that the state of the model and in particular the synchronisation between the model and the generated code is difficult to establish. This is especially true for code generated from the toolset, since it could be generated without uploading the changes to the encyclopaedia, or the model could be changed without re-generating the code.
At IET we recommend that the Gen objects are migrated to the next environment's model(s) as part of a controlled 'system update'. When using GuardIEn, the automated impact analysis will ensure that all of the code affected by the migrated objects is regenerated and installed. Generating direct from the encyclopaedia ensures that the model and generated code are synchronised.
A further complication arises because the web service definition can contain interfaces to multiple procedure steps. The wsdl and xsl files are tied to the import and export views for the procedure step and need to be regenerated when the procedure step's interface changes. What happens if you have a web service for multiple procedure steps, change the interface to two or more of them and then only migrate one of the changed procedure steps to the next environment? If you copy the entire web service, the result is that interface definitions in the web service do not match the view structure for the procedure steps in the next environment.
It therefore seemed a bad idea to copy the generated wsdl/xsl files from the toolset and the same principle of re-generating code from a stable model should be adopted. The problem though was that the web service generation feature of CA Gen was only available from Gen Studio and not the encyclopaedia generation.
In consultation with the customer, we decided that the best approach would be to develop a new web service generation feature in GuardIEn so that the web services could be properly managed via re-generation from the model as part of a GuardIEn system update. This new feature is now available in the latest service packs released yesterday.
Tuesday, 23 June 2015
Updating Mobile Apps
Whilst we would hope to never have any serious errors in our applications, it is a fact that no matter how much testing is done, there will be some bugs in an application, especially for complex business systems.
Having fixed the bug you will naturally want to release it to the end users as soon as possible, especially for high priority issues that might stop the app working or even cause data corruption.
For web based applications this involves a refresh on the application server. GUI clients can also be quickly updated using a variety of methods. But what about mobile apps that are distributed via a public app store and where the updates need to be approved by the app store vendor before they are released? This can take some time - for example over a week is common.
If you develop your mobile apps using Rapide, because the client logic and UI definition resides on the application server and not the device, a refresh of the app is as simple as deploying an update to the app server.
As long as you do not change the app branding (name, icon, splash screen or app server URL), the application can be updated without needing any refresh on the mobile device.
Having fixed the bug you will naturally want to release it to the end users as soon as possible, especially for high priority issues that might stop the app working or even cause data corruption.
For web based applications this involves a refresh on the application server. GUI clients can also be quickly updated using a variety of methods. But what about mobile apps that are distributed via a public app store and where the updates need to be approved by the app store vendor before they are released? This can take some time - for example over a week is common.
If you develop your mobile apps using Rapide, because the client logic and UI definition resides on the application server and not the device, a refresh of the app is as simple as deploying an update to the app server.
As long as you do not change the app branding (name, icon, splash screen or app server URL), the application can be updated without needing any refresh on the mobile device.
Subscribe to:
Posts (Atom)