1

Topic: Tree in storage

It is required to hold a tree in storage (like a tree of files or classes in any IDE) the Tree boots from xml a file and in it is saved. Also with it from the program certain manipulations, like adding, removal and renaming of nodes, change of their attributes can be led. A question - and in what it is better to hold a tree? If to hold actually in xml the document - that pluses in that that like as all from a box (xml the library gives a dial-up of classes), at saving xml-comments and  tags/attributes, but access are not lost more slowly, and the code directly in classes of nodes of a tree not to place. If to write a tree most - that like this decision it is more ground for a specific target, accordingly access to attributes not in  type xmlnode-> getAttribute ("name") and directly node-> name; the code of loading from xml and savings in xml is required; Also at saving xml the file is recycled completely from zero, that is in it comments and non-standard tags/attributes (whether I do not know it is required such but suddenly) are lost for example. While it is not clear in what all pours out in the project further, but the decision is good for accepting now. Probably there are any pluses and minuses about which I yet do not know.

2

Re: Tree in storage

Hello, x-code, you wrote: XC> While it is not clear in what all pours out in the project further, but the decision is good for accepting now. Probably there are any pluses and minuses about which I yet do not know. When something is required more xmlNode-> setAttribute, passage will be painfully sick. The parcer should be able to get all these , comments and other so in the representation they can be saved. And it is possible and to cross pluses and minuses of both approaches and to make  around xml a tree.

3

Re: Tree in storage

Hello, x-code, you wrote: XC> It is required to hold a tree in storage (like a tree of files or classes any IDE) At first to understand, whether the tree in storages or its visual representation is required. A tree of files or classes in any IDE are visual representations. XC> the tree boots from xml a file and in it is saved. Also with it from the program certain manipulations, like adding, removal and renaming of nodes, change of their attributes can be led. XC> a question - and in what it is better to hold a tree? In any normal objective-orientirovanno written how many  difficult application application and so there are hierarchically bound objects, than not a tree. Probably what that of these classes a dale;  to have methods of reading-record XML together with . XC> If to hold actually in xml the document - that pluses in that that like as all from a box (xml library gives a dial-up of classes), at saving xml-comments and  tags/attributes, but access are not lost more slowly, and the code directly in classes of nodes of a tree not to place. It is not necessary so to do. When appeared XML by naivety tried to screw hierarchy just the classes intended for a configuration over XML DOM but the decision turns out recomplicated and unduly heavy. XC> if to write a tree most - that like this decision it is more ground for a specific target, accordingly access to attributes not in  type xmlnode->> getAttribute ("name") and directly node-> name; the code of loading from xml and savings in xml is required; also at saving xml the file is recycled completely from zero, that is in it comments and non-standard tags/attributes (whether I do not know it is required such but suddenly) are lost for example. What language? If the tree in storage in normal languages is necessary there are ready template classes, the tree is implemented by pair lines. If the visual tree besides everywhere there are implementations is necessary. Further to select under the requirements (on the speed, occupied storage, etc.). Storage in XML is implemented with what help  a parcer and it DOM, but this tree XML should form only at the moment of reading - configuration records, the classes  to read-write there the information, and only at the moment of loading / savings. Also in many languages there is the automatic serialization, adjusted is declarative. It normally suffices for simple cases. XC> while it is not clear in what all pours out in the project further, but the decision is good for accepting now. Probably there are any pluses and minuses about which I yet do not know.

4

Re: Tree in storage

Hello, swame, you wrote: S> At first to understand, whether the tree in storages or its visual representation is required. S> a tree of files or classes in any IDE are visual representations. It is necessary both visual representation, and a tree in storage. It will be clear that on visual representation to be displayed not all that is in storage. S> what language? A C ++/Qt

5

Re: Tree in storage

Hello, x-code, you wrote: XC> Hello, swame, you wrote: S>> At first to understand, whether the tree in storages or its visual representation is required. S>> a tree of files or classes in any IDE are visual representations. XC> it is necessary both visual representation, and a tree in storage. It will be clear that on visual representation to be displayed not all that is in storage. S>> what language? XC> the C ++/Qt Need to be decided that there is a model in the program: the xml-document or the abstract tree, and the xml-document it only the data carrier. That that approaches and is sampled. The variant combining both approaches is possible.

6

Re: Tree in storage

Hello, Qulac, you wrote: Q> It is necessary to decide that there is a model in the program: the xml-document or the abstract tree, and the xml-document it only the data carrier. That that approaches and is sampled. The variant combining both approaches is possible. The abstract tree. xml it only a storage method. It would be possible json to select or something else, without a difference.

7

Re: Tree in storage

Hello, x-code, you wrote: Q>> It is necessary to decide that there is a model in the program: the xml-document or the abstract tree, and the xml-document it only the data carrier. That that approaches and is sampled. The variant combining both approaches is possible. XC> the abstract tree. xml it only a storage method. It would be possible json to select or something else, without a difference. Too it agree. The abstract tree, XML it only a method of serialization and only is better. XML should not be a tree part at all. Now serialization in XML, tomorrow in JSON, then in a binary format, then in a database is necessary to us... And all in one dustbin will be added. That a kitchen garden to fence!?! It is a separate functional. And the tree becomes on a knee for five minutes. And the main thing it will be quite abstract - that a tree. \\\, in general typical CRUD. And all. And as it serializuetsja\deseriializuetsja is a separate part.