Page 2 of 2
Re: Deferred Lobs feature suggestion
Posted: 05.04.2021, 17:16
by aehimself
Offtopic - why are we that much attached to properties stored as strings...? Why not to introduce a new "settings" class like "Zeos" and put our settings there as enums, integers, etc? So instead of ZDataSet.Properties.Values['whatever'] = 'True' you could simply say ZDataset.Zeos.Whatever := True.
If it was like this from the beginning and it's now considered legacy how long do we plan to carry this on?
Is there any advantage of this which I can not see yet?
Re: Deferred Lobs feature suggestion
Posted: 08.04.2021, 07:04
by marsupilami
aehimself wrote: ↑05.04.2021, 17:16
Offtopic - why are we that much attached to properties stored as strings...? Why not to introduce a new "settings" class like "Zeos" and put our settings there as enums, integers, etc? So instead of ZDataSet.Properties.Values['whatever'] = 'True' you could simply say ZDataset.Zeos.Whatever := True.
If it was like this from the beginning and it's now considered legacy how long do we plan to carry this on?
Is there any advantage of this which I can not see yet?
I think that having the strings is much mor flexible for several reasons:
- It is is much more simple to load Strings and lists of Strings from ini files. Having a new class with members etc would comlicate things in most use cases that use this, I think.
- Saving and loading human readable values for enums has to be done with RTTI and is a nightmare. I did that for the web service driver and don't want users to need to learn how to do that.
- Currently it is perfectly possible to write a driver that is not integrated into Zeos. This driver can have its own options, that the main Zeos doesn't need to know about. I think a new class would complicate things in this kind of use case.
- PostgreSQL uses a kind of connection string where one set options to use for the server. I have been thinking about implementing something where every entry in properties that starts with pg_ becomes an option in this connection string. This would allow setting any PostgreSQL option - not only the ones that Zeos is prepared to set. But could get impossible or clumsy to do when we use a settings class.
Best regards,
Jan
Re: Deferred Lobs feature suggestion
Posted: 08.04.2021, 08:29
by aehimself
Makes sense, but I disagree with the serialization part. I usually have a settings window in my application (or a settings application in headless programs), the user doesn't have to touch the settings file. It's possible but they must know what they are doing, end of story :)
Serializing enums only requires a bit of code:
Code: Select all
Const
FONTSTYLE_BOLD = ' bold';
FONTSTYLE_ITALIC = ' italic';
FONTSTYLE_UNDERLINE = ' underline';
FONTSTYLE_STRIKEOUT = ' strikeout';
Class Function TMyFont.StringToStyle(Const inStyleString: String): TFontStyles;
Var
s: String;
Begin
s := ' ' + inStyleString.Trim.ToLower;
Result := [];
If s.Contains(FONTSTYLE_BOLD) Then Result := Result + [fsBold];
If s.Contains(FONTSTYLE_ITALIC) Then Result := Result + [fsItalic];
If s.Contains(FONTSTYLE_UNDERLINE) Then Result := Result + [fsUnderline];
If s.Contains(FONTSTYLE_STRIKEOUT) Then Result := Result + [fsStrikeOut];
End;
Class Function TMyFont.StyleToString(Const inStyle: TFontStyles): String;
Begin
Result := '';
If fsBold In inStyle Then Result := Result + FONTSTYLE_BOLD;
If fsItalic In inStyle Then Result := Result + FONTSTYLE_ITALIC;
If fsUnderline In inStyle Then Result := Result + FONTSTYLE_UNDERLINE;
If fsStrikeout In inStyle Then Result := Result + FONTSTYLE_STRIKEOUT;
Result := Result.TrimLeft;
End;
It all comes down to preferences I suppose. I also don't want to hijack the topic :)
Re: Deferred Lobs feature suggestion
Posted: 19.05.2021, 13:49
by Fr0sT
aehimself wrote: ↑08.04.2021, 08:29
Serializing enums only requires a bit of code:
With "array[TFontStyle] of string " you can replace multiple if's by loop; next step would be GetEnumName/GetEnumValue
Regarding the options: yep they're quite cumbersome. But wide range of supported engines and options requires flexibility that only strings have. Nevertheless, some properties are already transparently mapped to TStrings - like connection properties. I guess it wouldn't be too hard to implement TZParams = class(TStrings) that would expose some generic properties.