Moose-dev November 2010

moose-dev@list.inf.unibe.ch

22 participants
68 discussions

Re: Issue 483 in moose-technology: Have a wizard to import form VerveineJ

by moose-technology＠googlecode.com

Updates: Labels: Component-ExternalTools Milestone-4.2 Comment #2 on issue 483 by tudor.girba: Have a wizard to import form VerveineJ http://code.google.com/p/moose-technology/issues/detail?id=483 That is great. What should we load?

14 years, 6 months

Re: Issue 149 in moose-technology: Reorganize packages

by moose-technology＠googlecode.com

Comment #21 on issue 149 by jannik.laval: Reorganize packages http://code.google.com/p/moose-technology/issues/detail?id=149 We should rename Merlin also

14 years, 6 months

Issue 484 in moose-technology: PetitParser debugger does not show nesting anymore

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-PetitParser Milestone-4.2 New issue 484 by tudor.girba: PetitParser debugger does not show nesting anymore http://code.google.com/p/moose-technology/issues/detail?id=484 PetitParser-lr.206 replaces the usage of def: in CompositeParser to make instantiation faster. However, this change makes the Debugger from the PetitGUI to not show the tree anymore.

14 years, 6 months

The future of Opax in XML-Support

by jaayer

The most recent version of XML-Support comes with a factory-based abstraction layer to customize the node object construction done by the parser. The default factory is just a number of stateless accessors with names like #elementClass and #documentClass that return class objects. This class can be subclassed and those messages overridden, and the subclass can then be instantiated and injected into a DOM parser using #nodeFactory: before parsing. However, also included is a node factory subclass named XMLPluggableElementFactory that can map specific elements to specific element classes based on the name and namespace information of the elements in question. Here is an example of its use: doc := (XMLDOMParser on: aStringOrStream) nodeFactory: (XMLPluggableElementFactory new handleElement: 'user' withClass: MyUserElement; handleElement: 'report' withClass: MyReportElement; handleElement: 'report' namespaceURI: 'urn:specialReport' withClass: MySpecialReportElement); parseDocument. This is undoubtedly similar to Opax, if not in its approach then certainly in its intent. I feel, however, that it is superior to Opax in a number of respects and question whether Opax should remain in XML-Support. First, the node factory abstraction layer is based on the DOM parser and XMLNode classes, not the SAX parser and the custom OP*Element classes Opax has added. This means that users will get back instances of XMLElement subclasses rather than OPGenericElement subclasses, and those objects will support the entire XMLElement protocol. Second, the pluggable element factory enables more powerful element/class mapping based not only on the names of elements but their namespace information as well. Third, the element factory and its test are both quite small, in part because they do not need to duplicate the functionality of XMLElement like OPGenericElement does. Fourth, because the element factory is a subclass of XMLNodeFacory, it can be subclassed further to exert additional control over which classes the DOM parser should use for other, non-element nodes. Fifth and perhaps most important of all, the factory approach does not require a specific subclass of XMLDOMParser to be used; it is injected into a DOM parser by the user, so any DOM parser, even ones that already exist, can use it without modification. To use Opax, however, a parser must be a subclass of OPOpaxHandler, which is itself a subclass of SAXHandler. That means DOM parsers can't be used with Opax at all, and existing SAX parsers can't use it unless they are rewritten to be subclasses of OPOpaxHandler. I think Opax should be taken out and made optionally loadable by the Metacello configuration file. In fact, this should be done regardless of which approach is preferred, as the package is already quite large and stands to get larger as more is added. I plan on making XMLWriter a separate but required package, and the test suites separate but optional packages. If anyone has any objections, I would like to hear them.

14 years, 6 months

Re: Issue 476 in moose-technology: VerveineJ should export some metrics

by moose-technology＠googlecode.com

Updates: Status: Fixed Comment #2 on issue 476 by anquetil.nicolas: VerveineJ should export some metrics http://code.google.com/p/moose-technology/issues/detail?id=476 Cyclomatic complexity and number of statement done for methods. number of line of cade is available for classes and methods through the attached FileAnchor which gives the first and last line of an Entity

14 years, 6 months

Re: The future of Opax in XML-Support

by Stéphane Ducasse

This is why you can get a little explanation beside the acronym Do you prefer Moose or SotwareAnalysisPlatform Glamour or BrowserFlowFramework Pier or SeasideAppllicationCMS Seaside or dynamicWebFramework Citizen or the fuckingLibToParseBibUglyEntries.... Mondrian or theDrawingAPIToOnlyDrawBoxesAndArrows I prefer the first. So let us be a bit clever. Have nice name and explanation. look at VW they have VisualWorks Web Server.... I proposed them to call it Sioux long time ago (because of blackfoot (smart guys), Apache, ....). Stef On Nov 16, 2010, at 3:44 PM, Johan Fabry wrote: > > A name that is not an explanation makes it hard for the user to know what the thing is or does. I have many problems with the Moose / Pharo / Squeak / ... community in this respect: I am sure there are a lot of cool tools and technolgies out there, and I see names flying around but I have no idea what they are. > > Apache gets away with it because it is world famous. Once your tool is world famous the name does not matter anymore. > > OK name your stuff how you want but in that case the community should also put a glossary online so that people like me can find their way. > > On 16 Nov 2010, at 11:16, Stéphane Ducasse wrote: > >> why? >> >> a name is not an explanation. >> >> Ava: an XML parser >> >> So for me I repeat is XML support is a bad name. >> >> Look at Comanche, Apache >> >> why apache is not called HTTPServer? >> >> >> Stef > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 6 months

Re: Issue 149 in moose-technology: Reorganize packages

by Stéphane Ducasse

Merlin is a wizard :) You see an easy name > > +1 Too many cryptic names in and around Moose and Pharo. Or at least put a glossary online! > > On 16 Nov 2010, at 06:50, moose-technology(a)googlecode.com wrote: > >> >> Comment #21 on issue 149 by jannik.laval: Reorganize packages >> http://code.google.com/p/moose-technology/issues/detail?id=149 >> >> We should rename Merlin also >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 6 months

Re: The future of Opax in XML-Support

by Stéphane Ducasse

why? a name is not an explanation. Ava: an XML parser So for me I repeat is XML support is a bad name. Look at Comanche, Apache why apache is not called HTTPServer? Stef >> We can always change it back to YAXO or change it to something else entirely. I would at least prefer something with "XML" in it so people will still be able to easily find, whether through Googling or searching on SqueakSource, an XML parser for Squeak/Pharo/Gemstone without having to know the cutesy name its developers chose for it ahead of time (see practically any Ruby library for an example of what I'm talking about). > > > Yep. Having 'XML' in the name is important. > > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years, 6 months

Re: The future of Opax in XML-Support

by Stéphane Ducasse

>>> >>> >>> Regarding Opax, your analysis is not quite right. >>> - You do not need to subclass the OPOpaxHandler. >>> - The goal of Opax is not to replace DOM, but to enhance SAX. It's true that at the moment it still creates a tree, but this should be changed to make it optional. The original idea of Opax was to dispatch everything, including the factory decision to the Element, but the implementation remained behind the wishes. >>> - Opax is tiny: 3 classes + 4 test classes >>> - OPGenericElement should simply be made a subclass of XMLElement, and we would have the compatibility we would need. >>> - I do not see the reasons why DOM should be preferred to SAX. The problem with DOM is that it always creates XML elements :). When you have large XML files, you often do not want to load them, but just to process them directly. This is the goal of SAX, but then SAX is procedural. Opax should be used to transform SAX into an object-oriented handling. >>> >>> Instead of removing it, I would suggest a different approach. Let's make it focus on the SAX parsing: >>> - We could easily get it to use the XMLNodeFactory >>> - We could subclass OPGenericElement from XMLElement. >>> >>> In any case, regarding packaging, I would definitely be in favor of splitting XMLSupport in multiple packages. >> >> It would be good also to have a more sexy name that XMLSupport. >> I know people do not care about names but XMLSupport looks like ok here is a garage yes you can find the tool may be, >> while I would love to have Gardner a nice and cool toolkit to take care of tree (soft and nice (woman) voice) if you see what I mean. > > I believe the library used to be called YAXO, which was an acronym for... something. YetAnotherX.... and Yaxo is way better than XMLSupportKitchenSinkAndMoreButThisIsNotClearAndNameSucksSoMayBeCodeTooWhyNot > I am not sure why the name was changed to something so generic; perhaps because it sounds more professional, certainly not. Just lack of idea. > or for SEO performance reasons, or so people would know this was *the* package to download for handling XML in Squeak and Pharo. I don't really know. this is why I propose that we think about it, have fun and get a real cool name. For example (this is not really working) just brainstorming 3 seconds. AvaDoom (because Ava Gardner ~ Gardener ~ Trees of Dom Objects) the logo could be a voodoo invocation. Stef

14 years, 6 months

Re: The future of Opax in XML-Support

by Stéphane Ducasse

On Nov 15, 2010, at 9:45 AM, Tudor Girba wrote: > Hi, > > Thanks for this nice overview. I am happy that XML handling gets a bit more traction in Smalltalk :). I took a quick look and your XMLPluggableElementFactory sounds quite interesting, and it's great that it supports namespaces. > > Regarding Opax, your analysis is not quite right. > - You do not need to subclass the OPOpaxHandler. > - The goal of Opax is not to replace DOM, but to enhance SAX. It's true that at the moment it still creates a tree, but this should be changed to make it optional. The original idea of Opax was to dispatch everything, including the factory decision to the Element, but the implementation remained behind the wishes. > - Opax is tiny: 3 classes + 4 test classes > - OPGenericElement should simply be made a subclass of XMLElement, and we would have the compatibility we would need. > - I do not see the reasons why DOM should be preferred to SAX. The problem with DOM is that it always creates XML elements :). When you have large XML files, you often do not want to load them, but just to process them directly. This is the goal of SAX, but then SAX is procedural. Opax should be used to transform SAX into an object-oriented handling. > > Instead of removing it, I would suggest a different approach. Let's make it focus on the SAX parsing: > - We could easily get it to use the XMLNodeFactory > - We could subclass OPGenericElement from XMLElement. > > In any case, regarding packaging, I would definitely be in favor of splitting XMLSupport in multiple packages. It would be good also to have a more sexy name that XMLSupport. I know people do not care about names but XMLSupport looks like ok here is a garage yes you can find the tool may be, while I would love to have Gardner a nice and cool toolkit to take care of tree (soft and nice (woman) voice) if you see what I mean. Stef

14 years, 6 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2010