> Kenneth,
>
> My compliments to such an extensive framework. I will investigate this
> thoroughly.
I'm assuming you are responding to the real ANNOUNCE, not this accidental
one. The message you are responding to is hardly "extensive" ha ha, more
like empty.
> One question though, does your framework support customer/user defined
> attributes/labels?
>
> M. Evers
By any reasonable definition I would have to say no. All specifications are
in the dictionary file, and there is no userland tool to override or modify
them. So if the caption for column WIDGET is "Widget Code", and the user
wants it to be "Widget No", we have to change the dictionary file and run a
build.
My plan from the beginning, but alas this remains unimplemented, is to allow
userland mods to any system-supplied data, using a system that protects the
original values. The idea would be that any table holding system-supplied
data (meaning data in the Dictionary file) would actually be built as two
tables. The system-supplied stuff would go into table A, and userland mods
would go into table B as overrides. A view would provide run-time access
to entries from B where applicable and fallback to A.

Signature
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
DM Unseen - 14 Jun 2005 15:16 GMT
OK I could have ignored the last post, but it makes the thread flow top
to bottom, which has some scarcity value on cdt;)
You should realize that some kind of userland mods are needed to do
e.g. internationalization. Note that in your dictionary I could not
see the difference between Caption, Name and Description. IIMO that is
required, since the Caption needs the ablity to be localized by the
user, but the Name would be fixed. Note also that in localization you
would need to distinguish between an entity's "formal" description
(sometimes also called business description), and it's user description
(which you can use as tooltip/helptext). BTW I assumed some profile
system as well. I would think the only other thing really worth
localizing is a fields format property, but most of that should be
handled by the client browser.
Another good use for this is what is sometimes called user views, which
are based on their business role (instead of their language
preferences). This is esp. useful when you designed general entities
that have different meanings for different types of users.
Kenneth Downs - 14 Jun 2005 15:53 GMT
> OK I could have ignored the last post, but it makes the thread flow top
> to bottom, which has some scarcity value on cdt;)
[quoted text clipped - 15 lines]
> preferences). This is esp. useful when you designed general entities
> that have different meanings for different types of users.
Agreed all around, we simply left it out of draft 0.1. Much closer to the
beginning I had i18n in there, but it was muddying up other efforts and I
stripped it out for the sake of clarifying those. Now that those are
cleared up we can do i18n in Copious Free Time.
In response to your specified point re: caption, name and description, these
are in fact unified right now as a single property. Our next mod there
will be to add "short caption" as a column heading, and i18n will likely
ride along that feature.

Signature
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)