@Ferrari_Julio, well, it's unlikely that will happen. That's why we added the customization script feature - to prevent adding dozens and dozens of UI elements that will be often used by a few.
So customization script is the way to go, if users contribute, we can curate a repository of several scripts that do all kinds of tasks.
Hard to believe.
When I read the new documentation I thought it would naturally lead to a DataModeler upgrade.
It would be far better than mantaining dozens of columns this way:
procedure OnColumnGenerated(Args: TColumnGeneratedArgs);
var
LTipo, LCampo : string;
begin
LTypeName := LowerCase(Args.CodeType.Name);
LFieldName := Lowercase(Args.Field.Name);
if (LTypeName = 'tperson') then begin
if (LFieldName = 'classrate') then begin
Args.Field.AddAttribute('DisplayName').AddRawArgument('''class rate''');
Args.Field.AddAttribute('Range').AddRawArgument('1, 10, ''Values must be %1:d up to %2:d for field %0:s''');
end else if (LFieldName = 'othercolumn') then begin
...
end;
end else if (LTypeName = 'TOtherType') then begin
...
end;
end;
1 Like
Sorry about that.
Hi Wagner,
Don't be sorry, you have a great tool in Aurelius, but it is not complete until Data-Modeler is capable to set all up and you have the Aurelius /DB configuration in one place, I see this two parts as one unit. It is a disaster from maintenance view to deal with the scripter it can be very error prone. The goal must be that all features that are in Aurelius should be in possible to set in Data-Modeler as well, that my point of view and I think it is more than me and Ferrari Julio that have that opinion.
1 Like
This seems similar to debating between setting VCL component property values in the OnCreate or OnShow methods of a form vs. in the IDE's Object Inspector. There are things that simply cannot be set in the OI, so you have no choice but to set them in code. The thing is, if they're in the main body of code, it's easier to notice changes (accidental or otherwise) than if they're hiding in the .DFM file. (In fact, the absolute WORST offenders involve how Actions work. O-M-G! Their settings are so effing opaque and hard to find I just refuse to use them. For DBs, it's tables with virtual fields that are used in different computations, especially when they're being used in another form. Grrrrr...)
Diagramming is nice, but having to go through forms with lots of redundant data becomes tedious after a while. Sometimes I wish I could just use a grid like a spreadshet and define a few columns and lots of rows with whatever attributes are needed, then click a button and have all of the code generated. I just want to get stuff out of my head as quickly as possible these days.
1 Like
@Schwartz_David I personally agree with you, but I'm not debating taste here. Data Modeler is a great tool and is there for many people, and is a very nice tool indeed for the approach chosen by those users.
The question I'm raising here is that I'm not sure about cluttering the Data Modeler UI with every possible thing that could be made with Aurelius. For example, should Delphi have a menu item "Create method" that you type the method name and it creates it in the code, or just let the developer write the method? A "create method" menu item might be a nice to have, but I think it's "too much". So that's the point, where the line should be drawn?
2 Likes
Off topic - I don't agree or disagree with your points. I just like your logic and the way you lay out explaining things. Very interesting. I have found some good programmers who happen to be very good writers - I guess it is the clear logic that makes the difference, even though the chosen written language is not their native ones.
1 Like
I prefer more features in Aurelius and other Business componets that they are really needed.
Also better and updated documentation than checking all the time the source code that will change in the next update.
I think the script tab's power is also underestimated and probably needs some videos for most of us.
1 Like
By the way, most databases have JSON database fields. When will we be able to use them in Aurelius?
It's in the backlog. No timeframe yet. @Wuping_Xin and other, for example, are in the line waiting for the next native PostgreSQL support ;-)
1 Like
Me too, Wagner.
And somewhere I read that it will support the JSON fields too 
1 Like
SIDEBAR: a while back, a couple of patent lawyers approached me to see about building a tool that would help them generate their client patent application documents quicker. They had developed an approach that was highly structured and looked like a great candidate for something that could make things easier and quicker for their workers. In fact, they wanted me to build them something that would reduce the amount of time it took by 1/3 to 1/2.
As they were explaining things to me, I'm thinking of something like a big template generator that had a bunch of combo boxes and edit boxes (both one-line and multi-line) on it. I thought of this as the "obvious approach".
When they were done explaining it, one mentioned, "Oh, we should tell you we just finished working with another coder who built something for us, but it didn't work out well." They fired it up and showed it to me. It was the exact thing I had conjured up in my mind as they were talking to me. It takes a very similar approach to how DB Data Modeler and most DB tools work.
The problem in this case was they said it took their people 2.5 times longer to create the documents, and after building several, it didn't look like they'd be able to speed up what they were doing by very much simply due to the way the tool was organized and what-not. This approach would not improve their time at all versus what they were already doing.
In other words, they found it was faster for their workers to use a simple copy-and-paste approach to taking boilerplate text from a document and then doing block text replacements and insertions where needed than to use a "more automated" tool that most programmers would lean towards building initially. Furthermore, using boilerplate was found to be decidedly faster than NOT using boilerplate. The so-called "automation" that tried to finesse the boilerplace approach only slowed things down.
Part of the trade-off is clearly a question of "how much of the necessary (or likely) text or program code do you include in the automated tool?"
I've got this other browser window open next to this one that shows something Bruno pointed me to in another question. It lists all of the parameters you can use in Build Events (for the Delphi Project Mgr pane). It's really handy because there's absolutely nothing in that Build Events panel to suggest what you might want to use. It's really not much more useful than a blank sheet of paper, implying it's designed for "experts" who already know what's needed.
Having drop-downs there that list possible parameters for Build Events would be helpful mainly if you're NOT a total expert and already know all of the stuff off the top of your head. If you ARE an expert, it probably won't speed things up much, if at all.
Similarly, it might be helpful to have a tab in the DB Data Modeler that lists a bunch of possible methods that would be useful, along with a way to select some (a check-list) that you wanted to have generated for you automatically. Not because everybody would use it, but because it's a useful help guide in itself. Simply not showing anything means you have to open a help page or the document and hope they both get updated when the information changes.
There are ways to be helpful in different ways that don't require the user to employ them every time. Sometimes just having the options listed there is helpful in lieu of having to maintain separate documentation in one, two, or even more separate locations.
1 Like
I full agree with you @Schwartz_David, if you have something that it is "featured" enough.
So, the result is to balance between needed features.
To be honest, if Datamodeler has all these speed dropboxes/checkboxes and gives everything automatically in code, I prefer not to have the attributes/generics and have Aurelius to be compiled by FPC too.
Reading the above, I am pretty sure that Arnaud Bouchez is just missing a Data modeler that exports ready code through checkbox/dropbox selections. Probably, TMS should think about providing a DataModeler and class helpers for Mormot, will be better source of money for TMS.
My just two cents.
1 Like
I am not disagreeing with you, but maybe oddly, I am one of those programmers that prefer the Code-First style. I personally have never used Data Modeler, and just type everything using my clicky mechanical keyboard.
I recently used both Aurelius and mORMot in one of my applications.
I feel mORMot is probably of a different design philosophy (or scope) than Aurelius.
- On one hand I like mORMot's performance-oriented focus where user-supplied SQL statements are still needed here and there;
- On the other, I also like the higher-level ORM abstraction of Aurelius that completely hides SQL details. I also like Aurelius capability to connect with VCL/FMX data-aware components.
In my application, I use mORMot and Aurelius for different scenarios, and I am happy with both.
I personally would be more interested to see Aurelius having better integration with ZeosLib (direct ZDBC, which gives great performance), than mixing itself with mORMot, or having Data Modeler supporting mORMot (eh.......why Aurelius should care mORMot at all it is like asking Microsoft to invest in Linux or Apple ....)
1 Like
I never mixed up Aurelius and mORMot and I agree that they have different philosophy and users.
I just talked about having a high level, code creator, user friendly to new users, Data Modeler for mORMot. if someone belives Aurelius needs so much the Data modeler, probably you @Wuping_Xin, you can tell more about how much needed is a Data Modeler for a new user in mORMot. Even with its excessive html documentation.
Hello, is there now a way to use Aurelius with JSON data fields?
@Maenken_Bjoern, unfortunately there has been no progress for that specific feature so far.
Out of interest, is the global filtering feature introduced in Aurelius v 5 available to XData client applications using the default Aurelius endpoints? I just had a look at TXDataClient and it doesn't appear to have an EnableFilter method in the same way as the TObjectManager. I'm wanting to attempt to leverage the new multi-tenant feature.
Actually for multi tenant applications you should enable such filter server-side.
Here is a small tip to use a XData event for it: Server-Side Events | TMS XData documentation
Besides of course the full documentation about global filters: Global Filters | TMS Aurelius documentation
And the tenant middleware: Middleware System | TMS Sparkle documentation
In case you want to go deeper this was covered in a session in the last TMS Days 2023:
1 Like
Thanks for the tips. Got it working well. The more I use the biz products the more i like them 
1 Like