> > Paul, I think you said you are writing a class to convert the .ini
> > file to an object. Sorry for not checking, and if this is not the
> > case, please ignore this.
> Yes, that's right. I was looking for an OO approach so that I could
> refer to them like oUserSettings.GetVal("FORMPOS","Top")
> > My thought would be to convert the .ini file internally to a table
> > instead of an object (refreshing the stored table at each startup).
> > I'm a big fan of OOP thinking, so it's not that, but that we have
more
> > native tools to handle relational tables then objects, thus using
> > tables opens the door to possible uses of that information then may
be
> > available in an object format. While objects are great in runtime
> > memory, tables have a more generic quality.
> >
> Your approach is akin to Malcolm's. As to your comments regarding
> native tools and relational tables (and tables having a more generic
> quality) etc - I'm not sure - I'd like to give that some more thought.
Delayed response, Paul. Had an inet outage here till now ...
I'm making one assumption that may not be true: that this is in context
of a system and not a small, self-contained utility program.
I understand your case for exposing some control information to users
via an .ini file, but I assume your application has (or will have) more
controls then only those exposed this way, thus by using .ini files you
may (now or later) have a situation where some controls are in the .ini
files while others are in tables which must then be 'joined' to form a
complete picture. It's from this standpoint that I would argue the case
for using tables, because then all of your controls are represented in a
uniform format.
There are the natural benefits of using tables, such as having the
ability to structure/view/manipulate/document controls as a collection
of tables subject to processes that operate on table input. Tables
naturally persist across sessions. They can store tracking info such as
operid and datetime stamps for the creation and last changes made, which
is sometimes useful. They can contain memo fields that store more
information about the controls contained therein, and they can be
related to other tables based on common keys.
Carrying this to the 'nth' degree is my "monolithic" app: I have an
entity, the catalog, which contains a collection of 'profiles' (tables)
that store information, process controls and metadata about objects used
in the system. This catalog is the architectural basis for the entire
system. In effect, it's an application level 'registry' in relational
table format.
For process controls, I typically have a 'profile' table for each
process the system can perform. The last such record in each table
contains the values used the last time the process was run, and are the
default values for the next setup. These represent the history of the
processes use and can be scrolled back through for repeating previous
runs, to explore it's historical usage. Examples include
importing/exporting data from/into different formats, each with
different controls.
For metadata, an example of their usage is a 'connect' class that is
used to connect the various tables used by the system. If, for example,
an attempt to connect a table fails because an index is missing or
corrupted, the class uses index expressions stored in a table to rebuild
the indexes for that table. If the table itself is missing or corrupted,
it will help the operator restore a backup, and in the worst case, no
backup, it will use metadata to recreate a new, empty table as a last
resort. It's also used to add/change/remove fields in tables previously
installed by comparing, at connect time, the metadata to the actual
table.
For diagnostics, the error handler scoops up profile tables relevant to
the failed process and includes them in a zip file that is sent to tech
support along with a problem report. Tech support receives this email
and unzips the attachment to review this data using generic or custom
designed browse/edit forms.
For documentation, I have a chapter devoted to the catalog and topics
for each of it's tables. Some tools used for this purpose are common,
such as a table formatter (Help Builder's is an example).
> > This is loosely related, but I heard someone mention that saving and
> > restoring objects using an XML format, would allow objects to span
> > sessions. Sounds sexy on the surface, but objects that contain
object
> > references (etc) may not offer as much or fare as well as their
> > relational table counterparts.
> >
> >
> I did look at using XML to persist objects (somebody did mention that
> idea and referred me to Rick Strahl's wwXML class). However
> one problem with Rick's class is that it can only deal with nested
objects if the
> XML excludes a DTD - and in that case the XML has to be used
> to populate an existing object with the correct hierarchy of objects
and
> properties. You can restore XML to a (not currently
> existing) object if the XML includes a DTD but you cannot ceate the
XML+DTD *and*
> deal with nested objects. IOW you can have your cake *or* you can eat
it !
Yeah, I have to think that the idea of persisting objects across
sessions may have some specific applications, but isn't generally
useful.
> Thanks for your input
It's an interesting question. Hope I didn't over-react :)
Bill
> Paul
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
