Synopse

To content | To menu | To search

Tag - UserInterface

Entries feed

2015, Saturday November 21

Try to avoid RTTI (ab)use

There is a very trendy move, since a few years, to value so called "meta-programming".
In short, it is about the ability to treat programs as their data.
It is a very powerful paradigm in functional languages, and it was also introduced to OOP languages, even in SmallTalk a long time before this concept was trendy in Ruby, C# or Java.

In OOP compiled languages, reflection is used to achieve a similar behavior at run-time, mainly via RTTI (Run-Time Type Information).
Delphi supports RTTI since its version 1, as it was heavily used e.g. for all UI streaming.
In our framework, we rely on RTTI for its main features: ORMSOA and MVC - and even in some other parts, like Desktop UI generation.

But RTTI could easily be abused.
Here are some thoughts, started as a comment in a good old Mason's blog article about how RTTI performance may be a bottleneck.
My comment was to get rid of RTTI, and follow a SOLID implementation with explicit OOP code, like use of interface.

Continue reading...

2015, Tuesday June 16

Handling Cross-Platform Time Zones

One common problem when handling dates and times, is that time is shown and entered as local, whereas the computer should better use non-geographic information - especially on a Client-Server architecture, where both ends may not be on the same physical region.

A time zone is a region that observes a uniform standard time for legal, commercial, and social purposes.
Time zones tend to follow the boundaries of countries and their subdivisions because it is convenient for areas in close commercial or other communication to keep the same time.
Most of the time zones on land are offset from Coordinated Universal Time (UTC) by a whole number of hours, or minutes.
Even worse, some countries use daylight saving time for part of the year, typically by changing clocks by an hour, twice every year.

The main rule is that any date and time stored should be stored in UTC, or with an explicit Zone identifier (i.e. an explicit offset to the UTC value).
Our framework expects this behavior: every date/time value stored and handled by the ORM, SOA, or any other part of it, is expected to be UTC-encoded.
At presentation layer (e.g. the User Interface), conversion to/from local times should take place, so that the end-user is provided with friendly clock-wall compatible timing.

As you may guess, handling time zones is a complex task, which should be managed by the Operating System itself.
Since this cultural material is constantly involving, it is updated as part of the OS.

In practice, current local time could be converted from UTC from the current system-wide time zone. One of the only parameters you have to set when installing an Operating System is to pickup the keyboard layout... and the current time zone to be used. But in a client-server environment, you may have to manage several time zones on the server side: so you can't rely on this global setting.

One sad - but predictable - news is that there is no common way of encoding time zone information.
Under Windows, the registry contains a list of time zones, and the associated time bias data. Most POSIX systems (including Linux and Mac OSX) do rely on the IANA database, also called tzdata - you may have noticed that this particular package is often updated with your system.
Both zone identifiers do not map, so our framework needed something to be shared on all systems.

Continue reading...

2015, Sunday May 3

SOLID Design Principles

I've just updated the documentation part about the SOLID Design Principles.
The former blog article (almost 4 years old!) sounds like a bit deprecated now...
This is why I would extract here an updated version of this material.

Ensure you checked the corresponding part of the mORMot documentation, which is the updated reference, and probably the easiest to read - including links to all the other documentation.

The acronym SOLID is derived from the following OOP principles (quoted from the corresponding Wikipedia article):

  • Single responsibility principle: the notion that an object should have only a single responsibility;
  • Open/closed principle: the notion that "software entities ... should be open for extension, but closed for modification";
  • Liskov substitution principle: the notion that "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” - also named as "design by contract";
  • Interface segregation principle: the notion that "many client specific interfaces are better than one general purpose interface.";
  • Dependency inversion principle: the notion that one should "Depend upon Abstractions. Do not depend upon concretions.". Dependency injection is one method of following this principle, which is also called Inversion Of Control (aka IoC).

If you have some programming skills, those principles are general statements you may already found out by yourself. If you start doing serious object-oriented coding, those principles are best-practice guidelines you would gain following.

They certainly help to fight the three main code weaknesses:

  • Rigidity: Hard to change something because every change affects too many other parts of the system;
  • Fragility: When you make a change, unexpected parts of the system break;
  • Immobility: Hard to reuse in another application because it cannot be disentangled from the current application.

Continue reading...

2015, Monday April 20

Delphi is not a cross-compiler, but a set of cross-compilers

It is worth saying again.
I'm not speaking this time about performance issues, but about a common misunderstanding of what the latest version of Delphi offers.

Since Delphi "NextGen" compilers did break the memory model (introducing ARC), and also reducing low-level types (e.g. RawByteString/AnsiString), we can not say that Delphi is a single cross-compiler.
In practice, it has a set of cross-compilers.

Continue reading...

2014, Monday August 11

Cross-Platform mORMot Clients - Smart Mobile Studio

Current version of the main framework units target only Win32 and Win64 systems.

It allows to make easy self-hosting of mORMot servers for local business applications in any corporation, or pay cheap hosting in the Cloud, since mORMot CPU and RAM expectations are much lower than a regular IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need to create clients for platforms outside the Windows world, especially mobile devices.

A set of cross-platform client units is therefore available in the CrossPlatform sub-folder of the source code repository. It allows writing any client in modern object pascal language, for:

  • Any version of Delphi, on any platform (Mac OSX, or any mobile supported devices);
  • FreePascal Compiler 2.7.1;
  • Smart Mobile Studio 2.1, to create AJAX or mobile applications (via PhoneGap, if needed).

This series of articles will introduce you to mORMot's Cross-Platform abilities:

Any feedback is welcome in our forum, as usual!

Continue reading...

Cross-Platform mORMot Clients - Delphi / FreePascal

Current version of the main framework units target only Win32 and Win64 systems.

It allows to make easy self-hosting of mORMot servers for local business applications in any corporation, or pay cheap hosting in the Cloud, since mORMot CPU and RAM expectations are much lower than a regular IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need to create clients for platforms outside the Windows world, especially mobile devices.

A set of cross-platform client units is therefore available in the CrossPlatform sub-folder of the source code repository. It allows writing any client in modern object pascal language, for:

  • Any version of Delphi, on any platform (Mac OSX, or any mobile supported devices);
  • FreePascal Compiler 2.7.1;
  • Smart Mobile Studio 2.1, to create AJAX or mobile applications (via PhoneGap, if needed).

This series of articles will introduce you to mORMot's Cross-Platform abilities:

Any feedback is welcome in our forum, as usual!

Continue reading...

Cross-Platform mORMot Clients - Generating Code Wrappers

Current version of the main framework units target only Win32 and Win64 systems.

It allows to make easy self-hosting of mORMot servers for local business applications in any corporation, or pay cheap hosting in the Cloud, since mORMot CPU and RAM expectations are much lower than a regular IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need to create clients for platforms outside the Windows world, especially mobile devices.

A set of cross-platform client units is therefore available in the CrossPlatform sub-folder of the source code repository. It allows writing any client in modern object pascal language, for:

  • Any version of Delphi, on any platform (Mac OSX, or any mobile supported devices);
  • FreePascal Compiler 2.7.1;
  • Smart Mobile Studio 2.1, to create AJAX or mobile applications (via PhoneGap, if needed).

This series of articles will introduce you to mORMot's Cross-Platform abilities:

Any feedback is welcome in our forum, as usual!

Continue reading...

Cross-Platform mORMot Clients - Units and Platforms

Current version of the main framework units target only Win32 and Win64 systems.

It allows to make easy self-hosting of mORMot servers for local business applications in any corporation, or pay cheap hosting in the Cloud, since mORMot CPU and RAM expectations are much lower than a regular IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need to create clients for platforms outside the Windows world, especially mobile devices.

A set of cross-platform client units is therefore available in the CrossPlatform sub-folder of the source code repository. It allows writing any client in modern object pascal language, for:

  • Any version of Delphi, on any platform (Mac OSX, or any mobile supported devices);
  • FreePascal Compiler 2.7.1;
  • Smart Mobile Studio 2.1, to create AJAX or mobile applications (via PhoneGap, if needed).

This series of articles will introduce you to mORMot's Cross-Platform abilities:

Any feedback is welcome in our forum, as usual!

Continue reading...

2014, Monday April 28

Mustache Logic-less templates for Delphi - part 3

Mustache is a well-known logic-less template engine.
There is plenty of Open Source implementations around (including in JavaScript, which can be very convenient for AJAX applications on client side, for instance).
For mORMot, we created the first pure Delphi implementation of it, with a perfect integration with other bricks of the framework.

In last part of this series of blog articles, we will introduce the Mustache library included within mORMot source code tree.
You can download this documentation as one single pdf file.

Continue reading...

Mustache Logic-less templates for Delphi - part 2

Mustache is a well-known logic-less template engine.
There is plenty of Open Source implementations around (including in JavaScript, which can be very convenient for AJAX applications on client side, for instance).
For mORMot, we created the first pure Delphi implementation of it, with a perfect integration with other bricks of the framework.

In this second part of this series of blog articles, we will introduce the Mustache syntax.
You can download this documentation as one single pdf file.

Continue reading...

Mustache Logic-less templates for Delphi - part 1

Mustache is a well-known logic-less template engine.
There is plenty of Open Source implementations around (including in JavaScript, which can be very convenient for AJAX applications on client side, for instance).
For mORMot, we created the first pure Delphi implementation of it, with a perfect integration with other bricks of the framework.

In this first part of this series of blog articles, we will introduce the Mustache design.
You can download this documentation as one single pdf file.

Continue reading...

2013, Thursday September 19

FreePascal Lazarus and Android Native Controls

We all know that the first Delphi for Android was just released...

I just found out an amazing alternative, using native Android controls, and FPC/Lazarus as compiler and IDE.

It creates small .apk file: only 180 KB, from my tests!

It makes use of direct LCL access of Android native controls, so it is a great sample.

Continue reading...

2013, Thursday July 4

Let mORmot's applications be even more responsive

In mORmot applications, all the client communication is executed by default in the current thread, i.e. the main thread for a typical GUI application.
This may become an issue in some reported environments.

Since all communication is performed in blocking mode, if the remote request takes long to process (due to a bad/slow network, or a long server-side action), the application may become unresponsive, from the end-user experience.
Even Windows may be complaining about a "non responsive application", and may propose to kill the process, which is far away from an expected behavior.

In order to properly interacts with the user, a OnIdle property has been defined in TSQLRestClientURI, and will change the way communication is handled.
If a callback event is defined, all client communication will be processed in a background thread, and the current thread (probably the main UI thread) will wait for the request to be performed in the background, running the OnIdle callback in loop in the while.

Continue reading...

2013, Monday April 22

TDataSet... now I'm confused

You perhaps know that I'm not a big fan of the TDataSet / RAD DB approach for end-user applications.
They are easy to define, almost no code to write, and you are able to publish a working solution very fast.

But it is a nightmare to debug and maintain. I prefer the new DataBinding feature, or... of course... ORM!
In mORMot, we have some auto-generated screens, and in our roadmap, we forcast to use some auto-binding features, using a KISS by-convention MVC pattern.

For some users, we made a ORM / TDataSet conversion unit.
And we discovered that TDataSet has a weird, and very misleading definition of its AsString property, for Unicode versions of Delphi.

Continue reading...

2013, Thursday March 7

64 bit compatibility of mORMot units

I'm happy to announce that mORMot units are now compiling and working great in 64 bit mode, under Windows.
Need a Delphi XE2/XE3 compiler, of course!

ORM and services are now available in Win64, on both client and server sides.
Low-level x64 assembler stubs have been created, tested and optimized.
UI part is also available... that is grid display, reporting (with pdf export and display anti-aliasing), ribbon auto-generation, SynTaskDialog, i18n... the main SynFile demo just works great!

Overall impression is very positive, and speed is comparable to 32 bit version (only 10-15% slower).

Speed decrease seems to be mostly due to doubled pointer size, and some less optimized part of the official Delphi RTL.
But since mORMot core uses its own set of functions (e.g. for JSON serialization, RTTI support or interface calls or stubbing), we were able to release the whole 64 bit power of your hardware.

Delphi 64 bit compiler sounds stable and efficient. Even when working at low level, with assembler stubs.
Generated code sounds more optimized than the one emitted by FreePascalCompiler - and RTL is very close to 32 bit mode.
Overall, VCL conversion worked as easily than a simple re-build.
Embarcadero's people did a great job for VCL Win64 support, here!

Continue reading...

2012, Monday December 31

Enhance existing projects with mORMot

Even if mORMot will be more easily used in a project designed from scratch, it fits very well the purpose of evolving any existing Delphi project, or even creating the server side part of an AJAX application. 

One benefit of such a framework is to facilitate the transition from a Client-Server architecture to a N-Tier layered pattern.

Continue reading...

2012, Thursday September 6

Roadmap: interface-based callbacks for Event Collaboration

On the mORMot roadmap, we added a new upcoming feature, to implement one-way callbacks from the server.
That is, add transparent "push" mode to our Service Oriented Architecture framework.

Aim is to implement notification events triggered from the server side, very easily from Delphi code, even over a single HTTP connection - for instance, WCF does not allow this: it will need a dual binding, so will need to open a firewall port and such.

It will be the ground of an Event Collaboration stack included within mORMot, in a KISS way.
Event Collaboration is really a very interesting pattern, and even if not all your application domain should be written using it, some part may definitively benefit from it.
The publish / subscribe pattern provides greater network scalability and a more dynamic SOA implementation: for instance, you can add listeners to your main system events (even third-party developed), without touching your main server.
Or it could be the root of the Event Sourcing part of your business domain: since callbacks can also be executed on the server side (without communication), they can be used to easily add nice features like: complete rebuild, data consolidation (and CQRS), temporal query, event replay, logging, audit, backup, replication.

Continue reading...

2012, Monday September 3

Client-Server allowed back to XE3 pro

The attempt to restrict the XE3 professional license did evolve into an amazing discussion in Embarcadero forums, and Delphi-related blogs.

David I announced the (reverted) EULA for Delphi Pro. Remote database access is again possible, with terms similar to Delphi Xe2.
You can check the Software License and Support Terms (EULA) for RAD Studio XE3 products.

This is good news, but also the opportunity to check the definitive terms.

In short, with the XE3 pro license, you have a deployment restrictive clause:

  • You can use DBExpress components and units only locally;
  • You can use DataSnap features only locally (it means that you can prototype using DataSnap, but are not allowed to deploy or redistribute DataSnap).

If you want to use those two features on Client-Server, you would need to buy a Client/Server Pack license:

If licensee has purchased a Client/Server Pack, the Licensee of RAD Studio, Delphi, or C++Builder XE3 Professional Edition (“Product”) may deploy that portion of the Product identified as "dbExpress" and dbExpress enterprise database drivers, in executable form only, to enable client server database access. Embarcadero may deliver the Product identified as “Enterprise,” however Licensee is licensed to use only the “Professional” edition features plus "dbExpress" and the Enterprise dbExpress database drivers in a client/server configuration. Licensee may evaluate the n-Tier DataSnap functionality included in the Enterprise Product delivered, but may not deploy or redistribute DataSnap.

This is now a real opportunity for our Open Source mORMot framework.
With a XE3 pro license, and even with a XE3 starter license, you are able, via our free units and classes:

That is, everything you need to build from a small Client-Server or stand-alone application up to the most scalable Domain-Driven design.

Nice, isn't it?

2012, Thursday August 30

WinRT support for XE3

Apart the sad and concerning license change issue (which has been confirmed by David I. himself), XE3 has some features, in order to support Windows 8 new 'tile-based' interface (formerly known as "Metro").

Windows Runtime, or WinRT (not to be confused with Windows RT, which is a tablet manufacturer only version of Windows 8) is a cross-platform application architecture on the Windows 8 operating system.
WinRT supports development in C++/CX (Component Extensions, a language based on C++) and the managed languages C# and VB.NET, as well as JavaScript.
WinRT applications natively support both the x86 and ARM architectures, and also run inside a sandboxed environment to allow for greater security and stability.
WinRT will also be part of the upcoming Windows Phone 8 operating systems.
(source: Wikipedia)

It has been clearly stated that only Microsoft compilers and runtime libraries (RTL) will be able to have full access to the low-level API needed to create a decent RTL.
This has been done for security reasons, but it won't allow third-party JIT or compilers to work as expected. Only Microsoft's C++ and C# compilers / virtual machines have access to the needed API. Even if you do not have a JIT in your language (Delphi is compiled and do not have any virtual machine), you would need to access to some low-level API calls e.g. to mark some memory block as executable (e.g. for virtual methods stubbing).

So Delphi is not able to have native support of WinRT, due to this limitation.

This is a known fact, but let us tell about "Windows 8 sideloading" feature, available with XE3.
In short, even if you do not have 100% WinRT application, XE3 "Metropolis" (sic) styled Desktop applications have some potential to behave like native UI applications, even if not being native.

Continue reading...

2012, Monday May 28

Is marketing the new native?

In a very nice (like always) blog post, trolling comments were dispatched about the "native" concept:

From the technical point of view, both assertions are false.

The article was subtitled: "Say a Lie Often Enough and You’ll Start Believing it Yourself".
At least, it is a trolling subject.

It remembered me about some of my past studies, i.e. five years of university studies in Medieval Theology in Italy and France (yes, I know, this is strange background for a Delphi programmer):

"Stat Roma pristina nomine, nomina nuda tenemus"

Our modern world is not thinking any more, it is sinking into nominalism, whereas IMHO the scientific approach is more compatible with a realistic approach of universals.

Today, marketing is everything.
Is it a necessary evil?

Continue reading...

- page 1 of 2