UI 3.0

... and is done. Gyro applications have a new look and increased usability.

The search bar is now on top of the category tabs, more user preferences, the forms are faster now, and they restore before showing on the screen (avoiding the annoying resize after the form is shown). There are tons of new things, most of them regarding usability(see previous post).

UI models

I've seen some screenshots of enterprise applications, and I've decided that the Gyro application search/results-based UI is not enough for some situations.

I've added a new property for every entity (you can actually combine models for different entities):


You can choose from search/results (standard model) or master view/detail, minimizing the number of open forms for the user (and actually increasing the productivity for the end-user).




The screenshots are from an actual application, so I've blurred some of the data.

I've modified the home screen (yes, again):


And as usual, bug-fixes, most of them regarding the MongoDB applications.

Repli-Gears and bugfixes

I had a few days off, just enough to make some new test units for GyroGears. I've noticed that Gtk+ 3.4 is windows-ready, and I'm waiting for the official release. Concept Client already works on Gtk3, but I'm using unofficial windows builds, that have some problems. The biggest problem is with GtkSheet (from gtk+extra), a widget that is not available on Gtk 3. To avoid this, I've modified the RTreeView control, to act in some situations more like a grid.

This function was already available, but it wasn't very user friendly. The standard behavior is this: the user presses enter or clicks on the column he wishes to edit, types all the text and presses enter. The cursor doesn't move automatically on the next column. To avoid that, I've modified this behavior, and now, beside the enter key, the user can press the tab key, and the cursor moves automatically and remains in edit mode (Avoiding two key events: press the right arrow key and the enter key). It doesn't seem much, but when dealing with large amounts of data, it can make a difference for the user.

The new feature is record duplication.


This allows the end-user to duplicate a record. This will duplicate all the non-exclusive relations (many-to-*), for the new created object.

For the exclusive relations (one-to-*) you can decide in GyroGears if is "duplicable" or not.

If this is checked, the exclusive relation will be duplicated. If the related entity has unique fields, this will bypass the standard validation (this feature is not stupid-proof), and GyroGears will issue a warning.

I've switched the default GyroGears web control to RWebKit (dropping RHTML). This is a preparation for Gtk3 (I'm not sure if they will suport GtkHtml anymore). However, I've emulate the old RHTML control using RWebKit, not to affect the existing software (just Concept Client will use the new control).


I've used some nice CSS3 effects like shadow.

I've modified the multiple delete and archive engine. Now, if an error is encountered when deleting/archiving, the entire operation is undone (rolled back). I've also speed up these operations that take significantly less time when dealing with large amounts of data.

Cranberry tea with end-users

About a week ago I sat with 4 of my end-users. The youngest has about 27 years and the oldest about 55, 2 men and 2 women. I watched how they use a Gyro-generated application, and notice they reflexes. And then, I've noticed how their eyes were looking for information on the screen. They had never used a Gyro application before. After watching them, I came out with a few and simple features that increase the overall usability.

First of all, the notebook tabs. The users sometimes find it hard to look for the tabs on top of the screen. He or she is maybe used with paper notebooks, that are indexed on the left or right side. So, I've added some new options there.


Now you can organize the categories into left- or right- aligned tabs, depending on your users.


I've noticed that some times the users are overwhelmed by the amount of information required for them to fill it in, so, I've added the expanders (by default, an expander containing a mandatory field is opened).


As you can see, every subcategory can now be expanded/collapsed. Simple, but very useful for the end-user.

Usability, usability, usability !


Some bug-fixes, as usual, mostly regarding the UI and one with some unoptimized queries.

For old folks, that use dBase, I've added support for dbf files. Not really needed these days, but useful when interacting with old applications.

Language candy and Mongo

Finished the implementation for MongoDB. Most Gyro features working with SQL are now working with MongoDB. Just faster. As a down side: no transactions, and different "cancel" behavior. For example, if we have an entity called "Post" and another one called "Comment" (related, one-to-any), on SQL, if the user modifies a comment and saves it, and the presses cancel on the parent object (Post), this causes a rollback for all the modified data in that transaction.

On NoSQL, same scenario, if a comment is modified, and then the parent is not saved, this will cause commit for the comment and rollback (emulated) for the post. Is not really a drawback, just a thing to keep in mind when designing your application.

I've introduced a new language core element: static key specification:
Something you used to do like this:

var arr0=new [];
arr0["key"]="some value";
arr0[3]="some index value";

// you can now do it like this:
var arr=["key" => "some value", 3 => "some index value"];
// or
// => and : are synonyms
var arr2=["key" : "some value", 3 : "some index value"];


Also, a new function (defined in standard.lang.serialize and Serializable.con): ToArray(object). This converts an object into an array, very useful for debugging, because you can now say:

echo ToArray(this);

GyroGears relations on MongoDB are now available using a mixed redundant relation/schema design. The related model is needed for maintaining Gyro-generated framework API compatibility with SQL design. The schema design is used for optimizing relation search. Yes, it is a little redundant, but it works very fast.

While implementing MongoDB driver, I've managed to identify a series of unreported bugs in GyroGears: revisions didn't work as expected for relations, some minor bugs in web search when searching by owner.

A new feature in GyroGears: View option for objects. All objects where opened in edit mode, this causing a locking of the record. Some times, the user just wanted to review the data, so the "View" menu option (when right clicking a record) opens a record in read only mode without locking.

I've made some preventive bug-fixing in Concept Server (automated tests), and MongoDB and MySQL driver.

MongoDB is the first NoSQL supported database server

It's been a while since I've started pondering about the benefits of NoSQL database engines. After implementing more than 100 GyroGears solutions, I've started to notice some patterns suitable for no-sql engines.



I've finished all the preliminary tests for the MongoDB Concept driver, the auto-documentation is available here:

http://www.radgs.com/docs/help/MongoConnection.html
http://www.radgs.com/docs/help/MongoDataSet.html
http://www.radgs.com/docs/help/MongoCursor.html

And static functions here:
http://www.radgs.com/docs/help/standard.db.mongo.html

I've modified GyroGears to use this driver, though is not yet fully functional. The relations, files and multimedia types are not working properly yet.

Here is a screenshot of a GyroGears application running on MongoDB.



You can see that you can use sql-style wildcard (for backwards compatibility). You can regenerate your old SQL-based Gyro application for MongoDB without the end-user ever noticing.

Here is a shot of how the Mongo data looks like:


I've used MongoVUE, no Concept Application Server tool yet available for managing Mongo data.

GyroGears is getting cooler

Lots of new stuff available in GyroGears.
Let's see:


New formulas, a lot easier to use:

QueryDB("select sum(`product`.`price`) from product inner join `rel_order_products` on `id_product`=`id` where `id_order`=$id") * (100-Discount)/100 + Shipping_fees

As you can see, it is a combined formula, using both a query and Concept computations (in red).

New member validation expression (PERL-compatible expressions).
[A-Za-z0-9_\.\-]+\@[A-Za-z0-9_\.\-]+\.[A-Za-z0-9_\.\-]+
it validates an email address.


User defined functions can be now defined directly from GyroGears, without any need to open CIDE (see the button).

A new source editor, with code completion, automatic indenting, search functions and zoom. This editor will replace the old editor in Concept IDE.

A new data type: reference.
A reference relation is a virtual relation to a member in a related entity. Then, that object will be mapped in the referring object. Look at the next screenshot to see exactly how it works.


For example, a blog post has comments and images. Each image has its own comments. So, you can add a reference to Image/Comments in the Post entity. This way, the end-user can see all the comments for all the images for a specific post.

A lots of bug were fixes in various areas (especially in reporting and web sources).

GyroGears CSV, face recognition and new plug-ins

I've fixed a bug that caused some crashes in the concept server when running cached applications having the same name on different virtual hosts.
Also, I had a little time to play, and I've added very simple functions for detecting a face (using OpenCV).
It works great, and it uses standard png or jpg pictures. It has a very simple interface, available here on http://www.radgs.com/docs/help/standard.lib.face.html.

Also, I've re-write the plug-in engine to support properties:


I've added new plug-ins:


... and a email sender plug-in:

A new property is available here "Hide title in forms", and when this is checked, the member title will be hidden.

A new flag available for entities:

This will show in the master view the representative member in the parent entity. When parent level is 2, will show the parent's parent, and so on. This proved to be very useful for me.

CSV import/export available for every entity (see the highlighted button and the one bellow):

It will automatically detect the separator (comma, semicolon or tab). Header is mandatory.

Some optimizations on 64 bit platforms and some web bugs were fixed.

These days I will implement face log-in for GyroGears applications, that will allow an user to log-in using a webcam. When the system recognizes the user, it could not ask for user and password. However, a picture of the user can be used ...

GyroGears plugins

About a year ago I've started thinking about a plug-in system for GyroGears. GyroGears is closed source (at least for now), and I was pondering a system for combining both open source and closed source plug-in into GyroGears.

Look at this:

As you can see, a Google map is displayed into this form, linked to the "Coordinates" and "Description" members.

The fun is in implementing this:


It's a member defined as a "plug-in". I've created two plug-ins, one for Google Maps and another one for the WebKit engine.

For Google Maps, you just enter your API key, and coordinates/title/description members and is done.


It should be very easy to write any plug-in for GyroGears, anything you could think at.

Thanks to the new GyroGears developers (that quadrupled in the last few months), I've optimized some things.

The first problem was the Concept Compiler (accel), that had an exponential growth in compile time when dealing with large applications. I've inserted some hashing tables in order to retrieve the data faster, and now it seems to work as expected.

Another reported problem was with the web-generated scripts. In some cases were slow due to a bug in Gyro-generated framework that caused all the data to be transferred from the server. Now it has decent times.

I've optimized the http:// interface, that looks a lot cooler now. However it still lacks in functionality when compared to the concept:// interface.

The Sablotron XSLT library was dropped (is still supported by the Concept Framework), and replaced by libxslt, that has a lot more features, and it seems to be a little faster and included in most Linux distributions (not necessarily needing manual compilation).

A few new templates were added to GyroGears (webpage and web catalog).

Below are some screenshots with the new http templates.

Ultraportability 3.0

It's been a while since I've started to analyze Android and iOS. I've thought of making a high level wrapper to maintain only one code tree for both platforms ... and I came over MoSync that does exactly this. And it does it in C/C++ !
I've spent the last few nights rewriting the core communication objects in order to be compatible with ARM devices in single thread mode over asynchronous socket. And now, it works, and it works better than I've expected. So, I've decided that for Concept 3.0 I will have the same UI for every platform.

Here are some pretty pictures:












A debug console ... for really bad days.



Here you can see the same application (using exactly the same code) running on desktop (the whole code is on background).




I've ported even the dialogs.

I hope that in early December to have a fully functional iOS and Android client.