{
"reviews": [
{
"user_id": 1,
"user_name": "u1",
"product_id": 1,
"product_name": "p1",
"content": "c1",
"rating": 1,
"stars": "★☆☆☆☆",
"approved": true,
"is_new": true
},
{
"user_id": 1,
"user_name": "u1",
"product_id": 2,
"product_name": "p2",
"content": "c2",
"rating": 4,
"stars": "★★★★☆",
"approved": true,
"is_new": false
},
{
"user_id": 2,
"user_name": "u2",
"product_id": 1,
"product_name": "p1",
"content": "c3",
"rating": 3,
"stars": "★★★☆☆",
"approved": false,
"is_new": false
}
],
}
However, that turns out to be difficult to be used as API response as well based on the service consumer feedback, so I change it to:
{
"result": {
"1": {
"product_name": "p1",
"reviews": {
"1": {
"user_name": "u1",
"content": "c1",
"rating": 1,
"stars": "★☆☆☆☆",
"approved": true,
"is_new": true
},
"2": {
"user_name": "u2",
"content": "c2",
"rating": 3,
"stars": "★★★☆☆",
"approved": false,
"is_new": false
}
}
},
"2": {
"product_name": "p2",
"reviews": {
"1": {
"user_name": "u1",
"content": "c3",
"rating": 4,
"stars": "★★★★☆",
"approved": true,
"is_new": false
}
}
}
}
}
Essentially turning the ids into object key instead of part of an object inside an array. However, not I have problem implementing the front end because I can't (or don't know how to) iterate the objects like arrays. Is it possible to do that or is there any alternative way?
]]> Ixx1 = interface
['{{GUID}}']
end;
Ixx2 = interface
['{{GUID}}']
end;
and the output e.g.
Ixx1 = interface
['{46DBA8EB-E9E3-4811-A2AF-B07895981A85}']
end;
Ixx2 = interface
['{C9CB4B0A-EC28-49E8-9CC6-B549B3CCB354}']
end;
What is be the best way to do this?
i.e. I think as a last resort, I could misuse the Internationalization feature..
But if our server is compiled, those dependencies become in fact simply Delphi units.
The Delphi compiler is your package manager...
And I didn't describe that 'perfect world' well. Simply put it, in a perfect world, we'll have a dependency/package manager like Maven for Java (http://stackoverflow.com/a/3589974), and all Delphi libs are comply with it... Well, just a dream
]]>Each unit, in fact, is most of the time stand-alone, or has clear dependencies.
For instance, you would never link any UI unit when you write a mORMot server.
Thanks to Delphi smart-linking (i.e. it puts only what is used in the exe), having huge units is not a problem.
On the contrary, it tends to make compilation faster, and use less resources (when compared to a lot of small units).
For a framework, I think it does make sense to have huge general-purpose units (as the VCL/RTL do).
Well, in a perfect world, we'll have small, standalone but interface-able libraries, like how node.js mange its modules.
In a perfect world, we'll have:
1 - SynpseFundamentals, which includes SynCommons.pas, Synnopse.inc, etc.
2 - SynpseSpiderMonkeyWrapper...
3 - SynpseMongoDbClient...
4 - SynpseHttpClient...
5 - SynpseHttpServer...
6 - SynpseORM...
And so on...
So it's not only good for marketing, but also good for managing the dependency, good for people who only want to use parts of the framework.
We all know the JVCL framework, which was heading to another direction over ten years ago. I saw people want to use some of it's components, but were afraid of it's huge size.
... yes, but all will use SynCommons.pas, SynLZ.pas and Synopse.inc...
All is available within mORMot source code repository, but the units are decoupled.
Several web sites may help, but only for marketing purpose, IMHO.
All is available within mORMot source code repository, but the units are decoupled.
Several web sites may help, but only for marketing purpose, IMHO.
@edwinsn
Our SynMustache is already listed to the official page http://mustache.github.io/
Great! And I wish start to love github - although on my computer I only do git-clones, github's web interface is really helpful for people checking out the source without using any version controlling systems.
]]>@edwinsn
Our SynMustache is already listed to the official page http://mustache.github.io/
This is the forum thread for a series of blog articles.
See http://blog.synopse.info/post/2014/04/2 … phi-part-1