wbDOMData Extender(Beta 2/3)

[JTaylor]

I believe I have the JSON and XML portions of the Extender fairly settled.   Now is the time to say if you think any of the function names are misleading or the terminology incorrect.   Open to changing them for a very short time but needs to be VERY soon.

I completely reworked the XML stuff.   Didn't realize how bad it was until I went to use it in the real world.   The trees seemed okay but the Forest was really ugly when I stepped back.  The downside of the change is that it dropped the size of XML one can parse to around 100mb (mileage will vary based on system configuration, I am sure).   If you have used the JSON stuff you will notice the similarities in how I am handling the Paths.

Also, does anyone believe it to be critical to be able to parse more than one document at a time?   That is, have more than one document active at a time.    Again, something that will be hard to change later as it would be a breaking change to every function.

      http://www.jtdata.com/anonymous/DomData.zip

Jim

[bottomleypotts]

Hey Jim,

Thank you for this!

One request. For arrays can get counts. This would be helpful in the treepath/nodepath. In your documentation the dmjGetTree example there is a subject. Having the subject.length appear in the treepath would be helpful!

Hope that makes sense.

[stanl]

Hey Jim,

Thank you for this!

One request. For arrays can get counts.

I think Jim addressed counts in a previous post I made. Any map can be addressed with Arrinfo,map,1 ... but you may have a point although subject.length might assume the Extender returns objects. [and that was only his example]

[JTaylor]

Just to clarify and build on what Stan said..

If you did something like

          sub_arr =  dmjGetValue("/subjects")

you could get the length/count by doing

          cnt = ArrInfo(sub_arr,1)

Is this what you need or do you want that info in the dmjTreePath() return data?


Jim

Hey Jim,

Thank you for this!

One request. For arrays can get counts. This would be helpful in the treepath/nodepath. In your documentation the dmjGetTree example there is a subject. Having the subject.length appear in the treepath would be helpful!

Hope that makes sense.

[JTaylor]

I just posted the latest after integrating the XML part into an app I distribute.  This resulted in a number of tweaks to the Extender and a few more Functions.   Mileage will vary but my experience was that is was very comparable to MSXML.  Somethings I liked better.  Some maybe less so but overall very comparable.   No real savings in amount of code.

JSON numbers (doubles and integers) will now return as strings to avoid rounding and other undesirable number behavior.   This lessens the usefulness of the dmjGetType() function I added but one can test on the WinBatch side if needed.

I added an dmjIsData() function so one can test an element to see if it is an object/array or contains a value.  This is easier than getting a type or checking for children/value.  It returns a @TRUE/@FALSE as expected.


      http://www.jtdata.com/anonymous/DomData.zip

I think I am done for they day  :)

Jim

[jmburton2001]

Also, does anyone believe it to be critical to be able to parse more than one document at a time?   That is, have more than one document active at a time.

My two cents...

For me personally, I don't ever foresee the need to work on more than one XML file at a time. My coding style lends itself to compartmentalizing steps. If I need to work with more than one XML I'd most likely extract from them separately and then manipulate the outputs with standard Winbatch functions.

[JTaylor]

Thanks.   I started to add it but then couldn't think of a single time I have ever done that so decided to skip it, unless someone makes a compelling case for it, as it adds one more level of complexity.   

Also, I just realized I didn't provide a way to simply search for a NodeName in the XML stuff.   Probably not as critical as for HTML but would still be useful.

In other news, I have finally settled on an HTML solution and have a good start on that.   As with many things on this project, I wasted a lot of time when the answer was staring me in the face the whole time.

Also, I intend to fold the Sundry Extender into this project.   One less thing to keep track of and some of the functions are applicable to this one anyway.  At least for my purposes.

Jim

Also, does anyone believe it to be critical to be able to parse more than one document at a time?   That is, have more than one document active at a time.

My two cents...

For me personally, I don't ever foresee the need to work on more than one XML file at a time. My coding style lends itself to compartmentalizing steps. If I need to work with more than one XML I'd most likely extract from them separately and then manipulate the outputs with standard Winbatch functions.

[bottomleypotts]

Thanks Jim and Stan. This addresses my needs perfectly! Thank you again for this extender Jim.

Just to clarify and build on what Stan said..