mORMot Open Source

I have a big package with all the mormot2 units on it
I don't have any multithreading knowledge, and so don't know if the threadvars will work properly on a package. I suppose they will, but as I said, I can't really judge

So we can not compile mORMot2 as-is in a package and use it safely?

mORMot won't be ever on GetIt. It does something strictly forbidden: "adding Client Server technology to Professional"

However if it's split in smaller repos, building ones on top of the others, I believe a good part of it could be there. And that could lead those repo users to the whole mORMot 2

mORMot 2 has still not reached release status?

What would you mean by validating it?
Compiling and running the tests would be of any help at all?
I do have Delphi Professional installed and current, but as of today all my development is still D2007/Win32 focused. Working my way towards

Thank you! Now compiles fine

Yes, it was the first I tried, with same result: hangs

I download and compile mORMot2 repo almost every day; no problems so far; will report whenever I find any other trouble

Unfortunately, I can't change that

The much excellent "Calibre", it's an open source piece of art, a do-it-all tool to handle eBooks, from library handling to eBook reader sync

https://calibre-ebook.com

I browsed to the documentation page, and just downloaded it as plain html. Then droped the file on Calibre
Right clic on it, chose "Covert book",  and then the first option (don't know the english caption, but it's not the bulk one)
There I just chose one thing: on "Page Configuration" I chose "Kindle" in both "Input profile" and "output profile". It was a random decision; don't know if it's needed at all
And "OK"

There is a load of stuff you can customize, but I didn't use it

Delphi Help:
function LoadPackage(const Name: string): HMODULE; overload;
function LoadPackage(const Name: string; AValidatePackage: TValidatePackageProc): HMODULE; overload;

Ofcourse, I know I would get more speed and less resource usage.
So, you should ensure you understand that I might have a reason to not removing the checkmark on "Build with Runtime packages"

Yes, I understand it absolutely. And I keep the checkmark because the value it gives me is much higher than the pros of the single exe

Edit: I never use packages on the path; I always install the auto-loaded packages in the exe folder

* Clean D2007 install
* Clean computer
* New package
* without DCUs, .local, .identcache

it happens few, random times

But if I make a package with all three of mormot.core.mustache, mormot.db.sql,mormot.net.rtsphttp.pas, and any other units you want, it compiles fine

Following this rule and recreating the *.dpk and *.dproj on the first computer, it all works fine

So this "issue" is SOLVED

I do need packages, as in no-go if it doesn't work inside one
Why? My only app is an ERP, where everything is in bpl's. It's heavily customizable via packages: the customers that need customizations, have a package,a bpl, wich integrates perfectly with the program, to the point you can't tell what is "native" and what is not. Form and datamodule inheritance allows to change standard behaviours, if that is needed. And so on...

In short: yes, packages have a place in this world. Perhaps not in the microservices world, but for now that's not my world anyway

But the problem is the input... In MVVM, the view is bound to properties on the VM, and that binding must be bidirectional, unless it's just a report or something as that, wich is not the MVVM target
The view is expected to be codeless or as near to it as possible, and to alter the VM just through binding (and actions to a lesser degree)

@ab ?

Is for real the MVVM in the documentation, or a typo?

You are forgetting we have bpl
I have a standard ERP, and for the few customers with non standard needs we make modules (packages) that plug in the system, using all standard stuff, and adding or overriding any functionality

I'm starting with mORMot, so I'm just making some packages with the sources, wich works fine

Drawback: when you build a new version, you need to rebuild the customer packages as well

Thank you very much; that has helped me a lot

First: The blog topic has fooled some people: yesterday I was told that you were dropping Delphi and keeping only FPC.

1) Compiler versions: whatever you decide will be fine. Myself, just finished migrating from D5 to D2007, and halfway from D2007 to D10.3.3
2) Non-visual components: a must te get more users onboard
3) Spliting units: Bravo!  Right now loads of wonderful stuff is lost there
4) Spliting documentation: from mobile devices is very very difficult loading the current page; many times I just can't load it all. There is even a chinese page that uses your documentation page as demonstration for a web client library performance

Please, please, split the project in subprojects that will give both more visibility and more users. Right now I've started to use just your JSON library, but it took with it a load of unrelated stuff. Make it so you have, say, "Core", "JSON", "Mustache" and all the great stuff.

You will have perhaps 5 or 20 subprojects, that will attract developers by themselves. Each repo will get people looking for that specific stuff, and once they are onboard, it's way easier they are interested on the other stuff

I'm probably wrong, but I believe spliting and decoupling your repos will boost very much the mORMot family

Now I'm begining to get it; I was absolutely lost.

Thanks for all the advices packed in your answer; will be of great help.

Thanks again, AB

Somehow I missed it; now I've read and on my way to understanding the mechanics

I'm used to put my business logic on the OnBeforePost, OnAfterPost, OnBeforeDelete, and so on.
Where and how should I implement the business logic of objects?
I'm refering not just to field validation, wich currently I implement on the OnBeforePost, but also things as deletion validation (Is acceptable deleting this object?), insert validation, side effects on other objects, and so on.