Home > Delphi, JavaScript, nodeJS, Object Pascal, OP4JS, Smart Mobile Studio > Next update, a closer look behind the scenes

Next update, a closer look behind the scenes

With the next update right around the corner, what can you expect to find? Well, I am going to give you some insight and preview into the update right here. For some of you it will be like Christmas and new-years eve all rolled up into one. Especially custom control writers who need fine-grained accuracy for their HTML5 components. So let’s visit the secret lab of object pascal fundamentalists and have a peek 🙂

The secret lab that shall not be named

The secret lab that shall not be named

Functional handles

If you know your way around the VJL (visual JavaScript library) then you will notice a few minor changes here and there, especially that we now have more handle types. So far all browser specific types have been references by the THandle type, which is of type variant and thus capable of abstracting everything.

Starting with this update we begin the journey to a fully typed RTL; This means that the ultimate goal is to get rid of THandle all together and replace it with a typed reference to the HTML5 element itself. So instead of a “Handle:THandle” property in TW3EditBox you would actually get “Handle:JInputElement” which gives you direct access to the element from your pascal code.

But we are not there yet. So for now we have begun separating different handle types, which means that user-controls are no longer packing THandle as their handle-property, but rather TControlHandle.

Why did we do this? Well it’s simple. By separating handles into distinct types we can attach helper classes to them, simplifying how you work with and access handles. This allows us to replace one handle type at a time (without breaking backwards compatibility) and do so in a timely manner.

TControlHandle introduces the following helper methods:

  TControlHandleHelper = helper for TControlHandle
    function  Valid:Boolean;
    function  Ready:Boolean;
    function  Parent:TControlHandle;
    function  Root:TControlHandle;
    procedure ReadyExecute(OnReady:TProcedureRef);
    procedure ReadyExecuteAnimFrame(OnRead:TProcedureRef);
    function  Equals(const Source:TControlHandle):Boolean;
  end;

The ReadyExecute() method requires special attention. In short, whenever you create a visual control it can take a few milliseconds before it actually appears. This means that your code both inside the control and outside stand the risk of accessing a control which is not yet attached to the DOM (document object model).

ReadyExecute solves this by attaching a testing routine to this job, namely to continuously check if the handle is ready for use (read: injected into the DOM and is thus capable of being displayed). When the control is ready it will execute the anonymous procedure you provided.

This allows us to do things like this inside our constructor:

Constructor TMyListControl.InitializeControl;
Begin
  inherited;
  Handle.ReadyExecute( Procedure ()
    begin
      BrowserAPI.RequestAnimationFrame( procedure ()
      Begin
        ReSize;
        LayoutChildren;
      end;
    end);
end;

What the above code does, is to initialize the control as usual, but instruct the system to call-back immediately when the handle is inserted into the DOM. At which point we ask the browser to redraw AFTER we have resized and done layout of child elements.

This results in your control smoothly appearing inside it’s container. You don’t need to issue a resize or “nudge” to force a the layout manually, like some controls require right now. All of that is gone and we will revamp our entire control library with new and updated code.

We also have a method which includes the RequestAnimationFrame call automatically, cleverly named ReadyExecuteAnimFrame(). This is a handy method to make use of:

Constructor TMyListControl.InitializeControl;
Begin
  inherited;
  Handle.ReadyExecuteAnimFrame( Procedure ()
    begin
        ReSize;
        LayoutChildren;
    end);
end;

The Root Method is a great way to check if a control is actually attached to the DOM. If it’s attached to the DOM then the root element will be HTMLBodyElement. So this is a handy way of testing for this particular state.

Valid is as the name implies a method for validating that a TControlHandle is, well.. Valid! A valid reference means that it’s assigned a value and that it’s not null. Which would be the case for an invalid reference. It also makes your code look more human:

if Handle.Valid then
Begin
  if not Parent.Handle.Equals(w3form1.handle) then
  Raise Exception.Create("This control cannot be dropped directly on a form");
end;

The parent method will return the immediate parent, it will not traverse the DOM to locate the first owner, but rather just whatever element you have created an element under (form, panel, custom control).

The Ready method does the exact same thing as ReadyExecute, except that it simply performs the test. It doesnt create a time object which keeps checking for a state change, nor does it call back. This is an excellent way to find out of the current control is attached and ready to use.

Design considerations

I have written by font measuring before. I realize that to some people this may not seem very important, but you have to remember that HTML and JavaScript doesn’t have any functions for measuring font metrics (!). Thats right, these things doesn’t exist in the browser. So being able to measure the width and height of a piece of text, taking font-face and style into consideration — is no small feat. In fact you can’t even enumerate what fonts the browser supports, which is another aspect of accuracy we now provide as standard.

Starting with the next update, TW3MovableControl (base class) introduces these methods:

    function getFontInfo:TW3FontInfo;overload;
    function MeasureText(aContent:String):TW3TextMetric;overload;
    function MeasureTextFixed(aContent:String):TW3TextMetric;overload;

    class function MeasureTextSize(const aHandle:THandle;
          const aContent:String):TW3TextMetric;

    class function MeasureTextSizeF(const aHandle:THandle;
          const aWidth:Integer;const aContent:String):TW3TextMetric;

    class function getFontInfo(const aHandle:THandle):TW3FontInfo;overload;

Attributes

This is a slightly more complex feature which may not seem immediately valuable to some, but believe me, a lot of software could not be written without them.

A couple of years ago browsers began to support “user defined attributes”. In short it means that you can now attach your own attributes to HTML elements. The rules are simple: always pre-fix your attributes with “data-” and the browser wont ignore them. If you don’t follow that rule the browser just ignores them (or deletes them).

Let me explain just how important these are:
This update introduces the ability to apply effects with a single call to any custom-control. You can also chain effects together and they will execute in-turn, one after another. Cool right?

Absolutely, but how do you think this was done? The problem is this: Effect objects are created when you call them, but there has to be a list or queue type of mechanism which prevents them from starting all at once. There must be some way of telling effects waiting in escrow – to wait until the control is ready for more effects.
Since effect objects cannot be kept track of easily, not without an expensive list of stack table – the best way to inform the waiting effects that the object is busy, is to write the value to the element itself!

And this is exactly how we solves having multiple effects waiting their turn. When an effect is active, it writes a busy-flag to the HTML element. The other effects keep checking this flag and only execute when the object is not-busy.

This would not be possible without attribute access. Well, at least not without a rather expensive lookup table and cleanup procedure.

Other uses of attributes

Loads. You can now “tag” your own elements with whatever values you like. Perhaps you want to link a visual control to some data? Well, then you would define table and field as attributes. And when the data is ready, query the DOM through a selector to return those elements marked with your “tags”‘s. Voila you can now freely target and populate visual controls without even registering them. A sort of weak-binding type solution.

Visual effects

I mentioned above that the QTX effects library has been built into the RTL. And that is true. This makes it child’s play to make your UI designs become more responsive and alive by responding with effects to touches and callbacks. But don’t over-do it! To much can render your application useless, so use with care!

All TW3CustomControl decendants now supports the following effects:

  1. fxFadeOut
  2. fxFadeIn
  3. fxWarpOut
  4. fxWarpIn
  5. fxZoomIn
  6. fxZoomOut
  7. fxScaleTo
  8. fxMoveTo
  9. fxMoveBy
  10. fxMoveUp
  11. fxMoveDown
  12. fxSizeTo
  13. fxScaleDown
  14. fxScaleUp

These effects can be daisy-chained to execute after each other, like so:

  w3Button1
    .fxFadeIn(0.2)
    .FxMoveDown(1.2)
    .fxFadeOut(0.3);

Legacy

For all your FreePascal and Delphi coders we have a little treat, namely some classes which will simplify your HTML5 graphics programming life. Like most Delphi programmers you are probably used to good old TCanvas and TBitmap to do your work. Perhaps you want to port over some older Delphi code and cringe at using HTML5’s canvas to do the work?

Well we have re-implemented both TBitmap, TCanvas, TBrush and TPen for you. So go straight ahead and do that port, also be amazed at the wonderful speed enhancement HTML5 offers over native Delphi.

Streams, buffers and memory

I have covered these features before, you can read more about these here:

Dataset support

Yes. Finally. I know you guys have been asking about this since the beginning. Well starting with the next update we ship TW3CustomDataset and TW3Dataset, which is an in-memory dataset solution.

NodeJS builder

NodeJS builder will make the current architecture make more sense

It does not connect to anything and is more like TClientDataset in Delphi, but you can use it to cache records you want to send via DataSnap, or via RemObjects, and naturally it’s a perfect match for nodeJS services. It will all make more sense when we ship the nodeJS service designer (ops! Perhaps I should not have mentioned that part).

You will find that in system.dataset, which means you can also reference it from your nodeJS projects. Communication between server and client will be 100% compatible since dataset can be deployed on both sides.

Later I will introduce binary records (everything is now JSon) and in-memory storage which will be super-fast and super efficient. So we havent even begun scratching the surface of databases under HTML5!

And much, much more

These were just some of the features I am adding to SMS this time. We are a team of 4 developers so there will be plenty of bug-fixes and other features, both for the IDE, the compiler and the RTL.

I cant wait to get to work on the next update! There are so much cool stuff in the pipeline I hardly know where to begin!

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: