Recent

Author Topic: Tlist of tstrings with name values question.  (Read 7569 times)

wpflum

  • Sr. Member
  • ****
  • Posts: 287
Tlist of tstrings with name values question.
« on: March 17, 2011, 03:27:27 pm »
I'm working on a bit of code to convert an xml file to a dataset and then write it out to a flat file for import into another program.  Right now I can go through the xml file and get the nodes and attributes and store them into tstringlists as a name/value pair.  What I was wondering is there a way to store a group of tstringlists in a tlist, or something else, that I can do a name/value pair on them??  Here's why I'd like to do this, lets say I have an xml file with a hierarchy like this:

order

order,component

order,component,unit
order,component,unit,accessory
order,component,unit,accessory,attribute
order,component,unit,accessory
order,component,unit,accessory,attribute

order,component,unit
order,component,unit,accessory
order,component,unit,accessory,attribute
order,component,unit,accessory
order,component,unit,accessory,attribute
 
order,component
order,component,unit
order,component,unit,accessory
order,component,unit,accessory,attribute
order,component,unit,accessory,attribute

Basically I have an order with 2 components, one component has 2 units each with an accessory with attributes and the other component has one unit with an accessory and attributes.

What I'd like to do is create a generic tlist then drill down the xml file to the bottom of each component and make a tstringlist of accessories attributres then back up and add each accessory tstringlist to a tlist for the unit it is in and back up and add each unit tlist to a component tlist and then back up and add the coponent tlist to the order tlist.  To further complicate things each tlist could have a tstringlist in it also so I could have a unit tstringlist with attributes included with the tlist of accessories.

Can I pair the tlist values with names like in a tstringlist??  I'd love to when I add the accessories tstringlist to a unit tlist pair it with the word accessory so I can access it using the word, same with units under component and so on.  The main reason I'd like to do something like this is that I will be writing modules for several different xml formats that, while similar in nature, will not have the same names for each different sections.  If I could make a generic routine to fill a tlist of tlists of tstringlists and associate each item with a name it would be easier to handle rather than an individual routine per xml format.  All I'd have to do is ad a small subset of routines per each format to let it match the headings/names of the tlists.

Any ideas??

garlar27

  • Hero Member
  • *****
  • Posts: 652
Re: Tlist of tstrings with name values question.
« Reply #1 on: March 17, 2011, 05:37:30 pm »
I'd better would implement a class to manage this kind of xml:

   1- You create your  ... "TXML_Something_Manager" (to give it a name).
   2- Then you can configure the node names it will use (since I understand that the files will have the same structure but with different TagNames and AttributeNames).
   3- You can set tables to use and any other things.
   4- There you have it. Ready to be used.


I don't like what you want to do, but here are my suggestions if you will do it that way:

   o- The TStringList has a property named Objects. maybe you can add your SubStringList there... although I don't recommend it.
   o- Manage a hierarchical pointer list (something between a pile, a stack and a binary tree).

eny

  • Hero Member
  • *****
  • Posts: 1646
Re: Tlist of tstrings with name values question.
« Reply #2 on: March 17, 2011, 05:53:39 pm »
If your only target is to translate the xml to another format, don't bother with creating all sorts of data structures. The only structure that is relevant is your output format.
Why not simply load the xml, traverse the nodes and write the output accordingly?

It's not possible to write a '1-procedure-fits-all' method to handle all different kinds of xml.
Any new xml structure requires a different way of functionally processing the data.
FPC already has all the functions you need for technically handling the xml.

On a sidenote:
   o- Manage a hierarchical pointer list (something between a pile, a stack and a binary tree).
I wonder what datastructure lies beneath a TXMLDocument ::)
All posts based on: Win10 (Win64); Lazarus 3_4  (x64) 25-05-2024 (unless specified otherwise...)

wpflum

  • Sr. Member
  • ****
  • Posts: 287
Re: Tlist of tstrings with name values question.
« Reply #3 on: March 17, 2011, 07:37:47 pm »
If your only target is to translate the xml to another format, don't bother with creating all sorts of data structures. The only structure that is relevant is your output format.
Why not simply load the xml, traverse the nodes and write the output accordingly?

It's not possible to write a '1-procedure-fits-all' method to handle all different kinds of xml.
Any new xml structure requires a different way of functionally processing the data.
FPC already has all the functions you need for technically handling the xml.

On a sidenote:
   o- Manage a hierarchical pointer list (something between a pile, a stack and a binary tree).
I wonder what datastructure lies beneath a TXMLDocument ::)

I just thought it would make things easier for similar style xml docs in the future and for this xml right now it seems a good fit if I could make something work.  It's not 'quite' a straight translate to another doc, I'm going to need to build and infer data from the existing stuff and since I know I'll be needing something slightly different for the next one I'd like to build a subsystem that could handle this kind of xml format and give me a standard output to work with.  Maybe I can write a class that can handle a tstringlist in a tstringlist and so on and so on  :-\

I can handle the different header and subheader names after I get them into a better format.

garlar27

  • Hero Member
  • *****
  • Posts: 652
Re: Tlist of tstrings with name values question.
« Reply #4 on: March 18, 2011, 04:54:44 pm »
It's not possible to write a '1-procedure-fits-all' method to handle all different kinds of xml.
Any new xml structure requires a different way of functionally processing the data.
FPC already has all the functions you need for technically handling the xml.

 :-[ :-[ :-[ I FORGOT THAT!!!

Each TAG is essentially an object. And it's TagName represents it's class.

For instance:
Code: XML  [Select][+][-]
  1. <TButton Name="Button1" Caption="Button1" Enabled="True">
  2.    <OnClick>...</OnClick>
  3. </TButton>
  4.  

And
Code: XML  [Select][+][-]
  1. <TForm Name="Form1" Caption="Form1" Enabled="True">
  2.    <OnClick>...</OnClick>
  3. </TForm>
  4.  

Are "textually" the same except for its TagName but the fact is that they are VERY different. Those elements represent different things of the real world and THEY HAVE A DIFFERENT BEHAVIOR so you need to handle them by different ways.


Let's see something more ... "complicated"

You have clients, employees, and providers.
It's obvious that they share a similar data structure but they play different roles in your system.
If you want to keep the same process to handle their data then you will need to be aware of their roles and this is something that needs more design time (on papers) before coding. so be aware of that.



I'm not a good english speaker so maybe I can't understand well what you are trying to do but: I wouldn't do what you are trying to do.

 

TinyPortal © 2005-2018