Refactor TXMLComponent to act as a proxy for XML handling in both Delphi and FPC

[nunopicado]

The idea is to reduce conditional compilation when using it

[mdbs99]

What do you think about this #10 approach?

[nunopicado]

Could be done, and would provide an abstraction for XML and other formats. We would need to address the compatibility issues just the same, but the end result would have a broader spec of usage. That however is a conceivable longer task, and waiting for it to be done would probably delay the Delphi compatibilization to be on par with the main branch, which will only get larger as new interfaces and classes are developed and added to the James framework. Shoud we keep waiting or advance issue #50 with what we have now?

[mdbs99]

Could be done, and would provide an abstraction for XML and other formats.

That is a goal too.

We would need to address the compatibility issues just the same, but the end result would have a broader spec of usage.

Yes, but we can start just with XML for now — I use much more XML than other formats like JSON. What about to you?

That however is a conceivable longer task, and waiting for it to be done would probably delay the Delphi compatibilization to be on par with the main branch, which will only get larger as new interfaces and classes are developed and added to the James framework.

But your issue is proposing to make this compatibility happen... Do you have another simpler approach?

[nunopicado]

Yes, but we can start just with XML for now — I use much more XML than other formats like JSON. What about to you?

Me too.

But your issue is proposing to make this compatibility happen... Do you have another simpler approach?

10 should definitely go forward, and replace TXMLComponent as soon as ready.

But I wonder if we could have a temporary solution that would allow us to have compatibility sooner. Even though it might represent an extra work now, and one that will possibly be ditched when #10 is done, it might avoid extra work in the future, because as you know, any object implemented on any one platform is possible due to refactoring to make it compatible on the other. So it makes sense that we try to have new object developing in both platforms simultaneously. But for that to happen, #50 must be done as well.

[mdbs99]

Well, I would like to have compatibility with Delphi as soon as possible. Because that I've pointed the #10 ticket as a possible solution. We wouldn't implement all XML features from these frameworks but, instead, only which is necessary for our tests to work in both plataforms.

For now I can see that we just need:

• Find Nodes
• Get Child Nodes as a list
• Move forward, deeply (child node) and backward.

Creating some decorator or something to solve #5 is a goal too.

However, tell me about your ideas.

[nunopicado]

Don't really have any, at this point. So you propose to make #10 as a XML parser to start with, and then move forward from there. We certainly could try it.

[mdbs99]

Ok. I'll code some draft of Interfaces and Classes to FPC first.

[nunopicado]

OK. As soon as you have it, I'll try them in Delphi and see how it goes.

[mdbs99]

Actually, I've created another project to handle this problem. Please, take a look https://github.com/mdbs99/xavier I did this code in just a few hours. It is not completed yet, but the basics are already working.

I will do more tests and then replace TXMLComponent and all stuff about XML from James.