On Mon, Aug 26, 2019 at 6:27 PM 'Jim Russell' via Programming <[email protected]> wrote: > I think the VBA and Java document object model are similar, if not > the same. With it, a program can access a web page and all of its > attributes (get text, change fields, click buttons, etc.) > as an object, rather than resorting to screen scraping. I would > assume that a J implementation would access the page hierarchy using > the j-unique approach of locale class names and __numeric__ objects.
Well, first off: conceptually, if there's a windows dll that offers what you want, you can use it from within J: https://www.jsoftware.com/help/user/call_procedure.htm So, for example, you could use Windows.Data.Xml.Dom.dll from inside J, if that suited your needs. That said, creating a J object to shadow each object in a DOM system would run into a whole batch of memory management and synchronization glitches. There's at least two different (conflicting) memory management philosophies already in the windows DOM implementations, and adding J objects would introduce a third. This could be done, but it would be slow and it would require a deep understanding of all three systems in some contexts. Personally, I would avoid that. But, it could make sense to create one top-level J class to represent the DOM interface, with an instance for each DOM document you were working with. This would isolate the use of that interface from the rest of the system. Here, you'd probably be working with numeric representations of objects -- they would just be external DOM objects and not native J objects. (You would still have to deal with some of those memory management issues, but hopefully the direct use of the interface will take some of the mystery out of them.) I hope this helps, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
