Arising out of this I am wondering if there is some existing way for an XMLNode to customise its printString based on the application's custom tags ?

I am looking into an importer for VisualWorks Parcels (btw, has��anyone done this already?).�� In this case the GT-InspectorExtensions-XML��[Tree] tab is not ideal since the tree-items only show the element tag but no identifying name (see XMLScreenShot.png). XMLElement>>gtDisplayOn: shows attributes, so ideally there would be an identifying attribute like "name", but with Parcels the "name" is a sub-element rather than an attribute.

My own first pass GT extension...

�� �� XMLNodeWithChildren>>gtInspectorNodesIn: composite
�� �� �� �� ��<gtInspectorPresentationOrder: 5>
�� �� �� �� ��composite list
�� �� �� �� �� �� ����title: 'Nodes';
�� �� �� �� �� �� �� display: [ self nodes ] ;
�� �� �� �� �� �� �� �� �� �� ��format: [ :each | each printString lineNumber: 1 ].

...got around this by displaying the whole first line (see XMLScreenShot2.png) -- but I realise now this works sort of by accident, just for this particular case.�� Other cases might not have significant info on the first line.

What I'd really like to be able to do is customise the XMLNode #printString to my application's XML tags.�� The approach I forsee is the application adds extension methods to XMLNode and friends (e.g. XMLNode>>myPrintOn:) that are called from a new class MyNodePrinter. ����Then you do something like...

�� ����xmlDoc := XMLDOMParser parseFileNamed: 'PDFDevelopment.pst' .
�� �� xmlDoc setNodePrinter: MyNodePrinter new.

Alternatively the extension method could be referenced directly...

�� ����xmlDoc := XMLDOMParser parseFileNamed: 'PDFDevelopment.pst' .
�� �� xmlDoc nodePrinterMethod: #myPrintOn:

In either case, this could be stored either:

1. In the document root such that each XMLNode needs follow the parent chain back to the document root to determine how to be printed.

2. An instance variable in XMLNode such that #setNodePrinter: descends the tree copying theMyNodePrinter into each node.

So, is this way off base? ��Would it be useful? ����Could it be made workable? ����

cheers -ben







On Mon, Apr 27, 2015 at 3:19 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,

There already exists a GT-InspectorExtensions-XML which is already published in the GT repository.

I would prefer to qualify the extensions by the tool they refer to: GT-InspectorExtnesions-*, GT-SpotterExtensions-* etc.

gtDisplayOn: should be more in the inspector, but probably some were added mostly in the spotter so they ended up in the less optimal package.

Cheers,
Doru



On Sun, Apr 26, 2015 at 8:30 PM, Ben Coman <btc@openinworld.com> wrote:
I happened to need to use and XML Parser for the first time and found inspecting the structure awkward, so I added some GTInspector extensions to XML-Parser. This is uploaded as XML-Parser-BenComan.304 to��http://smalltalkhub.com/#!/~PharoExtras/XMLParser.�� Could someone who uses XML regularly check if these are reasonable?

Now should these methods be packaged separately somehow, since they are likely not of interest to other Smalltalk flavours? ����

btw I gave them a protocol of "GT-Extensions" - but I also considered "moldable-tools" and "tools-extensions".�� If there a preference?�� This will likely be a common occurrence across the community, so we should try for a consistent convention across the community for such extensions.

btw2, I notice that #gtDisplayOn: implementors are fairly evenly split between [GT-InspectorExtensions-Core] and [GT-SpotterExtensions-Core].�� Are they really separated like this in their use?

cheers -ben



--

"Every thing has its own flow"