[fpc-devel] Rather large flaw in TJSONConfig component

[Mattias Gaertner]

On Mon, 21 Jun 2010 16:45:08 +0200
Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:

> Op 2010-06-21 16:31, Mattias Gaertner het geskryf:
> > 
> > Now I understand.
> > Yes, TXMLConfig has the same "design flaw" as
> > TStringList.LoadFromFile/SaveToFile.
> > It is strange how you get used to such flaws and think it is normal.
> 
> Like I said, if nothing gets changed in the TXXXConfig components, then
> Lazarus IDE leaves the door wide open for developers to make this mistake.
> Why, because Lazarus IDE has a TXMLConfig component on the component
> palette. Developers wouldn't think twice that they are not allow to drop
> one component on each form and have a data loss issue.

This only happens if developers thinks about TXMLConfig as a
concurrent database component. This depends on the background and
expectations of the developer. Any component can be misunderstood.
As I started with Delphi I thought TList is a design flaw, because I
started studying computer science and thought the term "list" in
programs stands for linked lists and not for arrays.
I'm sure that there are developers whos first impression about
TXMLConfig would be "configurator", which is also wrong.

IMO TXMLConfig is already useful as it is. If someone needs
concurrency and file locking it should be a descendant or a new class.

 
> Possible solutions:
> 
> * Fix TXXXConfig components to handle concurrency (multiple instances).
>   More intelligent file handling.
> * Implement a Singleton for each TXXXConfig component which is ready to
>   use for by the developer. Just like Application and Screen are single
>   instances in a application without the developer needing to do anything.
> * Lazarus could maybe warn the developer (with a popup message) if they
>   drop more than one TXXXConfig component in a project with same Filename
>   value.
> * Or TXMLConfig must be removed from Lazarus component palette as it's
>   not like all other components that can handle multiple instances without
>   problems.
> * Or remember to add clear documentation (when it is written) about this
>   pitfall with TXXXConfig components.

Is there already some documentation?

Mattias