Showing all blog entries tagged with "Web Builder"

Elevate Web Builder 2.02 Build 3 Released

---

Posted by Tim Young on Sun, Oct 25 2015

Elevate Web Builder 2.02 Build 3 is now available for download. If you're an existing customer, then you should be receiving an email shortly with download instructions. This build contains a bug fix for a GDI+ bug when resizing controls/elements with outset shadows in the designers, which is detailed here.

---

Tags: Elevate Web Builder, New Builds

Permanent Link • 0 Comments

Elevate Web Builder Case Study - Environment Canada

---

Posted by Tim Young on Tue, Oct 20 2015

We've posted a new Elevate Web Builder case study as a technical article on the web site:

Case Study: Environment Canada Weather Reporting Application

Thanks very much to the Bruno Larochelle, the program manager at the Canadian Meteorological Aviation Centre, Edmonton office, for putting together this case study for us.

---

Tags: Elevate Web Builder, Case Study, Technical Article

Permanent Link • 0 Comments

Elevate Web Builder 2.02 Released

---

Posted by Tim Young on Tue, Oct 13 2015

Elevate Web Builder 2.02 is now available for download. If you're an existing customer, then you should be receiving an email shortly with download instructions.

2.02 Breaking Changes

---

The following are breaking changes in Elevate Web Builder 2.02:

• The TInterfaceManager.Scheduler property has been removed, replaced with a new async keyword (see below for more information on this).



• Layout consumption is now based upon the maximum consumption rectangle now, instead of the last element's consumption rectange. This provides a more logical layout behavior, especially with flow layouts.



• The "Hot" control interface state is now given preference over the "Focused" state with mouse-overs.



• The TPanel control interface's Visibility propety changed for the Client element.



• The TPanel control interface's Base and Client element backgrounds are now styled differently in order to allow proper use with height animations.



• The TGrid*Cell* control interfaces all contained incorrect Focused and Both state property settings for the Border.Top property that would cause unnecessary interface updates during grid cell updates. They should have been the same as the other interface states.



• The TMenu control interface Padding and Background.Fill.Color property settings added for the Client element.



• The TEdit, TMultiLineEdit, TEditComboBox, TFileComboBox, TGridEdit, TGridEditComboBox, TGridTextCell, TGridTextCellWithLines, and TGridColumn control interfaces' default Font.Color property changed to clElevateLightBlack in order to provide more contrast for editable text.

2.02 Improvements

---

The following are included improvements in Elevate Web Builder 2.02:

• The compiler now supports a new async keyword for executing function/procedure calls asynchronously.



• The TGrid control navigation/load performance as been greatly increased.



• There is a new OnAnimationComplete event for all controls that support animation.



• The entire selected row is now highlighted for the "Hot" interface state in the TGrid control when its RowSelect property is True.



• There is a new TBalloonLabel control and control interface added for displaying text in a word balloon.



• There are new OnEnter and OnExit events for the TMenu control.



• There is a new TMenuItemSeparator control interface.



• There is a new TMenuAddSeparatorButton control interface.



• There is a new DropDownPosition property for the TEditComboBox, TDateEditComboBox, TButtonComboBox, and TGridColumn controls for specifying whether the associated drop-down control should be placed relative to the owner control's position, or positioned in the center of the application surface.



• There is a new Responsive Panels example project added that shows how to use the layout overflow functionality to create flow layouts.



• New keystrokes in the form/control interface designer: the up/down arrow keys select controls/elements in layout order and the ctrl+up/down arrow keys select controls/elements in tab order, making the selected control/element visible, if necessary. This is useful for verifying layout/tab ordering, as well as finding any "stray" controls/elements that are not visible because they are beyond the bounds of their container.

---

Tags: Elevate Web Builder, New Releases

Permanent Link • 0 Comments

Elevate Web Builder 2.01 Build 2 Released

---

Posted by Tim Young on Thu, Aug 27 2015

Elevate Web Builder 2.01 Build 2 is now available for download. If you're an existing customer, then you should be receiving an email shortly with download instructions. This build contains several bug fixes for issues introduced in the initial 2.01 release, which are detailed here.

---

Tags: Elevate Web Builder, New Builds

Permanent Link • 0 Comments

Elevate Web Builder 2.01 Released

---

Posted by Tim Young on Wed, Aug 26 2015

Elevate Web Builder 2.01 is now available for download. If you're an existing customer, then you should be receiving an email shortly with download instructions.

2.01 Breaking Changes

---

The following are breaking changes in Elevate Web Builder 2.01:

• The parameters for the TReader constructor and Initialize method have been changed.



• The class for the TImage ContentLayout property has been changed so that it mirrors the background image layout options. You will need to reset the ContentLayout property settings for any TImage controls created using the initial Elevate Web Builder 2 release.



• Per this incident report:
  
  # 4196 Line Separators Incorrectly Set to Only LF Instead of CRLF in List-Based Controls
  
  the TListBox, TEditComboBox, and TButtonComboBox Items properties, as well as the TMultiLineEdit Lines property must be reset if they have been assigned values at design-time using the initial Elevate Web Builder 2 release.



• The Elevate Web Builder Web Server now automatically handles cross-resource origin headers for modules, so you do not need to manually handle such HTTP headers in your module code.



• The Elevate Web Builder Web Server now automatically assigns URL authentication parameters (user=<UserName&password=<Password>) to the RequestUser and RequestPassword properties of the incoming TEWBServerRequest instance passed in to web server modules. This is in addition to alread automatically handling any custom Elevate Web Builder HTTP authentication headers (X-EWBUser and X-EWBPassword).

2.01 Improvements

---

The following are included improvements in Elevate Web Builder 2.01:

• A new TControl Animations property that can be used to set up animations for the Left, Top, Width, Height, Opacity, and Visible properties of controls.



• You can now use the TLayout Overflow property to implement flow and responsive design layouts.



• There are new TCalendar and TDateEditComboBox controls for date selection.



• There is a new TMenu control for displaying vertical menus.



• There is a new TIconButton control for using icons like buttons.



• The TButton control now has an Icon property that you can use to specify an icon that will appear to the left of the caption on the button.



• There is a new TMap control for accessing Google Maps, including geocoding and marker support.



• There are new ctIcon, ctImage, and ctDateEditComboBox TGridColumnControlType members for the TGridColumn ControlType property, allowing icons, images, and date edit combo boxes to used with grid columns.



• There is a new TGrid AlwaysShowControls property for ensuring that grid column controls are always visible and don't need to be specifically enabled.



• You can now control the appearance of individual cells within a grid column using the TGridColumn OnCellUpdate event.



• There are new TGrid OnColumnChanged and OnRowChanged events for detecting when the grid's ColumnIndex and RowIndex properties change.



• There are new TGridColumn OnEnter and OnExit events that are fired as focus shifts to or from a grid column.



• For un-bound grids, you can now sort the rows using the TGrid SortRows method. In addition, you can use the TGridColumn OnCompare event to customize the sort.



• For un-bound grids, you can save/load grid rows to/from JSON using the TGrid GetRows and LoadRows methods.



• There is a new TServerRequest Timeout property (and a corresponding TDatabase Timeout property) for specifying request timeouts.



• There is a new Refresh method for the TImage, TPlugin, and TBrowser controls for refreshing their content without having to modify their URL property. This is useful when the content changes on the server, but the URL does not.



• There is a new TDialogCaptionBar AllowMove property that can be used to specify that a TDialog can be moved by dragging the caption bar, and a corresponding property for the TPanelCaptionBar and TPanel controls.



• There is a new TControl DefineLayout method for "pegging" a control to its current layout bounds.



• There is a new public (not published) TControl ClientID property that you can use to specify the unique HTML ID for the client UI element of a control. This is useful when you need to identify the element from external JavaScript.



• The emit clause for external classes now allows for namespaces with periods (this.is.a.namespace).



• The compiler now includes support for function/procedure references.



• The Ord function can now be used with Boolean values (0=False, 1=True).



• There are new DateTimeToISOStr and ISOStrToDateTime functions for converting to/from ISO 8601 date/time strings. These functions are useful when used with non-EWB REST APIs that use this date format to eliminate ambiguities with timezones/UTC.



• The TReader and TWriter classes now include a DateTimeFormat parameter in their constructors for specifying how date/time values should be handled when being read/written as JSON: as raw integer values (the default), or as ISO 8601 strings.



• There is a new WebDSnap unit containing a class called TDataSnapResult that can be used as a base class for creating classes for reading Delphi/C++Builder DataSnap JSON results from a server request



• There is a new AuthenticateUser method and a new OnAuthenticateUser event for automating user authentication in web server modules.



• There are new SendContentHeader and SendCustomContentHeader methods for handling HEAD requests in web server modules.



• There are new SendContentStream, and SendCustomContentStreammethods for sending content in streams as responses from web server modules.



• There are new HeaderExists, ParseHeader, and ParseHeaderAttribute methods for working with HTTP headers in web server modules.



• The Elevate Web Builder Web Server now handles PUT and DELETE requests and will relay them on to web server modules.



• The IDE now detects external source modifications, and will reload the modifications into the code editor.



• There are two new code editor options in the Environment Options dialog: wrap-around and external source modification prompts.



• New entire scope option for the find/replace bars in the code editor, and the find/replace bars now wrap their contents as the width of the IDE shrinks



• There are new default project options for automatically saving project files before compilation, saving/restoring non-project files, default form class for new forms, and whether new forms are automatically set as auto-create in the Environment Options dialog.



• New project, unit, form, and interface file naming is more logical now, and based upon the contents of the applicable current directory, as opposed to a base name with an ever-increasing, incremented file name suffix



• New animation layout example project that demonstrates how to use the TControl Animations property to build animations.



• New responsive layout example project that demonstrates how to build a responsive layout using the new TLayout Overflow property.



• New PDF Client and PDF Module example projects that show how to dynamically return a PDF file as a content response from an Elevate Web Builder module.



• New maps example project that shows how to use the new TMap control to display and manipulate maps using the Google Maps API.

---

Tags: Elevate Web Builder, New Releases

Permanent Link • 0 Comments

Why Limit Web Development to JavaScript ?

---

Posted by Tim Young on Fri, Aug 7 2015

I've been doing some browsing and reading recently, catching up on the current state of affairs in software development, and I came across several mentions of a quote by Anders Hejlsberg from the 2012 Lang.NEXT conference, where he was part of an expert panel on web/cloud development. You can watch the discussion yourself here:

Lang.NEXT 2012 Expert Panel: Web and Cloud Programming

I don't get as much chance as I'd like to keep up with what's going on in the industry, so at the time I missed this particular quote. In case you've been living in an even deeper cave than myself and don't know who Anders is, he created Turbo Pascal, was the chief architect of Delphi, is/was (?) the lead architect for C#, and is now working on the TypeScript language at Microsoft. As one can imagine, he definitely has some insights into the requirements of a successful development language.

During the discussion, he was asked the direct question:

"Are you saying you cannot write large programs in JavaScript?"

and he replied:

"No, you can write large programs in JavaScript. You just can't maintain them."

I won't profess to speak for Anders, but I would assume that he was talking in broad strokes with this response, and was not saying that all large JavaScript programs are un-maintainable. Rather, given a typical organization with typical resources and the typical amount of screw-ups and craziness that accompanies software development, one will typically find that large applications written in JavaScript are difficult-to-very-difficult to maintain. I'm sure that Google has no issues with throwing enough resources at flagship properties like GMail or YouTube to get them to work. But, it's probably a bad idea to predicate the success of a large segment of the software industry on always having Google-like resources at our disposal.

Of course, various blogs lit up with indignant responses, and the biggest pushback appeared to be coming from who you would expect: JavaScript developers.

Now, when I read the quote my first reaction was "duh !". This was one of the primary reasons that I started developing Elevate Web Builder in 2010-2011. Elevate Web Builder compiles Object Pascal into JavaScript, but this is not a unique idea and there are many compilers/transcoders that do the same for many different languages:

List of languages that compile to JS

Let's start out with some self-evident observations:

• There's definitely something amiss with a language if there's a list that long of compilers/transcoders whose sole purpose is to avoid writing code in the target language.



• JavaScript development can't be that bad, otherwise we wouldn't see the millions of web sites/web applications that are powered by JavaScript code.



• The JavaScript engines in the various modern browsers are very good. Performance is spectacular on desktop, and normally acceptable on mobile.

So, the question is not really "Is JavaScript, the language, any good ?", but rather "Should we use only JavaScript for web development ?".

Of course, once you start getting into "should" territory, you're normally talking about very subjective arguments. But, I think it's easier than that, and I'll try to demonstrate that the arguments against using only JavaScript are not subjective at all, and are easily recognized with an objective eye. But, please don't mistake the following points for a claim that other languages are perfect, or that you cannot do stupid, awful things with them. You can, and we all do. At issue here is whether we are moving forward or backward by using only JavaScript. I also think it's important to note here that much of JavaScript's maintainability problems stem from the fact that it's a very flexible language. In fact, in many ways it's similar to much lower-level languages in the sense that it lets you do just about anything. Unfortunately, flexibility is often the converse of maintainability. It is often the case that the languages we choose to use for development are as much about preventing us from doing bad things, as they are about allowing us to do good things.

Code Size

---

Because JavaScript is shipped to the browser as textual source code, there has traditionally been a size limit forced upon JavaScript developers that is derived from the bandwidth of a typical user's Internet connection. In the early days of browser development, connections were so slow that even a 30-50k source file would have been considered suicide. This resulted in source code that tried to keep identifiers as short as possible, which should not be necessary and is completely contrary to good software engineering practices. JavaScript minification was developed to ease this burden, but I'm probably not the only person in the world (or maybe I am) to wonder: if one needs to post-process their source code prior to deployment, then perhaps we should use this as an opportunity to recognize that shipping readable source code to a remote execution environment is probably not a wise choice. It's simple logic. If we don't ever want to ship source code because it's too large or there are IP issues involved, and the resulting minified source code isn't readable by a human, then why are we arbitrarily restricting ourselves to one language ? Shouldn't we just compile to web assembly ?

One can also imagine that this problem will only get worse as single-page web applications that load as pure JavaScript, such as Elevate Web Builder, become more and more prevalent, and as SAAS continues to replace traditional desktop/LAN applications.

This code size issue also plays into the problems with modularization and packaging of deployed code. Minification is great for monolithic source files, but is a non-starter for any identifiers in library source files. One can work around this by providing mappings in the library source code between the "real" identifiers and the minified identifiers, but once you start going down that road you will eventually discover that it's simply easier to just keep non-minified identifiers for any "public" objects/functions. Of course, if you're doing what you're supposed to and re-using code, then probably 80-90% of your code is in, or should be in, such library source files, and there goes any benefits of minification. This is why I just said "screw it" with Elevate Web Builder and had it generate a single monolithic JavaScript source file for each application. The reduced code size from aggressive minification/compression across the entire identifier space, including the component library, far outweighs any downsides from including more code. And, I removed any dependency issues in the process. Proper signed/versioned module support in the browser, combined with web assembly (above) that supports exporting symbols, could be a solution for these issues.

Structure

---

JavaScript lacks any formal structure whatsoever, other than the ability to organize code into functions and "objects" via prototypes. It has no formal modules or namespaces, and there are two implicit scopes: function and global (I'm including constructors in the "function" category). Object instances are essentially hash tables, which means you can do things like this with them:

// Declare the Car prototype

function Car (type) {
    this.type = type;
    this.color = "red";
    this.drive = function() { return "Vrroommm !!!!!" };
}

// Create a Car instance

var car = new Car('Ferrari');
car.color = "red";
car.engine = "V8";
alert(car.engine); // where did that come from !

car.drive = function() { return "Wrrrrrrrr !!!!!" }
alert(car.drive()); // that's not a sound a Ferrari makes

You can define methods for any object, but they are simply references to functions that can be overwritten just like any other property. Namespaces and certain types of class scopes can be fudged using nested object literals, and the language is making progress towards proper classes with configurable properties and sealing/freezing objects, but these are all features that are not implicit/enforced and must be consciously used by the developer. One gets the distinct sense that the JavaScript (ECMAScript, officially) language committee is trying to "close the barn door after the horse has left".

Type System

---

Conversations about formal types in JavaScript tend to get very heated, and many JavaScript developers vehemently deny that the lack of a formal type system is an issue for the language. I've read comments from developers that blame other developers for their inability to always write perfect JavaScript code without runtime type errors. To me, this is just nuts. When, God forbid, an airliner crashes due to pilot error, or a surgeon amputates the wrong limb, we don't dwell on the fact that a human being made a mistake. No, in fact we immediately begin to examine the systems in place that allowed the human error to be introduced in the first place. I don't mean to diminish the gravity of such real-life horrors by comparing them to a UI bug in a browser application, but there is something to be learned here in how such errors are handled.

So, let's start out with the simplest question: why ? Why would you want to be forced to worry about creating unit tests and other automated tests to catch simple bugs that compilers with formal type systems have been catching for many years ? Isn't it the entire purpose of computers and software to process huge amounts of information in an error-free way, over and over again, so that we don't have to ?

A JavaScript developer might reply: yes, but then you have to declare types for everything and do things like casting to satisfy the compiler.

Again, a simple question: are you writing completely undocumented code ? If not, then I can pretty much guarantee that you're specifying a type for that variable or parameter, and there's a very good chance that it's located in a documentation comment block right above the actual function. Go take a look at the Google Maps API, or documentation for the built-in browser DOM objects and functions. What you'll find is that almost all of the function parameters, variables, and properties are documented as using a specific type. A formal type system would a) make in-source type documentation unnecessary, and b) make the source code self-documenting. In addition, documentation skeletons can be automatically created directly from the source code (this is what we do here at Elevate Software) and IDE productivity features like code completion and refactoring can be used.

An easy thought experiment is this: what would you rather step in to maintain ? An application built in a language that had no formal type system, or a language that does ? Anyone that indicates the former is not being 100% honest. It's just a plain fact that its easier, relatively speaking, to read source code that has formal type information. This does not account for other aspects of the code, of course.

Finally, let me put forth the most important question when deciding to use a language like JavaScript with no formal type system: what exactly are you gaining by not having types ? The ability to define a function parameter that can accept any type of value ? Many modern languages with formal type systems have variant types for things like this, so that's not a plus, and removing all types just for this one capability amounts to "throwing the baby out with the bathwater". Apart from that, I'm hard-pressed to come up with a reason why one would want to not have types, other than it saves some additional keystrokes. I think that when you start selecting a language based upon the number of keystrokes required, you're using the wrong productivity metric. Typing is easy. Typing error-free code is not.

Case-Sensitivity

---

Ugh. There's not much need to say any more, other than this: case-sensitive languages are a forest-for-the-trees nightmare that work against the way that the human mind works. Especially a tired human mind that's been writing code for hours. They're a waste of time with no tangible benefits. Combining case-sensitivity with runtime compilation of source code, as JavaScript does (it's not alone in this regard), is a recipe for creating bugs that would normally be easily caught by the developer or the compiler.

Summary

---

I'll wrap things up with what I think is the most compelling argument against using only JavaScript for web applications. The web browser today has grown way beyond just a documentation presentation environment. It is no longer just being used for minimally-functional web sites. As evidenced by Elevate Web Builder, and products like it, you can build entire full-featured front-end applications that rival the functionality in desktop client applications. Application execution environments like operating systems and browsers should be language-agnostic for the simple reason that many different languages already exist, and have existed for many years prior to JavaScript, and there are millions of developers in the world that have many years of experience in these other languages. It makes much more sense, in time and money, to leverage these existing skills than to force every developer on the planet to code in the JavaScript language "just because". Furthermore, by excluding these existing language skills, you're excluding a whole host of IDEs, libraries, frameworks, etc. that could be written (or modified) to target this web execution environment. Windows languished in the development arena until developers like Anders Hejlsberg and the team at Borland started creating easy-to-use Pascal compilers and IDEs in the 90's that provided a better, more productive abstraction for the Windows API. Imagine what would have happened with Windows if you were forced to use C or C++ to write applications that target it ? Forcing a single language on a powerful application execution environment like the browser is just limiting its potential and stifling innovation. There are many different types of code, and many different types of developers that write that code. Some code should be low-level, while other code should be high-level. Forcing everyone into the same language, or trying to make one language be all things to everyone, simply does not make sense.

So, there you have it. Tell me what you think in the comments.

---

Tags: JavaScript, Elevate Web Builder

Permanent Link • 8 Comments

Previous Entries: 1-6 7-12 13-18 19-24 25-30 31-36 37-42 43-48 49-54 55-60 61-66 67-72 73-78 79-84