mORMot Open Source

Just checked, definitely not and I have not used the TUriRouter either.

Regards,
Daniel

I have the same error message, you mark value as Pointer, but SortFind expects TOrmCacheEntryValueDynArray, which value is already.

It is, thanks!

Oh yeah! Please :-)

no comments?

While this part works now, I have noticed another small, Delphi specific glitch around that. From the original sample code, I used

Prop.Value.Name

to get the type.
When using TArray it propagate as

TArray<Unitname.Typename.SubTypeName>

Due to including the unit name, FindType will not recognize the Type. Should prop value name be handled specific in that case?

I uploaded example it would generate

SomeStr: UTF8String;Fail:TArray<Decl.TPpCallSecurityRight>;

<-- note the Decl.

Regards,
Daniel

Digging deeper, you call GetNextFieldProp, which in turn only selects alphanumeric and underscores

  while tcIdentifier in tab[P^] do
    inc(P); // go to end of ['_', '0'..'9', 'a'..'z', 'A'..'Z'] chars

Therefore, the <....> part never becomes part of the typename, therefore failing the test in lns 9000+

Regards,
Daniel

Here is a simple sample, breaking with TArray<...>, working with array of ...

https://pastebin.com/JyzF67hN

Enable/Disable lines 14&17 to see difference.

Especially, when signed into the forum as known user, yeah, I read you and feel the same.

Perfect

Service Methods shall never leak Exceptions, rather work with return codes. IIRC that is mentioned in the documentation. Thus allowing the framework to optimize for speed. If exceptions may occur in your service method, you are required to use try...except...end to catch those.

Created a sample, explaining what I'd expect from copy object, and what I actually get...

https://pastebin.com/M4h7sWTb

Wonderful, thanks a bunch!

--Daniel

I am not using it on production yet, simply because our product is way away from alpha release. However, in day to day development use and testing, it's running flawless.

However, no haevy duty tests yet, no massive connections, etc. So I should not be taken seriously, when I say: go ahead ;-)

--Daniel

He is fine, just "out of network for a week".

And while were are at it, could the "wait before searching again" be turned down for logged in users?

Bad compiler message, problem is, that Delphi expects reintroduce; before overload;, not thereafter. Lines 2228 and 2230.

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.

@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.