/*Answers to Q&A Technology Stack Livestream*/

Go to Portuguese answers     Go to German answers

Language and Framework

• Will alias tables work the same way?
  The concept of alias tables is still possible, the way it currently would work is by simply instantiating another DataDictionary of the same Entity with a different Object name.
   
• Had the concept of ‘global file buffer’ and ‘local buffer’ going to be a thing of the past with Technology Stack phase 2?
  The global file buffer will be gone in the first releases of techstack. When converting code that relies on the global file buffer a global singleton instance of the DDO structure can be used as a replacement for the global buffer since the global database API’s will be redirected to Data Dictionary instances.
   
• With the redesign of datatypes will there be a native Null support?
  We currently have experiments running for Null support on Struct members.
   
• How much do I have to massage my existing code to make it work with the new runtime?
  The language is fairly compatible, with some very obsolete techniques removed. The classes however have seen some changes like a new cHttpClient instead of the cHttpTransfer classes. Also, the Windows UI framework won’t be included as the initial focus is on Web and Flextron for now. All Web UI Object code, however, should be very compatible as we use the same Web App Framework you are accustomed to.
   
• Will we still be able to use a tablename.columnname symbol when we reference a table column in the source code?
  Yes we have rerouted all global Database APIs to the DataDictionaries, meaning that as long as you replace the table name with a DD you should be settled. If you want the backwards compatibility, it should be as simple as creating an Object with the same name as your table name and you should be settled (as we see it currently).
   
• What will be the replacement for properties data_file and data_field?
  Anything that gives a hint as to what our code will look like when we access our databases is interesting. They still hold purpose as the Data_File is now replaced with a handle to the DataDictionary object. As such existing code using these should still work.
   
• There is no more file list, how do you expect to handle changes to it?
  The studio will contain the table editor and other tools you are accustomed to. However, now it will also be possible to make changes in code.
   
• Would the client side runtime allow function keys to be used again?
  The Client Web Application Framework already supports function keys using Key Handlers. These will keep on working.
   
• To clarify re function keys, will a webapp client respond to e.g. F2 = save?
  WebApps do respond to function keys already including F2. Note that if the focus is not on a Web Control the browser might perform its default operation.
   
• If a browser act on e.g. fn+page down to scroll down a web page, it cannot act as a next-record.
  You can override the default behavior of browser function keys in most modern browsers.
   
• There’s going to be wizards for ‘Create struct/entity from DB table’ and things like that, right?
  We already have tooling internally to convert DataFlex table definitions through the studio to an Entity definition file. Wizards would be a next step.
   
• When defining tables as structs, can you also specify indexes on the table?
  In the current internal iteration, you provide your columns, attributes, indexes, and relationships between the entities.
   
• So how might the syntax inside Procedure Creating or Update (say) in a DD Class definition look like? As in, you might want to update a parent table but won’t know the DD object name.
  Though you can already do these using methods to find the table responsible for a certain table. You can find them in the documentation for the current stack. Depending on the use case we still have to figure some of this out. So, we hope in the long run the manner will be appreciated if not compatible.
   
• Will the new HTTP Transfer class (cHTTPClient?) methods and properties etc. operate the same or will the changes (I will have to make) be kept to a minimum?
  There are some changes, however the API will be familiar and is designed to last the next 20+ years. Know that you are now also able to use this API on all platforms (WebAssembly, Windows, etc.).

Studio

• How about the Studio, will that be web-based or Windows-only?
  TechStack will use the existing studio which will remain to be a windows application for the foreseeable future. The long term vision is to have a Web-technology-based studio.
   
• Will the Studio run on Linux and macOS in the future?
  That’s the long-term goal. Applications will initially run through WebAssembly, and later also natively on Linux and macOS. For the Studio itself, we’re gradually moving toward making it web-based. That would mean it could run as a FlexTron application on Windows, macOS, or Linux, or even in the cloud. There’s no set timeline yet, but every decision we make today is with that goal in mind. For now, the Technology Stack will continue to use the current Studio.
   
• Will DataFlex support other editors like Visual Studio Code?
  We’re actively exploring that. We’re not planning to replace the current Studio, but we want to be more open to external tools. For instance, we currently have an intern working on a language server (LSP) for DataFlex. LSPs are what make features like IntelliSense work in editors like VS Code. This would allow other tools and editors to better support DataFlex. Long-term, it also opens the door to replacing the Studio’s editor with something more modern like Monaco – the editor used in VS Code.

Data

• What happens if you compile the database model into the application and then run it on different companies with different field sizes?
  There will certainly be flexibility in the system to handle cases like that.
   
• Will the DataFlex come with a default database backend or a free recommended database to replace the current embedded database for new programmers to use?
  We currently intend to replace it with SQLite to provide both the ease of a single-file database together with the power of SQL.
   
• How do you envision the data connection between the client and the server?
  This connection is of course completely optional, offline support and all, you can connect manually using the cHttpClient or using the HttpDatabaseDirvers we are going to provide for working with Data Binding and Data Dictionaries.
   
• Tips on how to quickly deploy new updates (and database changes) seamlessly to OnPremise customers?
  We currently have not completely designed the restructuring of database tables, but we will take this into account when designing this.
   
• Data Dictionary API is very verbose, how does that work?
  Data Dictionaries are completely rewritten in DataFlex code allowing you to debug it better and see what is going on. We will also refactor them and provide additional backwards-compatibility layers for those that need them.

 FlexTron and Windows

• What will the model for a FlexTron application look like?
  Presumably it still requires the DataFlex client to run the .exe, but the newer runtime will be running within the local control host(s). While it would be possible, it would merely create overhead costs. As such the new runtime will then run natively on Windows like it does now and use the current FlexTron Paradigm with just a JS Web App Framework.
   
• How long will native Windows desktop applications be suppported?
  The Technology Stack runtime will not support native windows desktop applications for the first revisions. And even when it does then converting large existing applications to the new stack will be an investment that not every customer will be able to make. So we intend to support the classic runtime for a long time, which means that we will continue to provide updates to fix bugs and add features for the foreseeable future.

Timeline

• Whats the ETA for Technology Stack?
  We hope to work as soon as possible towards a Technical Preview, this will resemble the development cycles we have seen during the development of DataFlex 20.0.
   
• When can we expect the first versions for docker image?
  This is expected in phase 2 when we’ll create a new Web App Server that does depend on Internet Information Server and will run on platforms other than windows. You should then be able to download a published webappserver image.

Other

• Is DataFlex working with AI?
  Yes, we’re experimenting with AI for features like code completion. Think of it as a convenience copilot for developers. It’s still early, but we’re exploring how AI can support and enhance the development experience.
   
• Why do we have a numeric primary key, why not go to UUID straight away?
  Most database systems provide auto numbering and we intend to use auto numbering of the backend when possible. When a back-end supports UUID the intend to support that as well. UUID vs numeric keys is also a matter of preference.
   
• How is this going to be secure? How does the server know it’s actually the DataFlex application?
  Security will remain the same, as with normal web development in any language you are still required to provide Authentication behaviours and checking session tokens etc.
   
• Will DataFlex ever allow Windows authentication in WebApp so users can use their Windows credentials to logon to webapp?
  There are ways to already do this. One is at IIS level where you can tell it to authenticate and then in DataFlex you can check HTTP headers in the Session Manager to get which user is logged in. The other is that we are currently working on a Single-Sign-On library with IntraID support for Azure Cloud support.
   
• What will the license policy be for the new runtime i.e. docker images, WebAssembly?
  We currently have no answer to this question. However, it is to be expected that for WebApp Server deployments we’ll have a similar licensing scheme that is currently employed.
   
• You mentioned user counting is not possible in JavaScript. Will it be possible in WebAssembly?
  No as both are run on the client and like in Web Development a client can never be "trusted" to be secure and tamper-proof.
   
• There is no workspace file, why?
  In the WebAssembly environment we don’t want to rely on many external files at runtime. So in the WebAssembly environment we do not expect to want (and need) a workspace file. At other (native) platforms the workspace file might return when we see a need for it.
   
• Is the move from the US to Europe driving this change?
  Not directly. This could’ve happened in the US too. Our European R&D team was already involved in the development of DataFlex and they’ve been able to attract new talent, which gave us the opportunity to take on projects like this.
   
• Are the Unit test part of the future DataFlex package or an addon Library?
  It currently is an addon library you can find at here.
   
• What about GitHub and Git integration?
  Git integration in the Studio is a popular request. The ability to work with repositories, see changes, and commit directly. It’s definitely on our wishlist, but not something we’re actively developing right now. What we are actively working on is getting DataFlex better integrated with GitHub. We want it to be recognized as a language, with proper syntax highlighting and improved search support. We’re also sharing more open code on GitHub to support the community and be more transparent.