Looking for a property driven "documentation" component

[Guest]

For a new (and rather big) project i have decided not to create any packages, so that it can be more easily compiled and moved. I use the concept of "interceptors"* moderately to reach this goal.

 

But there are some things that would benefit from adding a couple of properties to some of the components on my "form" (actually TDataModule). For example, all my DataSet(s) would benefit from a chunk of text that can be edited in design-time.

 

One way of doing this is to create something i lieu of DevExpress TPropertiesStore. This component basically enumerates all controls and their properties on a given form and allows you to check/uncheck each property.

I was thinking that i would need something similar, but instead of managing storage and loading of property values, i'd like to be able to attach a longer "help text" to each component, to be accessed by code in runtime. And for each component, perhaps even some properties.

 

So imagine a on-form component that enumerates the other components and offers me to store a text (or a set of texts) in the DFM for each. The project i'm working on would benefit from something open source and/or "easy" to access 3rd party as i also want to keep the needed "subprojects" at a minimum. I could just use a memory-dataset and store it's data in the DFM, but then i'll loose the immediate connection and overview of available components.

 

Suggestions?

 

TIA,

 

/Dany

 

* https://windwings.wordpress.com/2009/10/07/turbocharging-delphi-2010-2-adding-dynamic-functionality-to-3rd-parties-the-solution

Edited October 8, 2019 by Guest

[David Schwartz 413]

Who is the consumer of this data? Run-time access presumes the end-user, which doesn't make much sense. End users have no knowledge of what's under-the-hood. It's like when SQL queries fail and spill these horrid run-on queries to the user in a warning box. Great for testing, but bad to have them exposed in the field.

 

Can you describe your use-case better? (some?)

[Guest]

The consumer is the end-users. And the components are mainly DACs.

On 10/9/2019 at 1:04 AM, David Schwartz said:

End users have no knowledge of what's under-the-hood.

True, but in many cases depending on how you set up the different data-models it can be a boon to fetch a description of the "role" of the dataset in the application. Think "Fieldnames", "Field hints" and one such for the "Query".

[David Schwartz 413]

If memory serves me correctly, MS SQL Server has a metadata-field attached to everything that serves just this purpose. It's distinct from the ones that you can add comments in SQL GUI tools.

 

I was looking through MS documentation for an odd TSQL API function that some code was calling, and I scrolled around the other functions in that group, and it seemed like an odd collection of stuff attached to records and tables.

[Guest]

In Firebird there's a comments too of course. This is not what i am about. Regarding comments on the SQL level i definitely agree with you first sentiment. It is not end-user stuff.

 

In previous projects i had elaborate "proprietary" dynamic metadata that covered a lot, almost all. But this time i'd like to use the "design time" in the IDE.

Thus; to attach metadata to a query and extended metadata (textual) to fields would be good.

For example, i may have two lookup datasets that are actually the same SQL "table". But they are used in different contexts and produce different "output" and it fits rather good to be able to supply an "i" button (info) with details that users can read when the support is sleeping. I usually document all functionality per client (that is per implementation, varying databases) in a way that is suited to a "superuser". The key here being not to enable any end-user to do all, the key is that the system and all it's micro-business-decisions must be 100% documented. Especially when the clients donors (owners, whatever) comes down on us with a huge revision (here they call it system-revisions). Things like testing backups, and also checking that all business-logic is properly documented. Where better to document what each "query" (or set of) does, it's tweaks and even client-side code. A boon is that after a year or two a superuser can help controllers and others to figure out what went wrong when - as we all know - things will.

 

So - i should really inherit my components and add the properties that i need. BUT as i wrote above, this is not the "style" i want this project to have. Thus this thread.

 

/D