Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2017-09

Why Laz2_DOM, laz2_XMLRead, and laz2_XMLWrite?

8 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marcos Douglas B. Santos

Hi,

Nowadays we have Unicode and so on.

Is there any reason to these units (Laz2_DOM, laz2_XMLRead, and laz2_XMLWrite) still exists?

I've always used them, but days ago I needed to use XPath and the xpath unit works using objects from DOM unit, not laz2_DOM, and because that my doubt.

Best regards,
Marcos Douglas

Reply by email

Michael Van Canneyt
to Marcos Douglas B. Santos
Marcos Douglas B. Santos wrote 10 lines
Hi, Nowadays we have Unicode and so on. Is there any reason to these units (Laz2_DOM, laz2_XMLRead, and laz2_XMLWrite) still exists? I've always used them, but days ago I needed to use XPath and the xpath unit works using objects from DOM unit, not laz2_DOM, and because that my doubt.

These units work using UTF8. The DOM units use UnicodeString (UTF16).

Given that these units are quite stable in terms of functionality and maturity, it may be a good idea to move them to the FCL.

Michael.

Reply by email

Marcos Douglas B. Santos
to Michael Van Canneyt
Michael Van Canneyt wrote 5 lines
These units work using UTF8. The DOM units use UnicodeString (UTF16). Given that these units are quite stable in terms of functionality and maturity, it may be a good idea to move them to the FCL.

Yes, that is my point.
But instead of just moving them, shouldn't they merge as well into a single unit, ie, only one DOM, XMLRead, and XMLWrite unit?

Best regards,
Marcos Douglas

Reply by email

Michael Van Canneyt
to Marcos Douglas B. Santos
Marcos Douglas B. Santos wrote 11 lines
On Wed, Sep 20, 2017 at 12:36 PM, Michael Van Canneyt via Lazarus wrote: > > These units work using UTF8. The DOM units use UnicodeString (UTF16). > > Given that these units are quite stable in terms of functionality and > maturity, it may be a good idea to move them to the FCL. Yes, that is my point. But instead of just moving them, shouldn't they merge as well into a single unit, ie, only one DOM, XMLRead, and XMLWrite unit?

I don't think so, because how will you make the difference between the 2 ? And it's not possible to have optimal code for both cases in 1 set of classes; The idea is that there are no conversions necessary.

Michael.

Reply by email

Marcos Douglas B. Santos
to Michael Van Canneyt
Michael Van Canneyt wrote 22 lines
On Wed, 20 Sep 2017, Marcos Douglas B. Santos via Lazarus wrote: > On Wed, Sep 20, 2017 at 12:36 PM, Michael Van Canneyt via Lazarus > wrote: >> >> >> These units work using UTF8. The DOM units use UnicodeString (UTF16). >> >> Given that these units are quite stable in terms of functionality and >> maturity, it may be a good idea to move them to the FCL. > > > Yes, that is my point. > But instead of just moving them, shouldn't they merge as well into a > single unit, ie, only one DOM, XMLRead, and XMLWrite unit? I don't think so, because how will you make the difference between the 2 ? And it's not possible to have optimal code for both cases in 1 set of classes; The idea is that there are no conversions necessary.

And we will continue having two base code to do the same thing? Don't you think this is confusing for the users?

What about having just one code but setting the type of string (XMLString) to use? (even having Unicode... God)

How can I use XPath with laz2_* units then?

Regards,
Marcos Douglas

Reply by email

Michael Van Canneyt
to Marcos Douglas B. Santos
Marcos Douglas B. Santos wrote 30 lines
On Wed, Sep 20, 2017 at 3:02 PM, Michael Van Canneyt via Lazarus wrote: > > > On Wed, 20 Sep 2017, Marcos Douglas B. Santos via Lazarus wrote: > >> On Wed, Sep 20, 2017 at 12:36 PM, Michael Van Canneyt via Lazarus >> wrote: >>> >>> >>> These units work using UTF8. The DOM units use UnicodeString (UTF16). >>> >>> Given that these units are quite stable in terms of functionality and >>> maturity, it may be a good idea to move them to the FCL. >> >> >> Yes, that is my point. >> But instead of just moving them, shouldn't they merge as well into a >> single unit, ie, only one DOM, XMLRead, and XMLWrite unit? > > > I don't think so, because how will you make the difference between the 2 ? > And it's not possible to have optimal code for both cases in 1 set of > classes; The idea is that there are no conversions necessary. And we will continue having two base code to do the same thing? Don't you think this is confusing for the users? What about having just one code but setting the type of string (XMLString) to use? (even having Unicode... God)

This is an option, but you'll still have 2 sets of units.

How can I use XPath with laz2_* units then?

Currently not, I think.
All the more reason to move everything to FCL in a unified codebase.

Or use your suggestion and use something like

Type
{$IFDEF XMLUTF8}
  XMLString = UTF8String;
{$ELSE}
  XMLString = unicodestring;
{$ENDIF}

should do the job. I will have a look at this; the only thing that must then be properly checked is the actual reading and writing...

Michael.

Reply by email

Mattias Gaertner
to Michael Van Canneyt
[...] Currently not, I think. All the more reason to move everything to FCL in a unified codebase.

+1

Show quoted text 11 lines
Or use your suggestion and use something like Type {$IFDEF XMLUTF8} XMLString = UTF8String; {$ELSE} XMLString = unicodestring; {$ENDIF} should do the job. I will have a look at this; the only thing that must then be properly checked is the actual reading and writing...

The laz2_dom has some options for keeping the spaces (indentation). Don't know if this was already backported to the original xmlreader/writer.

Mattias

Reply by email

Torsten Bonde Christiansen
to Mattias Gaertner
Mattias Gaertner wrote 24 lines
On Wed, 20 Sep 2017 20:38:23 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: > [...] > Currently not, I think. > All the more reason to move everything to FCL in a unified codebase. +1 > Or use your suggestion and use something like > > Type > {$IFDEF XMLUTF8} > XMLString = UTF8String; > {$ELSE} > XMLString = unicodestring; > {$ENDIF} > > should do the job. I will have a look at this; the only thing that must > then be properly checked is the actual reading and writing... The laz2_dom has some options for keeping the spaces (indentation). Don't know if this was already backported to the original xmlreader/writer. Mattias

Please, please consider the fact that the FCL counterpart require (or at least used to) a widestring manager! This was not the case with Laz2_DOM, etc... and hence the sole reason why we a using these units and not the FCL ones!

Just my 2 cents....

Kind regards,
Torsten.

Reply by email