A theory question regarding XML

[Henry]

I know it is possible to store dynamic propterties for applications in XML
files. The app.config and the web.config files can be used to store
AppSettings... I am just wondering how far one can go with this technique.
In my case, what I am interested in doing is to store information about
reports and report parameters that I might want to use in an XML file.

Ideally I'd like to get to the point answer and respond to the following
questins by reading a data file:
For a given report:
What are the parameters I need to pass to the report.
What are the parameter names?
What are the parameter data types?
What query should I issue to the database in order to retrieve the
possible values?
What type of Interface control, e.g. listbox, combobox, treeview, etc.,
should I use to display this information?
Given the specific Interface what data do I need to set to populate that
control? How do I associate a data column from the query to a control
property?
Perhaps even where on my query form should I place this control?
What report file will I be opening?
If I am pushing data to the report, what is the query or queries I used to
generate the DataSet?

The major question here is whether it is possible to build data controls
based on dynamic data read from a file? and if so, what is the strategy
for doing so?

 

[Guest]

Its certainly possible to do what you're asking. Controls can be added
dynamically to both forms and pages. I'm not sure that I'd put this
information in app.config or web.config.

My preference would be to try to read as much of the information from the
report file itself (if possible). Things like parameter names and types are
available through most reporting APIs. The rest of the information could
either be in a database or in a separate dedicated config file.

The big question here is how are you going to manage the information?
Because the information is so unstructured, I would probably suggest the
separate config file to make things easier. Another choice would be a
separate config file stored alongside each report so that the reports
themselves are more portable (just the report definition file and the config
file).

 

[Kevin Spencer]

Hi Henry,

If I understand your question correctly, you want to know if you can store
specific Control-building information in an XML file. The answer is yes.

Again, hoping I understand you fully, I am doing a similar type of project.
I'm building a "simple" printing engine that can be plugged into any .Net
application to create print jobs. This is a "generic" print engine, that
works with documents made up of rectangles containing various kinds of data
in them, such as formatted text, images, boxes, lines, and database data.
One of the requirements is that a document can be saved and/or loaded from a
file.

Now each of these "PrintElement" types is a Control that can be used on a
"PagePanel" Control to visually build the print document. The "PagePanel"
Control can be hosted in any .Net Windows Form, and is a container for
"PrintElement" Controls. All "PrintElement" Controls share certain
characteristics. They can be transparent, or have a colored background. They
can be resized, dragged for re-positioning, and each can bring up a Dialog
Box to set various properties of the Control, such as Font, Background
Color, Border Width and Color, and so on. They are all highlighted by a
purple outline when the mouse hovers over them, and they can overlaid in
various Z-Orders.

So, I created a base class called "PrintElement" that is derived from
UserControl. I gave it all the basic properties and functionality shared
among all "PrintElement" classes. Then I created a derived "PrintElement"
Control class for each different type of PrintElement, to handle the
different behaviors, such as being able to select an image for an
"ImagePrintElement" or a DataSource for a "TablePrintElement."

Now, as you know, a System.Windows.Forms.Control class cannot be serialized
as XML. But I wanted to be able to save a print document in an XML format
for cross-platform compatibility and other reasons. So, what I did was to
create a "PrinterDocument" class that could be serialized as XML. This is a
container class for "PrintElementData" classes. I also created a base
"PrintElementData" class that could be serialized as XML. It contained all
the information (data) needed to populate a "PrintElement" base class, in a
serializable (as XML) format. For example, for Font, I created a "FontData"
class which holds all of the characteristics of a Font (which also cannot be
serialized as XML). For colors, I used the integer value of the given
System.Color (a Color can be converted to and from an Int32). And so on.

From this I derived a "PrintElementData" class for each "PrintElement"
class that I had, one for each. Then I added functionality to the
"PagePanel" Control that enables it to open an XML file, deserialize it to a
"PrinterDocument" class with a Collection of any number of
"PrintElementData"-derived classes in it as a Collection. It uses Reflection
to discover the exact type of each "PrintElementData" instance, and then
assigns it to the appropriate "PrintElement"-derived class, which it then
adds to its Controls Collection. It can also save its current state to a
file by doing the opposite. It creates an instance of "PrinterDocument," and
adds the "PrintElementData" instance from each "PrintElement" in the page to
the "PrinterDocument" "PrintElementDataCollection." Then it serializes that
as an XML file.

So, the basic principle is this: You can't actually serialize a Control, but
you *can* serialize the properties of the Control, which can then be used to
re-build the Control from a deserialized class at run-time.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.

 

[Henry]

Thanks for replying... The Report Manage code that I currently interface
with has hard coded the parameter data, e.g. the parameter names controls
types, all actions required to populate them. Because every time I or any
other report writer wants to add a new control to address some aspect of the
our application, we have to get the programmer involved again.

I want a design that will eliminate this bottleneck and give us more
flexibility. Some of the parameters are used in many different reports and
so I should probably have a separate section just for parameter. In that
section I would have to store the information that would guide my building
of the appropriate data controls.

I would open the report file and determine what parameters are present. Then
I would search the config file and locate the data I need to create and
populate the necessary controls..

Right now the report manager just reads the parameters from the report file
and throws the controls up on the form as they are read. That gets sloppy.
I need to figure out some sort of algorithm to say if I have these specific
controls this is the way I want to lay them out.

As Jeffrey noted, I don't think this should be stored in the App.config
file. I would expect it to be a separate XML file. In my next post I hope
to layout a sample XML format for your comments.