More mORMot2 examples: adapted from DMVCframework

Javierus · 2025-12-23 17:11:15

I've adapted more than 40 examples from the DMVCframework to mORMot2

The intention is:
1. Have more examples for mORMot2
2. Help DMVCframework users transition to mORMot2

I've posted them in my own public GitHub, but I would be very glad if Arnaud is willing to add them to mORMot2 samples

ab · 2025-12-23 18:57:51

Sounds amazing!

Perhaps we could add them as git sub-modules?
By default, no sub-module would be loaded, but if --recurse-submodules is defined, then all third party samples would be included?

But sub-modules could be confusing, and samples are mostly for beginners, so they may expect to have as many sample as possible to find their way into the code...
My other concern is that if it is part of the main repository, they would need to be maintained somewhat. And it is already not so easy to maintain our third-party samples...

Or we could just add them to the third party folder of the mormot 2 repository? Perhaps if there are a lot of sample there, everyone would understand that they are not at the same level of maintainability?

Worth a common discussion...

zen010101 · 2025-12-24 03:25:53

Wow, there are so many demo programs! It feels like their number has even exceeded the examples that come with mORMot itself! I don't think anyone would dislike more examples, heh heh.

Personally, I still prefer the ThirdParty solution. Just like it is now, it can greatly reduce everyone's cost of obtaining examples.

ab · 2025-12-24 10:18:26

OK.
I have included the samples as https://github.com/synopse/mORMot2/commit/13fe46e06
into https://github.com/synopse/mORMot2/tree … os/dmvc-ai
(I trimmed some *.rsm files from the original repository)

Now users won't complain about the lack of samples!
Thanks a lot for sharing.
All this AI-generated stuff is very interesting.

rcla · 2025-12-25 15:57:44

@Javierus , Thank you very much for all that number of examples, in addition to all the SAD documentation that you have provided.

I'm using FPC 3.2.3 (fixes) with Windows 11 and wanted to learn about HTTP Basic Authentication.
So I took the "08-basicauth" example, but I ran into the following issues:

It was showing a related error that "RegisterInterfaces" was missing...
I fixed it by adding the following code to the "api.interfaces.pas" file:
```
initialization
  TInterfaceFactory.RegisterInterfaces([TypeInfo(IBasicAuthApi)]);
```
Inside the Log file, an error related to "useHttpApiRegisteringURI" is displayed.
"TRestHttpServer(06222840) Create: HttpSetServiceConfiguration() failed: ERROR_ACCESS_DENIED (5) for root - useHttpApiRegisteringURI may need admin rights"
"EXC ERestHttpServer {Message:"TRestHttpServer: http.sys URI registration error ERROR_ACCESS_DENIED for http://+:8080/root (you need to register the URI - try to use useHttpApiRegisteringURI)"}"
I solved it by changing from "HTTP_DEFAULT_MODE" to "useHttpAsync"
```
  // Create HTTP server
  fHttpServer := TRestHttpServer.Create(aPort, [fRestServer],
    '+', useHttpAsync, {threaded=}32); 
```

It showed several memory leaks when exiting the program.
I solved it by adding a variable "fModel: TOrmModel;" and you don't need to free "fBasicAuthApi"

  // Create in-memory REST server (no database needed)
  fModel := TOrmModel.Create([]);
  fRestServer := TRestServerFullMemory.Create(
    fModel, 'root', {authentication=}true); 

destructor TBasicAuthServer.Destroy;
begin
  Stop;
  fHttpServer.Free;
  //fBasicAuthApi.Free;
  fModel.Free;
  fRestServer.Free;
  inherited Destroy;
end;

The program did not work correctly, with or without authentication it did not show the expected results.
After spending hours understanding how it worked, I found that the problem is with "methodName"
For some reason "Ctxt.UriMethodPath" always returns empty.
And within the code you have to:
```
  methodName := Ctxt.UriMethodPath;
  if methodName = '' then
  begin
    // Fallback to full URI
    methodName := Ctxt.Call^.Url;
  end;
```
The problem is that it returns the entire Url.
For example, we obtain that:
methodName ="root/BasicAuthApi.PublicSection" , but it was expected that methodName ="PublicSection"
methodName ="root/BasicAuthApi.OnlyRole2" , but it was expected that methodName ="OnlyRole2"
methodName ="root/BasicAuthApi.OnlyRole1Json?par1=hello" , but it was expected that methodName ="OnlyRole1Json"
I solved it by doing the following code (maybe not the best solution, but it works)
```
  methodName := Ctxt.UriMethodPath;
  if methodName = '' then
  begin
    tmpUrl := Ctxt.Call^.Url;
    mPosIni := PosI('.',tmpUrl) + 1;
    mPosEnd := PosI('?',tmpUrl);
    if mPosEnd >0 then
      mLen :=  mPosEnd - mPosIni
    else
      mLen := length(tmpUrl);
    methodName := Copy(tmpUrl,mPosIni,mLen);
  end;
```

flydev · 2025-12-29 10:41:17

Hello everyone,

first of all, thanks Javierus for throwing tokens into this set of samples!

disclaimer: I really don't want to sound like a party pooper

IMHO, when samples are generated with AI models, we should enforce a simple rule: the sample should include its own tests.

Not to annoy anyone, but rather for quality reasons, and to avoid potential frustration for new users. As @rcla already mentioned, there are still errors. I personally tested two samples (26-middleware_analytics and 51-react), and neither of them worked, tested with Delphi 12.3 and FPC.

My opinion, having non-working samples in the official repository can negatively impact how newcomers perceive mormot when they just want to try things out. I strongly believe in quality over quantity. I'm allowing myself to say this because, just this week, I tried again to give FMX (with Alcinoe) a LAST chance for an iOS/Android project... failed miserably and ended up coding the apps natively with Xcode/Swift and Android Studio, simply because the IDE combined with the libraries (and the samples) generated too much frustration (remember that gif?)

The only thing that works exactly as I expect, without complaining, is my mORMot servers

ab wrote:

...
Worth a common discussion...

To me I liked @mpv idea suggested in this topic.

Yeah, I know... in the end, I am a bit of a party pooper

ab · 2025-12-29 12:12:55

Yes, its own repository may make sense.

Using sub-modules may been overkill, but a separated repository may make sense...

Or the samples should be humanly tested and validated.

Javierus · Today 12:58:27

Thanks all for the time spent with them; I plan on giving them a second run, which would include testing ttjem at runtime, and when it's solved, then run both the samples with DMVCframework and mORMot2 and compare the results

Although I will do all of it without human intervention; it's where I am now. My mistake with this task was not including thorough testing, specially against the original examples compiled on it's original environment, as Source of Truth

Thanks again

mORMot Open Source

#1 2025-12-23 17:11:15

More mORMot2 examples: adapted from DMVCframework

#2 2025-12-23 18:57:51

Re: More mORMot2 examples: adapted from DMVCframework

#3 2025-12-24 03:25:53

Re: More mORMot2 examples: adapted from DMVCframework

#4 2025-12-24 10:18:26

Re: More mORMot2 examples: adapted from DMVCframework

#5 2025-12-25 15:57:44

Re: More mORMot2 examples: adapted from DMVCframework

#6 2025-12-29 10:41:17

Re: More mORMot2 examples: adapted from DMVCframework

#7 2025-12-29 12:12:55

Re: More mORMot2 examples: adapted from DMVCframework

#8 Today 12:58:27

Re: More mORMot2 examples: adapted from DMVCframework

Board footer