Unable to access RTTI for SmartMobileStudio

Question

Trying to use Smart's RTTI as defined in this post, I was not able to let RTTI be emitted to the HTML.

When I define:

type
   TBase = class
      published
         Field : Integer = 1;
   end;

 var base := new TBase;
 PrintPropertiesForType(base);

Then, there is no RTTI available for this class.

In index.html, I have:

var $RTTI = [];

Meaning that there is no RTTI emitted.

This occurs for whatever Project Options I have set. (in short, the RTTI compilation option does not make any difference)

I’m using SMS 2.0.1.741.

I’m stuck with implementing a native SMS client for mORMot..

Jon Lennart Aasenden · Accepted Answer · 2014-06-23T09:30:27.790

3

There seem to be a bug with this issue in the latest hotfix. I have reported the issue to the developer team and it should be fixed shortly. I noticed the exact same thing myself testing the RTTI methods on different versions of SMS.

An immediate solution is to just roll-back to version 2.0.0.723.

You can download that version here: http://smartmobilestudio.com/download/v2_0_0_723/

edited Jun 23 '14 at 09:30

answered Jun 22 '14 at 14:47

Jon Lennart Aasenden

3,920
2
29
44

1

Thanks for the feedback! I think I won't use rtti but generated wrappers. Using mustache for templates. :-) – Arnaud Bouchez Jun 23 '14 at 18:56

score 3 · Answer 2 · answered Jun 23 '14 at 18:36

3

I found out that it works in the main unit (TApplication) but not in other referenced units. So you can try that in the mean time

answered Jun 23 '14 at 18:36

André

8,920
1
24
24

Yes this was a very odd case. From viewpoint of the compiler TApplication is just a class, side by side with any other. But since it's the first class to generate an object, it's dependency mark is ensured above all else. Something tells me this is just a small bug, a one-liner or minor adjustment. Still very sad that it happened now, that I have the persistent framework up and running. – Jon Lennart Aasenden Jun 24 '14 at 11:19

score 0 · Answer 3 · answered Jun 24 '14 at 11:46

As an alternative to automatic persistence (since RTTI is not working in the latest hotfix and you have opted not to use RTTI for object mapping), it should be mentioned that Smart Pascal supports JavaScript structures. This will greatly simplify object storage. If you have ever used a Microsoft property-bag (com class) then this is more or less the same thing.

In JavaScript you would write:

var mbag = {};
mbag["test"] = {};
mbag["test"]["somevalue"] = 12;
mBag["text"] = "this is a string value";

Resulting in a memory structure like this:

Type
TMyBagContent = Record
  bcTest = Record
             bcSomeValue:Integer;
           end;
  bcText:String;
End;

In Delphi these kind of structures are implemented in SuperObject (I believe). RemObjects also have some support classes that mimic this. But thankfully Smart Pascal achieves this automatically by grace of targeting JavaScript directly.

So in Smart Pascal you would do the following to achieve the same results:

var mBag:Variant;
mBag:=TVariant.CreateObject;
mBag['test'] := TVariant.CreateObject;
mBag['test']['somevalue']:=12;
mBag['text']:='this is a string';

You can also save some time and use an assembly section:

var mBag:variant;
asm
  @mbag = {};
  @mbag["test"] = {};
  @mbag["test"]["somevalue"] = 12;
  @mbag["text"] = "this is a string value";
end;

Once you have populated your object's data, you then use JSON to serialize and make it portable:

var mObj: String;
asm
  @mObj = JSON.stringify(@mbag);
end;

Creating reader/writer class for storage is very easy. Naturally automatic RTTI property mapping is better (and that should be fixed shortly), but for frameworks that does it manually - which does have some advantages over full automation - there are plenty of options for creative programmers such as yourself.

There is also speed to consider, and using a JavaScript object as a lookup table is very, very fast compared to a for/next recursive algorithm. Especially for large and complex data structures.

Looking forward to testing your creation :)

We use this trick in other places, but we wanted to know the exact class layout. We expect not only to store value objects, but true classes with methods, inheritance, and some public or published properties, with distinct features. For instance, a *mORMot* server may either return a standard JSON object or array (with duplicated field names), or a much smaller [not-expanded format](http://blog.synopse.info/post/2010/07/02/JSON-format-of-a-RESTful-application), as a JSON array with field names at first row. To handle such kind of JSON content, we need to know how the classes are defined. — Arnaud Bouchez, Jun 24 '14 at 15:39
Is not `mBag['test']` exactly the same as `mBag.test` in SMS, as I suspect it is in JavaScript? In our cross-platform units, I use the `mBag.test` syntax, which also works with our [`TDocVariant` custom type](http://blog.synopse.info/post/2014/02/25/TDocVariant-custom-variant-type) in Delphi. — Arnaud Bouchez, Jun 27 '14 at 12:37

Unable to access RTTI for SmartMobileStudio

3 Answers3