You are not logged in.
Pages: 1
Hi,
I am exploring mORMot features and trying to connect all things together and currently trying to build my version of UI auto generator for one record (I know there is included ribonUI, but it is not exactly what I need).
I get field info runtime with:
fRESTClient.Model.Table['testtable'].RecordProps.Fields.Items[FieldCnt].NameDisplay
but I would also like to include with model some custom default data for fields like visibility, default value, different caption,...:
const UItesttable:RawUTF8= '[{"visible":false, "default":3},{"visible":true, "default":0}]';
so I could access them like:
fRESTClient.Model.Table['testtable'].CustomData
or
fRESTClient.Model.CustomData
I guess I could make interface based service which would return this data for the model or write them in some TSQLRibbonTabParameters field, but maybe there is another more direct way for doing it ?
Thanks,
Bostjan
Offline
Thank you for your answer,
I tried TDocVariant instance, but I don't want it to be writen to DB, but to be part of TSQLModel.
Maybe if I clarify what I want to achieve: after I read through SAD, I made a decision to transform my old RAD based app to mORMot style DDD app and as a result I have more TSQLREST-s and also TSQLModel-s for each one.
My idea was that when I define Tables layout in model, I could also add default UI properties in JSON form which could be used for UI customisation.
For example if I have fields in TSQLRecord:
TSQLTable1 = class(TSQLRecord)
Name:RawUTF8;
LastName:RawUTF8;
Status:integer;
...
If I now generate user input form from TSQLRecord definition, I get all three fields on form, but Status is field that will be managed from code, so I don't want it on form.
In my current tests I define string constant just under TSQLRecord definitions, so that things are together:
const UIDefTable1:RawUTF8= '['
+'{"name":"Name","visible":true,"width":"40%"},'
+'{"name":"Status","visible":false}'
+']';
To add this data to TSQLModel I inherited from TSQLModel, added new field fCustomData and made new constructor:
constructor TSQLModelMy.Create(const Tables: array of TSQLRecordClass; const aRoot: RawUTF8; CustomData: RawUTF8);
begin
inherited Create(Tables, aRoot);
fCustomData:=CustomData;
end;
Now when I create model I add UI data like this:
function MyModelCreate:TSQLModelMy;
var TmpCustomData:variant;
begin
TmpCustomData:=_Arr([_Obj(['table','Table1','data',_JSON(UIDefTable1)])]);
TmpCustomData.Add(_Obj(['table','Table2','data',_JSON(UIDefTable2)]));
result := TSQLModelMy.Create([TSQLTable1, TSQLTable2],'root',VariantSaveJson(TmpCustomData));
end;
So when I am creating my universal data entry form I have default UI data available, regardless to which TSQLRest am I connecting it through:
tmpCustomData:=(fRESTClient.Model as TSQLModelMy).fCustomData;
It is usable, but I don't know if this correct/smartest way to accomplish this ?
Thanks,
Bostjan
Offline
mORMotUI is for direct ORM-to-UI mapping, not a DDD-like approach.
With DDD the tables should not be part of the UI.
You use a persistence service, on the server side, then the UI communicate with a presentation layer, using DTOs (not TSQLRecord).
The TSQLModel tables are expected to be for the ORM, only inside the persistence service.
Sometimes, I am more lazy, and don't define a persistence service, but export the ORM classes in the domain layer.
But I never transmit directly the TSQLRecord to the user - only some DTOs mapping the exact use cases of the UI.
Offline
Now I think I get it, thank you (have also re-read DTO part of SAD )
Since I am only at begining and still finding right concepts, I will for now use this approach, because it is quicker for prototyping, but later I will upgrade it so that my existing TDocVariant structure (or maybe whole default form definition) will be persisted in DB and UI form will request it through some dedicated service like any other data and then render it.
Thanks,
Bostjan
Offline
@ab what type of clients you write for DDD? Do you write desktop clients using Delphi with DDD approach?
Offline
Either Delphi clients, or PHP/JavaScript clients.
We also generate the documentation (and sometimes client source code) using mORMotWrappers.pas and mustache templates.
Using DTOs over REST/JSON makes it pretty easy to work with on client side.
Offline
Pages: 1