Ticket #70 (closed enhancement: fixed)

Opened 2 years ago

Last modified 2 years ago

Allow field container type to return documentation about fields

Reported by: allenb Assigned to: unassigned
Priority: major Milestone: 2.0 Beta
Component: System Version: 2.0
Keywords: Cc:
Completion:

Description

The .fcd files have documentation in them, why not make it possible for the FieldContainerType? classes to return this documentation at run-time?

Change History

09/29/06 07:13:39 changed by cneumann

Since this will probably increase the lib size considerably (this is just a guess - not based on hard data) and given that they already are big, what are the advantages of this ? (Note: I don't think this is a bad idea, but why is it a good one ?)

(follow-up: ↓ 3 ) 09/29/06 07:55:18 changed by allenb

I thought about the library size issue and I don't think it will increase it by that much. If we consider that there may be 100 bytes average per field, say an average of 8 fields per fc, and there are about 100 fc, then that is 78k across all the libraries. The latest build of the libraries (debug on Linux) takes about 210MB I don't think 78K will add much to the size of the libraries. :)

The benefit is that for run-time tools that want to examine things through the reflective interfaces, it would be possible to present the user with documentation about the fields and types being examined.

(in reply to: ↑ 2 ) 09/29/06 09:42:57 changed by cneumann

Replying to allenb:

I thought about the library size issue and I don't think it will increase it by that much. If we consider that there may be 100 bytes average per field, say an average of 8 fields per fc, and there are about 100 fc, then that is 78k across all the libraries. The latest build of the libraries (debug on Linux) takes about 210MB I don't think 78K will add much to the size of the libraries. :)

you are right. By the way very good estimates, by counting all occurences of <Field in the .fcd files I get the following: OpenSG 1: 824 (including Contrib) and OpenSG 2: 690 (there a duplicates here because of the WS/ES stuff).

The benefit is that for run-time tools that want to examine things through the reflective interfaces, it would be possible to present the user with documentation about the fields and types being examined.

10/01/06 15:24:50 changed by allenb

I was thinking about this a little further, and it seems to me that it should be possible to ask a type for all it's original meta-data from the .fcd file. This could be very valuable information to any number of tools that want to use the reflective APIs of OpenSG. A simple way to store this would be to store the original XML data as a string that can be returned from the types. This would provide the maximum amount of information available and would keep working in the future even if additional information is added to the .fcd files.

10/02/06 22:22:48 changed by allenb

  • status changed from new to closed.
  • resolution set to fixed.

Addressed in r219