v1.18.4952 is the best?

uniho · 2021-12-09 08:38:19

Thanks for your great library.
I launched new project using mORMot v1.18.4952.
Do you think v1.18.4952 is the best for it? I am interesting in mORMot2.

edwinsn · 2021-12-09 08:56:19

I think you should use the latest source from the github repository?

https://github.com/synopse/mORMot/commits/master

PS, interesting project with well-written documents

Last edited by edwinsn (2021-12-09 08:56:58)

sakura · 2021-12-09 10:57:26

And yes, if you start new projects, go straight to mORMot2, most things are working, and very likely, before you launch new projects with it, it'll have everything you would find in version 1.
We started our new project(s) on mORMot2 and they are coming along wonderfully. (Running Delphi, Windows only)

edwinsn · 2021-12-09 15:10:19

I agree with sakura and thanks him for sharing his experiences.

@sakura, speaking of similarity of mORMot1 and mORMot2, how does it feel?
Over the years I've built up a bunch of utility functions and classes based on mORMot1, I wonder in the future if I will be able to easily port them to mORMot 2.

sakura · 2021-12-09 16:09:24

@edwin - I would think it should be possible, depending on the size, it might take a while, but it will be worth it.

However, I have used mORMot1 in my old company, at my current place I've started right out with mORMot2 and have to recreate things from scratch. It is different, but similar that it is, usually, easy enough to adapt my knowledge. We use Delphi, not FPC, because of the [Attributes] which gives me an amazing power to extend mORMot easily even further - and I love it :-) Many things in our new app will be working by simply marking things using attributes, up to replacing whole classes in services with more refined versions.

edwinsn · 2021-12-09 17:30:17

sakura wrote:

the [Attributes] which gives me an amazing power to extend mORMot easily even further - and I love it :-) Many things in our new app will be working by simply marking things using attributes, up to replacing whole classes in services with more refined versions.

Thanks sakura! Is the use of [Attributes] a new feature in mORMot 2? That sounds good, but I just did a grep search into the mORMot2 source and didn't find anything related to `TCustomAttribute`... would you point me to any place that has such example or info?

sakura · 2021-12-09 20:54:24

edwinsn wrote:

Is the use of [Attributes] a new feature in mORMot 2? That sounds good, ...

Just part of Delphi, the creation and use of them is part of our internal development team.

edwinsn · 2021-12-10 05:28:52

sakura wrote:

edwinsn wrote:
Is the use of [Attributes] a new feature in mORMot 2? That sounds good, ...
Just part of Delphi, the creation and use of them is part of our internal development team.

I'm still interested, what does you team use the attributes for?

I know there are some uses of attributes are very helpful:
- In Delphi Event Bus, you can use attributes to define whether you want your event handler to be run in the main thread, in the calling thread or in a dedicated thread.
- Some ORM framework uses attributes to define the object models ( I do wish I can define default db values in mORMot, BTW).

sakura · 2021-12-10 07:17:40

Pretty much everything, we want automated. As sample (sorry for posting directly, but that makes discussing easier:

type
  [PXDomain, PXDomainSubstitute, PXDomainEasyAccess, PXCrudRW, PXDomainHistoryEnable, PXDomainLink(TPpAddress, 1), PXDomainLink(TPpContactPoint, 1)]
  TPpDoc = class(TPpUser)
    ...
  published
    [PXDomainElement] property EFN: UTF8String read FEFN write FEFN;
    [PXDomainElement] property Birthname: TPpPersonName read FBirthname write FBirthname;
  end;

Our Domains, which the client may work with, look something like that - at the start all of them are analyzed and prepared. The meanig for those attributes are:

PXDomain - available for client use
PXDomainSubstitute - replaces the parent domain (TPpUser) in all services/calls automatically, thus allowing us creating a base server framework that can be reused for other purposes. This server will be for docs, but the same server/client framework will be implemented for support as well, where the TPpUser might be overridden by TPpSupportMember
PXDomainEasyAccess - Allow general functions to be used for streaming/searching/creation/etc for that domain, so that the developers do not have to write some vanilla code for every domain (relies heavily on generics)
PXCrudRW - client may read/write, but not delete data
PXDomainHistoryEnable - automatically versioning for this record
PXDomainLink(TPpAddress, 1), PXDomainLink(TPpContactPoint, 1) - link to other domains, and at least one of each is needed for the record to be valid - no need to declare ORM records for the link tables, or anything. This one line does it all.

PXDomainElement marks elements of the domain, which the client may manipulate, we have many more attributes for validators, constraints, etc.
Thus, the developer simply declares, what he needs, all the validation/transformation/historization/etc. is automated

Similar it is for the MVC routines, the ones available are marked with information as to which input/output parameters, the calls can be marked for access rights, thus the call never gets to them, if the current user misses the rights needed to access them. Call can be marked asynchronous, so that the server automatically spawns a new thread, before the actual MVC call is started, automatically taking their results and sending them out over websockets as they are done, or if those are missing, they will be send piggy back with any next client call made.

  [PXModule('Users', 'Benutzerverwaltung', 'core', nil, True, True)]
  TPpUsersApplication = class(TPpMvcApplication)
    [PXCall('number', TPpUser), PXUserRights(purtUserAdministration)]
    procedure User_Get(const aCtxt: TPpSQLRestServerURIContext);
    ...
  end;

Here you see part of the generic user library access. In our main product, though declared using TPpUser, the call will return a TPpDoc (see above), as this one overrides TPpUser, thus allowing the client to show all Data of TPpDoc, not just TPpUser. This needs no changes to the code of the module, there very same code will be used for our support server and the cloud administration server, each and every time returning different record types, based upon which class actually will manage the users of the system. Input is a single number (record id ;-) ), and the caller needs rights to the user administration, in order to access the call. All is part of the "users" module, part of the "core" system.

And so on, attributes basically allow us to automate almost all mundane tasks of development and we concentrate solely on the business logic. The client (web client completely done in TypeScript) gets all those information from the server and will be able to render the UI based on the rights of the user, modules started, etc. The framework will take about 1 1/2 years t develop, but afterwards we hope to reuse it for many internal projects.

Last edited by sakura (2021-12-10 07:39:45)

edwinsn · 2021-12-10 07:46:37

@sakura, I appreciate your sharing of the details and it's inspiring. I'll take some time to consider how/if I can take advantage of the `attribute` language feature in my projects!

ab · 2021-12-10 13:22:28

Yes, thanks Sakura for the feedback!
Very interresting.

In FPC, attributes are in the FPC truck but not yet in stable branch. I hope it will be available soon!

mORMot Open Source

#1 2021-12-09 08:38:19

v1.18.4952 is the best?

#2 2021-12-09 08:56:19

Re: v1.18.4952 is the best?

#3 2021-12-09 10:57:26

Re: v1.18.4952 is the best?

#4 2021-12-09 15:10:19

Re: v1.18.4952 is the best?

#5 2021-12-09 16:09:24

Re: v1.18.4952 is the best?

#6 2021-12-09 17:30:17

Re: v1.18.4952 is the best?

#7 2021-12-09 20:54:24

Re: v1.18.4952 is the best?

#8 2021-12-10 05:28:52

Re: v1.18.4952 is the best?

#9 2021-12-10 07:17:40

Re: v1.18.4952 is the best?

#10 2021-12-10 07:46:37

Re: v1.18.4952 is the best?

#11 2021-12-10 13:22:28

Re: v1.18.4952 is the best?

Board footer