![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder Public Beta Tests » View Thread |
Messages 1 to 3 of 3 total |
![]() |
Fri, May 29 2020 2:49 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | I've uploaded Build 14 of the beta. There are a *lot* of changes in this build, several of them breaking, so please read the following carefully:
- The database API is now complete, including for server applications. However, there have been some pretty significant changes made to how the database API works. Instead of having a dataset defined with SELECT, INSERT, UPDATE, and DELETE SQL as part of the dataset, EWB 3 now splits out the dataset commands as separate entities. This change was required due to how BLOB updates work: when you combine BLOB updates into the UPDATE statement for the entire dataset, it prevents selective update of BLOB columns and requires weird IF() expressions in the UPDATE statements to avoid NULLing BLOB columns if the parameter for the BLOB column is not passed to the web server because it wasn't updated (server applications right now, but eventually client applications will also be able to update BLOB columns directly). Furthermore, this new architecture makes retrieving individual BLOBs much faster and efficient because the BLOB retrieval is performed with a separate SQL SELECT command that only selects the BLOB (and, optionally, the special <BLOB>_ContentType column) for the specific row that needs it, instead of re-executing the dataset's SQL SELECT command and positioning on the desired row to retrieve the BLOB column contents. Finally, this new architecture also provides the ability to define datasets that don't actually allow reading, but instead only allow INSERT, UPDATE, and/or DELETE statements. The naming of the dataset commands is important: the SELECT, INSERT, UPDATE, and DELETE commands should be named "Select", "Insert", "Update", and "Delete", respectively. For BLOB columns, the SELECT and UPDATE commands are named "Select<Column Name>" and "Update<Column Name>", respectively. The dataset command generation has now been moved from the dataset dialog to a separate context menu option in the Server Manager. It also now allows you to select exactly which dataset commands you wish to generate for a given dataset. As part of this change, the entire database API is also now "primary key-agnostic". What this means is that datasets no longer require key column information, and instead they rely solely on the defined parameters within a given dataset command's SQL to determine what needs to be populated for WHERE clauses, etc. This also means that the new TDataColumn.Key property is no longer necessary, so you will need to remove it from any custom JSON database APIs that you may have implemented for web servers other than the EWB 3 Web Server. My apologies for this last-minute change: I know some of you have already added the Key property to the JSON exchange for your web server API. This change required that the EWB Web Server database format be changed. This change is transparent to you and will happen automatically when you start up the build 14 IDE (the database is automatically versioned). However, once a database is updated to the new format, it will not be usable with any older versions of the EWB IDE or web server. This change also required that the privileges/roles be modified to handle the privileges at the dataset command level instead of at the dataset level. The build 14 EWB Web Server will automatically add the necessary privileges for the new dataset commands and add these privileges to the existing Administrators role. However, it will *not* remove some of the old, outdated privileges that were relevant to the older way of having the privileges tied to the dataset, so you may want to delete those manually. Just to clarify: there are no changes required for client applications, but you will need to recompile any client applications so that they pick up the new client-side code for the database API. All of the changes mentioned above are either in the IDE, the web server, or both. You will also want to re-run the Install Example Applications option from the Help menu in the IDE. That will ensure that all example datasets are set up properly with the proper dataset commands, and that they match the changes in the example applications. For example, the Multimedia example application has been changed a bit and now has custom backgrounds for the various albums in the sample dataset. Finally, there are two new "automatic" parameters in the parameter handling for dataset commands: the EWBSessionID parameter and the EWBUserName parameter. Including these parameter names in any dataset command will result in the EWB Web Server automatically setting their values to the current request's session ID and/or the current request's authenticated user name. This allows you to define dataset commands that operate specifically for the current session and/or user only, which is important for preventing other users from seeing data that only the current user should see. Here is an example of a Select dataset command that uses the current user name to restrict the rows returned to the current user: SELECT * FROM Profiles WHERE UserName = :EWBUserName - There were some issues with how the compiler defines were being handled by the compiler. Specifically, the compiler was setting up compiler defines as a global construct and not resetting them on a per-unit basis. This is now fixed. In addition, you can now define project-wide compiler defines in the Project Options dialog in the IDE (semicolon-delimited list of defines), as well as via a command-line compiler switch (run ewbcc.exe to see the details/instructions on how to use). The compiler defines in the Project Options dialog *do* affect the current compilation status of the application, so if you modify them, it will cause the application to be recompiled in the next compilation pass. So, there's no need to perform a manual compilation of the application after modifying the compiler defines. Finally, as part of these changes, the server application format needed to changed (server applications are compiled on-demand by the web server, so it needs the compiler defines in the application). You will need to recompile any server applications before trying to execute them with build 14 or higher. Failure to do so will result in a server application loading error when the web server tries to compile any server application created with build 13 or lower. - The TLS issues with the EWB Web Server are now all fixed, and you should be able to both modify the URL for the Internal web server to use secure connections in the IDE, as well as use the external EWB Web Server with secure connections. As part of the TLS fixes, I also made sure to go back through the localhost self-signed certificate handling to ensure that it would work with all modern browsers in the development environment. In the process, I determined that I could no longer have the certificate installation be automated during the product installation (see below about the Windows warning dialog during root certificate creation). Therefore, you will need to manually run the ewbcert utility before starting the IDE in order to avoid the IDE warning about a missing localhost certificate along with preventing the Internal web server in the IDE from starting. The ewbcert.exe utility has been modified so that it now behaves as follows: 1) When creating a new localhost certificate, the ewbcert utility will *first* create a self-signed root certificate for the specified store type (current user, by default). This will cause a warning dialog to appear that you will need to confirm before the root certificate will be created. 2) After the root certificate is created, the localhost certificate will be created and signed using the root certificate created during step 1). This process will allow the localhost certificates to work with Edge and Chrome without further intervention. FireFox will still require that you agree to allow the use of the localhost certificate before you will be able to use it with secure connections. - There was an issue with sending attachments with the new TMailer component (the attachments weren't being base64-encoded like they should have been). This is now fixed. In addition, the Execute function now returns a Boolean and the TMailer component no longer requires you to inspect the status codes in order to determine if the sending was successful (the status codes are still there to view, but aren't required). For reference, this is how you would send an attachment using GMail and the new TMailer component in a server application: procedure TReqHandler1.SendMail(Request: TWebServerRequest); var TempEmailAddress: Variant; TempFileStream: TFileStream; TempResult: Boolean; begin with Request do begin TempEmailAddress:=Request.RequestParameters['Address']; with Mailer1 do begin Host:='smtp.gmail.com'; UserName:='<GMail Address>'; Password:='<Google App Password>'; MailFrom:='"Tim Young" <GMail Address>'; MailTo.Add('"Tim Young" <timyoung@elevatesoft.com>'); MailSubject:='Test Email'; {$IFDEF MAIL_ATTACH} TempFileStream:=TFileStream.Create('c:\temp\form_logo.png',FILE_OPEN_READ or FILE_SHARE_DENYNONE); try with MultipartMailMessage.Add do Content:='This is a test email to make sure that everything works okay !!!'; with MultipartMailMessage.Add do begin Headers[MIME_HEADER_CONTENT_TYPE]:=MIME_DISCRETE_IMAGE+'/png'; Headers[MIME_HEADER_CONTENT_ENCODING]:=MIME_TRANSFER_ENCODING_BASE64; Headers[MIME_HEADER_CONTENT_DISPOSITION]:=Format(MIME_ATTACHMENT_FILENAME_DISPOSITION,[TempFileStream.FileName]); ContentStream:=TempFileStream; end; TempResult:=Execute; finally TempFileStream.Free; end; {$ELSE} MailMessage:='This is a test email to make sure that everything works okay !!!'; TempResult:=Execute; {$ENDIF} end; SetResponseNoCacheHeader; if TempResult then SendContent('Email sent successfully') else SendContent('Email send failed:'+CRLF+Mailer1.Transcript.Text); end; end; - There was one final issue with how the compiler was determining whether a given declaration was referenced or not, and this issue could cause the compiler to emit incorrect JS. This is now fixed. - There are also a bunch of small fixes in the IDE and compiler, including some further fixes to how the new code assistance behaves. Moving forward, the next build will contain the rest of the server application RTL functions for file/directory management, base64 encoding/decoding and more. That leaves only the audit/web server logging to surface in the EWB IDE, along with the server migration. Sam and I have also started on the documentation updates, so hopefully we can get everything finished by end of the first week of June. As always, thank you so much for your help in testing EWB 3. Stay safe ! Tim Young Elevate Software www.elevatesoft.com |
Sat, May 30 2020 9:37 PM | Permanent Link |
Steve Gill | Phew! That's a lot of hard work you have done.
Thanks Tim! = Steve |
Fri, Jun 5 2020 10:16 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Steve,
<< Phew! That's a lot of hard work you have done. >> There's a lot there, but I've been thinking about this change for a while, so it was just a matter of head-down typing for a couple of days. ![]() Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |