Yes, very much. As I recall, a single DOM handled all web pages; a class of objects containing collections of headings, buttons, fields, etc. For any particular page, a bit of inspection of the collection’s attributes might be required to orient/validate the composition, but, save for major changes, the object could be programmatically manipulated. But I may have forgotten everything; I’ll look into your .dll approach. Thanks very much.
> On Aug 26, 2019, at 7:08 PM, Raul Miller <rauldmil...@gmail.com> wrote: > > On Mon, Aug 26, 2019 at 6:27 PM 'Jim Russell' via Programming > <programm...@jsoftware.com> 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
