mORMot Open Source

sandeep_c24

Member

Registered: 2010-10-23

Posts: 2

JSON Server and Client

Hi

Is it possible to use your framework without using SQLite and just use the framework to write server and client side to communicate using JSON.

I am looking at using your framework along with InstantObjects.

Regards

Sandeep

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: JSON Server and Client

The ORM is mapped in both side of the framework.
So it's not possible to use another ORM than the one integrated in the client/server current implementation.

But you can take a look at our JSON-related functions, located in SynCommons and SQLite3Commons units, and our client/server functions, in SynCrtSock unit. It could help you creating easily such a JSON client/server communication for InstantObjects. But you'll need the RTTI functions for SQlite3Commons to guess the properties names and such...

Another database engine than SQLite can be used with the framework. I'm currently looking at Zeos in order to provide persistence across multiple database engines.

InstantObjects is not a database engine, it is an ORM, therefore, it can't be used as is with our framework.

Thanks for your interrest, in all cases.

sandeep_c24

Member

Registered: 2010-10-23

Posts: 2

Re: JSON Server and Client

I don't know much about JSON, so I might me talking rubbish, but if you framework can be used to do server and client calls and JSON stuff can be done using DelphiXE I think what I am after can be achieved easily.

Your thoughts

Regards

Sandeep

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: JSON Server and Client

The problem has nothing to do with JSON.

The fact is that our framework is ORM-based, and both client and server side rely on this ORM mapping.
Using another ORM mapper, like Instant Object, won't work without a deep rewrite of our framework, I'm afraid.

The Instant Object ORM seems more complex (because with diverse architecture/features) than ours.
Our is not better, it's only more close to the Delphi RTTI.

For the JSON layer, and also for the Client/Server layer, we don't rely on the Delphi XE features. We coded our own RESTful server, because we needed it to compile with Delphi 6/7/2007 projects (and Delphi 2009/2010/XE also), and we didn't want to use any RAD feature of Delphi.
IMHO RAD is good for prototyping and for describing simple windows, but the more complex your architecture is, the better pure object code with an ORM is.
It appeared to me, but it's only a personal opinion, that browsing objects in the code editor was more productive than clicking on components on modules.

It's the good point of Delphi to allow both style of coding: full RAD, or more code-oriented.