Urgent: maybe someone already dealt with am issue like this one?

In one module of an application I am building (I already developed it using ASP at the server side) I offer to the the user (that is a seller) the possibility to set a certain number of custom views: custom views are customized ways a seller can view data (formatted in a classical HTML table) related to his clients.
On these data I am giving to the user 2 kind of possibilities of customization:
1) one related to WHICH columns (of the table containing the client data) he wants to view;
2) the other related to the ORDER under the which he wants those columns to appear in the table.
Even though - as I previously said- I already developed this module, I would like to optimize it some way by wrapping the whole in a COMponent.
A solution to which I an thinking about is the use of metadata (the name and the order of the colums) and/or maybe uthe use of an XML file that will store the preferences setted by the user: this file will have to be updated each time an user set a new custom view or modify an existent one.
Just a note: the values that will have to be passed to the COMponent are also: the seller ID (because the app will be used by many clients) and the viewID (because
each custom view will have its own view ID).
Thanks in advance.

Who is Participating?
ianouiiConnect With a Mentor Commented:
perhaps, u can start off with MSDN XML. Your suggested solution was quite true. Anyhow, it doesn't cater for heavy data which means the data cannot be too huge.

XML file is still using the flat file methodology when browsing it. Somehow, database still play its important roles.

here, I paste something about XML. hope it helps u.

good luck.

There's a problem with XML. The problem is that XML, at first glance, looks like technology that Someone Else is supposed to use.

Take your typical Internet company. Some developers are busy building Web pages. Other developers are working on network architecture and database-driven applications. Until recently, many Web developers saw XML and said, "Great, but how does it help me make Web pages?" Application developers saw XML and said, "Great, those Web folks will really like that technology." And nobody (until recently) saw XML as applicable to their problems.

When I first saw XML, I (naively) dismissed it, too, because I thought it was meant to replace HTML as a standard. I saw lots of hype, but I largely ignored it. I had apps to build. I had a site to launch.

About six months ago, I saw the first practical application for XML and immediately realized that it could solve one of my real problems: refreshing editorial content on Web pages. My colleague built a sample Web site that uses XML for content and Active Server Pages (ASP) for display. The XML could be edited in XML Notepad, and ASP parses the content and spits out a flat Web page. The sample is elegant because it effectively separates the content from the display. For this application, when the content must be updated but not stored long-term, XML was the perfect solution.

Suddenly, XML was no longer something that Someone Else is supposed to use. I was using server-side XML to simplify a task that would have taken some rather elaborate code to simplify otherwise.

XML skills in hand, I set out to do something even more interesting: separate both layout and data from the ASP layer. I made a tiny .xml file that stored both cascading style sheets formatting parameters and database query syntax. When the application runs, the XML is parsed and the database queries are run, resulting in a flat HTML page. Whenever someone wants to redesign the presentation of the data, or even to add new data, I don't need to touch the ASP code. I just open up the .xml file, which is, in essence, simply a structured text file, make some tweaks here and there, and the app performs its generic magic.

Finally, I thought, I've discovered the value of XML. I don't need to wait for browsers to be XML-enabled, I can simply create semi-structured text-based .xml files and create generic server-side applications to parse the file and format Web pages. Then, my generic .asp files simply use XML to handle the aspects of the page that might change, whether formatting or content.

I was using XML, but I still didn't see the big picture.

I didn't see it until I attended the Xtech '99 conference. In a session led by Tim Bray, co-editor of the XML 1.0 specifications, I heard something that I might otherwise have regarded as pure hype: "XML is the ASCII of the future." He was talking about using XML to exchange data across the Web. He described using XML to create data structures that can be shared between and among disparate and otherwise incompatible systems. Most of the speakers at this conference agreed that XML is to be a common meta-language that will enable data to be transformed from one structure to another. Even ASCII, or American Standard Code for Information Interchange, was not this ambitious.

I realized that XML is useful even if you don't have a Web page.

XML implements a not-so-new idea: Data should be exchanged in the form of documents, such as product catalogs, invoices, purchase orders, contracts, and more. Businesses are already familiar with document exchange. End users can understand the concept of documents more easily than they can understand abstract data structures. Companies and individuals can agree on common document formats much more easily than they could rearchitect their back-end data structures.

Although XML was designed primarily for the Web, its usefulness extends beyond the confines of a browser's window or an HTML page. For example, XML separates data from layout in a way that hides both the data source and the formatting from one another. It doesn't matter whether the XML came from a database or from someone typing it in Notepad; if the file is well-formed (that is, conforms to XML syntax rules), any XML parser can read it. This is not always the case with other types of data exchange. Often, a developer must deal with the back-end data structure in order to extract the data he or she wants. With XML, a developer locally consumes, creates, or modifies data from a logical data structure that is independent of all back-end implementation. Multiple data sources may feed data into a single type of XML structure, allowing seamless integration of disparate systems. Because XML is plain text, this integration may take place through the Web via HTTP.

You can write an .xml file in Notepad, but you don't want to have to write custom parsers for every application. That's where Microsoft Internet Explorer 5.0 comes in. Internet Explorer 5 launched with full support for the World Wide Web Consortium (W3C) XML standard and it includes a parser?the Internet Explorer 5 XML component?that not only works in the browser, but can work in any server-side application using standard COM interfaces. If you're already familiar with general XML concepts, which I'll outline briefly in the next section, you may still be interested in the last section of this article, where I will describe how I built the sample application, X-Ray, using the Internet Explorer 5 XML parser. The X-Ray sample is a Microsoft Visual Basic? version 6.0 application that demonstrates some of the core features of the Internet Explorer 5 XML component.

Teach Yourself XML in Five Minutes
In this section, I'll outline some of the essential concepts of XML and relate them with the DOM, or Document Object Model, which is the basis of the Internet Explorer 5 XML interface. If you are hungry for details about XML, visit http://msdn.microsoft.com/xml/.

Unlike HTML, which uses Markup Language to describe the structure of a document and implies layout, XML markup describes a document's content. Consider the following product description in HTML:

<H1>KomputerSource's Wizbang 3000 dot matrix printer</H1>
<LI>40 pages per minute
<LI>60 dpi printing
<P>10 lbs.

The same product description in XML might look like this:

<?xml version="1.0"?>
      <TYPE>dot matrix</TYPE>
      <SPEED Units="ppm">40</SPEED>
      <QUALITY Units="dpi">60</QUALITY>
   <PRICE Units="USD">
      <WEIGHT Units="lbs">10</WEIGHT>

The XML markup tells nothing about how the XML will be formatted, but it richly describes the contents of the document, both through explicit descriptions (the tag names and attributes) and through implicit structure (how the tags are nested within one another). Because XML separates information from its end use, any system that can read an XML document can extract relevant content.

A bit about the XML structure in this example: the <PRODUCT> is a child of the <MANUFACTURER>. This would be a reasonable structure if you are a manufacturer and have many products in your XML catalog. If, instead, you are a wholesaler and have many products from many manufacturers, you might have <PRODUCT> be the parent of <MANUFACTURER>. The beauty of XML is that you can define different data views with different XML structures based on the needs of the data consumers. As my company worked to define an XML schema for our product catalog, we realized that we had two different types of consumers. Rather than attempting to force-fit the two data requirements into a single schema, we decided to publish two catalogs. Because the Internet Explorer 5 XML component will do the heavy lifting of creating the .xml file, publishing two catalogs will not require twice the effort.

The good news is that XML is a standard. If your information is encoded into a well-formed XML document, any XML-enabled system can scan and repurpose the information in your document. The contents may be formatted for people to read, translated into database tables, or converted into a different XML structure. In the XML example just shown, a wholesaler could easily read the products from a <MANUFACTURER>-centric XML structure and rearrange that manufacturer's tags and data to fit into a <PRODUCT>-centric structure. In fact, the next section of this article will show you the code to do this. The tags and structure allow for automated processing: U.S. dollars may be converted to euros, keyword searches can be made more intelligent, and many XML-tagged products can be sorted by any combination of criteria, such as price, speed, quality, and so on.

Another extremely useful feature that is built into XML is the idea that documents contain information about themselves?metadata. If the tags and attributes are well-designed, both people and computers can read and use the information contained in the XML document. Document Type Definitions, or DTDs, formally declare the type of document an .xml file represents. DTDs describe explicitly the elements that may be allowed, in what quantity and sequence, in that DTD's XML document type. Specifically, a DTD defines such things as the valid tag names and attribute names, which fields are optional, which are required, and which may occur multiple times in the document. In a vertical marketplace, companies may define a common DTD to describe products, processes, customers, and so on. Once standard DTDs are established, data consumers will be able to rely on a specific document structure. There won't need to be such an emphasis on translating .xml files from one company's schema to another's.

An .xml file may include its DTD in the file or link to an external .dtd file. XML does not require that all files have a DTD, but all .xml files must be well-formed.

A DTD for the preceding XML example might include the following content model for the PRODUCT element:


Translated, this means that a PRODUCT element must contain a CLASS, NAME, FEATURES, PRICE, and WEIGHT. For more information about DTD syntax, visit http://msdn.microsoft.com/xml/.

If two or more users decide to share a common DTD, the XML documents they produce will be completely interchangeable because the documents share a common structure. For example, if Company A manufactures computers and Company B makes printers, and if they both use the same DTD to describe their products, a third company, Company C, could receive XML product catalogs from both companies and could easily combine the product lines into a single catalog. Updating this catalog would be a piece of cake, too.

u can have a look yourself in the MSDN. just search for XML.
what is your question? one quick thing to note when you are developing dll's for asp you can not specify data types in your parameters... they have to all be variant because vbscript does not allow type casting.
IlaloveAuthor Commented:
I am interested in having at least a scheleton of code that manages the above scenario.
Thanx for your kind attention.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.