Smalltalk › Pharo › Pharo Smalltalk Users

XMLParser GTInspector extensions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Ben Coman

XMLParser GTInspector extensions

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

Tudor Girba-2

Re: XMLParser GTInspector extensions

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 <[hidden email]> 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

www.tudorgirba.com

"Every thing has its own flow"

Ben Coman

Re: XMLParser GTInspector extensions

On Mon, Apr 27, 2015 at 3:19 AM, Tudor Girba <[hidden email]> wrote:

Hi,

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

Cool. I'll revert my changes. However its not very discoverable that people need to check that repository for any particular application. I even took a few guesses to find the repository Smalltalkhub/Moose/GToolkit. Also, I understand from...

http://pharo.gemtalksystems.com/book/LanguageAndLibraries/XML/XML-support-in-Pharo/
that there are different XML packages, so its not obvious from your package which system it applies to. Though from context here I guess it is XML-Parser, others coming later won't have that context. (I guess a separate GT-InspectorExtensions-* package is needed for each XML system.)

Now when I add some GT extensions to my own package, should I put my GT-InspectorExtensions-MyApplication package in your repository? And can I have write access to maintain it ;) ? It would be good to manage these extensions consistently across the community.

So what do you think of...

* Updating ConfigurationOfXMLParser to automatically load the extensions for Pharo4.

* Moving the package into the XML-Parser repository so it sits next to other compatibility packages like XML-Parser-GemstoneCompatability -- and possibly renaming it something like XML-Parser-GT-Extensions.

I would prefer to qualify the extensions by the tool they refer to: GT-InspectorExtensions-*, 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.

okay. good to understand.

cheers -ben

Cheers,
Doru

On Sun, Apr 26, 2015 at 8:30 PM, Ben Coman <[hidden email]> 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

--
www.tudorgirba.com

"Every thing has its own flow"

Ben Coman

Re: XMLParser GTInspector extensions

In reply to this post by Tudor Girba-2

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 <[hidden email]> 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 <[hidden email]> 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

--
www.tudorgirba.com

"Every thing has its own flow"

XMLScreenShot.png (85K) Download Attachment

XMLScreenShot2.png (247K) Download Attachment

stepharo

Re: XMLParser GTInspector extensions

In reply to this post by Ben Coman

Hi ben

we could update the configurationOfXMLReader.
But the right solution is to define a new configuration loading GT-Tools, XMLReader and your extensions.
In pharo 40 we could consider that GT-Tools is loaded.
Now I think that making the dependencies explicit is important.

So what do you think of...

* Updating ConfigurationOfXMLParser to automatically load the extensions for Pharo4.

* Moving the package into the XML-Parser repository so it sits next to other compatibility packages like XML-Parser-GemstoneCompatability -- and possibly renaming it something like XML-Parser-GT-Extensions.

The package I maintain with monty is in PharoExtras so I would prefer not to change its location.

Stef

I would prefer to qualify the extensions by the tool they refer to: GT-InspectorExtensions-*, 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.

okay. good to understand.

cheers -ben

Cheers,

Doru

On Sun, Apr 26, 2015 at 8:30 PM, Ben Coman <[hidden email]> 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

--

www.tudorgirba.com

"Every thing has its own flow"

Ben Coman

Re: XMLParser GTInspector extensions

On Sun, May 3, 2015 at 4:28 AM, stepharo <[hidden email]> wrote:

Hi ben

we could update the configurationOfXMLReader.
But the right solution is to define a new configuration loading GT-Tools, XMLReader and your extensions.
In pharo 40 we could consider that GT-Tools is loaded.
Now I think that making the dependencies explicit is important.

So what do you think of...

* Updating ConfigurationOfXMLParser to automatically load the extensions for Pharo4.

* Moving the package into the XML-Parser repository so it sits next to other compatibility packages like XML-Parser-GemstoneCompatability -- and possibly renaming it something like XML-Parser-GT-Extensions.

The package I maintain with monty is in PharoExtras so I would prefer not to change its location.

I meant moving GT-InspectorExtensions-XML..mcz from Smalltalkhub Moose/GToolkit
to Smalltalkhub PharoExtras/XMLParser renamed XML-Parser-GTExtensions..mcz ,

but that might not suit the GT Team.

Actually in off-list correspondence with monty I learnt of XMLPluggableElementFactory, which seems to suit my need better than my proposed GT extensions for XMLParser.

cheers -ben

Stef

I would prefer to qualify the extensions by the tool they refer to: GT-InspectorExtensions-*, 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.

okay. good to understand.

cheers -ben

Cheers,

Doru

On Sun, Apr 26, 2015 at 8:30 PM, Ben Coman <[hidden email]> 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

--

www.tudorgirba.com

"Every thing has its own flow"

Tudor Girba-2

Re: XMLParser GTInspector extensions

Hi,

Sorry for the slow reaction.

Indeed, we would like to encourage the packaging of GT extensions in the same project as the code they extend. So, in this case, GT-InspectorExtensions-XML would be better suited to be in the PharoExtras/XMLParser repository under XML-Parser-GT-InspectorExtensions.

Actually, given that most of these extensions are not more complicated than a printOn:, I would even argue that in many cases it would be more suitable to have them in the same package as the class they extend. I know it sounds like bad dependency management, but the GT-Inspector is here to stay (and the API will likely remain compatible in the future), so the risk is minimal and I think in many situations you will this approach more pragmatic.

So, Ben: could you push the package as you described (only call it please XML-Parser-GT-InspectorExtensions)?

Cheers,

Doru

On Sun, May 3, 2015 at 4:30 PM, Ben Coman <[hidden email]> wrote:

On Sun, May 3, 2015 at 4:28 AM, stepharo <[hidden email]> wrote:

Hi ben

we could update the configurationOfXMLReader.
But the right solution is to define a new configuration loading GT-Tools, XMLReader and your extensions.
In pharo 40 we could consider that GT-Tools is loaded.
Now I think that making the dependencies explicit is important.

So what do you think of...

* Updating ConfigurationOfXMLParser to automatically load the extensions for Pharo4.

* Moving the package into the XML-Parser repository so it sits next to other compatibility packages like XML-Parser-GemstoneCompatability -- and possibly renaming it something like XML-Parser-GT-Extensions.

The package I maintain with monty is in PharoExtras so I would prefer not to change its location.

I meant moving GT-InspectorExtensions-XML..mcz from Smalltalkhub Moose/GToolkit
to Smalltalkhub PharoExtras/XMLParser renamed XML-Parser-GTExtensions..mcz ,
but that might not suit the GT Team.

Actually in off-list correspondence with monty I learnt of XMLPluggableElementFactory, which seems to suit my need better than my proposed GT extensions for XMLParser.
cheers -ben

Stef

I would prefer to qualify the extensions by the tool they refer to: GT-InspectorExtensions-*, 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.

okay. good to understand.

cheers -ben

Cheers,

Doru

On Sun, Apr 26, 2015 at 8:30 PM, Ben Coman <[hidden email]> 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

--

www.tudorgirba.com

"Every thing has its own flow"

www.tudorgirba.com

"Every thing has its own flow"

Ben Coman

Re: XMLParser GTInspector extensions

On Mon, May 4, 2015 at 3:18 AM, Tudor Girba <[hidden email]> wrote:

Indeed, we would like to encourage the packaging of GT extensions in the same project as the code they extend. So, in this case, GT-InspectorExtensions-XML would be better suited to be in the PharoExtras/XMLParser repository under XML-Parser-GT-InspectorExtensions.

Actually, given that most of these extensions are not more complicated than a printOn:, I would even argue that in many cases it would be more suitable to have them in the same package as the class they extend. I know it sounds like bad dependency management, but the GT-Inspector is here to stay (and the API will likely remain compatible in the future), so the risk is minimal and I think in many situations you will this approach more pragmatic.

This had crossed my mind. The upside is that #gtDisplay its unlikely to clash with another platform maybe that its easier to load a single package, but the Configuration should handle this anyhow. The downside is that unneccessary methods pollute other platforms. In this case being under PharoExtras maybe thats not so much a worry, but was XMLParser pulled from somewhere that we should be synchronising with?

So, Ben: could you push the package as you described (only call it please XML-Parser-GT-InspectorExtensions)?

Thanks for the go ahead. Will do. Now considering further that that GT-Inspector is here to stay :) perhaps we should go more generic and call the package XML-Parser-PharoCompatibility ?

cheers -ben

On Sun, May 3, 2015 at 4:30 PM, Ben Coman <[hidden email]> wrote:

On Sun, May 3, 2015 at 4:28 AM, stepharo <[hidden email]> wrote:

Hi ben

we could update the configurationOfXMLReader.
But the right solution is to define a new configuration loading GT-Tools, XMLReader and your extensions.
In pharo 40 we could consider that GT-Tools is loaded.
Now I think that making the dependencies explicit is important.

So what do you think of...

* Updating ConfigurationOfXMLParser to automatically load the extensions for Pharo4.

* Moving the package into the XML-Parser repository so it sits next to other compatibility packages like XML-Parser-GemstoneCompatability -- and possibly renaming it something like XML-Parser-GT-Extensions.

The package I maintain with monty is in PharoExtras so I would prefer not to change its location.

I meant moving GT-InspectorExtensions-XML..mcz from Smalltalkhub Moose/GToolkit
to Smalltalkhub PharoExtras/XMLParser renamed XML-Parser-GTExtensions..mcz ,
but that might not suit the GT Team.

Actually in off-list correspondence with monty I learnt of XMLPluggableElementFactory, which seems to suit my need better than my proposed GT extensions for XMLParser.
cheers -ben

On Sun, Apr 26, 2015 at 8:30 PM, Ben Coman <[hidden email]> 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?