February 2019 - Pharo-users

Re: [Pharo-users] Multiple NeoJSON mappings for the same domain object

by Esteban Maringolo

Not in a hurry at all, I'm defining this part, so I can explore different alternatives. I'll explore the OpenAPI approach with JSONSchema as well. Regards, ps: What I liked about Stargate is that it manages other aspects of an API such as CORS, HATEOAS [1] and resource versioning, but JSON-HyperSchema [2] seems to provide a similar approach to HATEOAS, I don't know if there something in OpenAPI to have multiple representation versions of the same resource (so you preserve the route, but make the API back AND forward compatible). [1] https://en.wikipedia.org/wiki/HATEOAS [2] https://www.ietf.org/archive/id/draft-handrews-json-schema-hyperschema-01.t… Esteban A. Maringolo El miÃ©., 13 feb. 2019 a las 4:45, Norbert Hartl (<norbert(a)hartl.name>) escribiÃ³: > > If you are not in a hurry you can use JSON schema. That is also an external mapper which can validate. And the spec is serializable. You might miss some functionality but I could try to add that if you donât do. I would be happy to have more users of the library. > > If you use it for REST you could also use OpenAPI which I did. It uses the JSON schema stuff for doing it. > > Norbert > > > Am 13.02.2019 um 02:58 schrieb Esteban Maringolo <emaringolo(a)gmail.com>: > > > > Meanwhile I found another approach to solve this in the context of a > > JSON/REST API. > > > > E.g. see #addRuleToEncode:to:using: in. > > https://github.com/ba-st/Stargate/blob/release-candidate/source/Stargate-Ex… > > > > Has a separate mapper for encoding and decoding, depending on the endpoint: > > > > Regards, > > > > Esteban A. Maringolo > > > > El mar., 12 feb. 2019 a las 19:34, Esteban Maringolo > > (<emaringolo(a)gmail.com>) escribiÃ³: > >> > >> Hi all, Sven, :) > >> > >> I'm working on a domain model that will have different JSON > >> representations for the same domain objects, so depending on the > >> context it will return one representation or another. > >> > >> In the past to solve the multiple representations, what I did was to > >> build "helper" methods that added the mappings to the mapper. > >> > >> So the process was like: > >> 1. instantiate the mapper > >> 2. call a #neoJsonSimple: mapper > >> 3. configure the mapper by calling other mapping defining methods > >> 4. convert the object to a JSON string. > >> > >> If I wanted an "extended" representation, in the step 2 I would call > >> #neoJsonExtended: instead. > >> > >> But I find this "too manual" to scale. > >> > >> So... is there a better, Â¿canonical?, way to achieve this? > >> > >> > >> Thanks! > >> > >> > >> ps: By now it will be only object -> JSON (so NeoJSONWriter), but in > >> the future I might need to instantiate objects back from JSON, so the > >> mappings should be for both mappers. > >> > >> Esteban A. Maringolo > > > >

Feb. 13, 2019

Re: [Pharo-users] Traits for class methods?

by Marcus Denker

> On 13 Feb 2019, at 12:22, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > On 11/02/2019 17:18, Cyril Ferlicot wrote: > >> A quick question: is it possible to use traits to define class methods? >>> For example, could the popular singleton pattern consisting of the >>> three class methods #uniqueInstance, #new, and #reset plus the instance >>> variable uniqueInstance be packaged as a trait? >> Hi, >> >> Yes it is possible. > > Thanks for your encouragement! > > I ended up trying exactly that example, and it works just fine: > > https://github.com/khinsen/SingletonTrait > It is amazing how much better this feels now that Traits can define state, tooâ¦ (compared to before where it was just methods). https://github.com/khinsen/SingletonTrait/blob/master/SingletonTrait/Single… I would even want to have (and use) a Trait like that in the system by default. Marcus

Feb. 13, 2019

Re: [Pharo-users] Traits for class methods?

by Konrad Hinsen

On 11/02/2019 17:18, Cyril Ferlicot wrote: > A quick question: is it possible to use traits to define class methods? >> For example, could the popular singleton pattern consisting of the >> three class methods #uniqueInstance, #new, and #reset plus the instance >> variable uniqueInstance be packaged as a trait? > Hi, > > Yes it is possible. Thanks for your encouragement! I ended up trying exactly that example, and it works just fine: Â Â Â https://github.com/khinsen/SingletonTrait Konrad.

Feb. 13, 2019

Re: [Pharo-users] Running test

by Hilaire

You mean the same libgit plugin error? Hilaire Le 13/02/2019 Ã 03:38, Sean P. DeNigris a Ã©critÂ : > HilaireFernandes wrote >> I could try to fetch one from PharoLuncher on Mac OSX > I just dl-ed the new Launcher on Mojave and it seems that I had to > temporarily disable Gatekeeper via command line to get around a similar > error. -- Dr. Geo http://drgeo.eu

Feb. 13, 2019

Re: [Pharo-users] Multiple NeoJSON mappings for the same domain object

by Sven Van Caekenberghe

Wow, first time I heard about https://github.com/ba-st/Stargate - seems like a great project. So much is happening in and around Pharo, it is really impossible to follow everything. > On 13 Feb 2019, at 02:58, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Meanwhile I found another approach to solve this in the context of a > JSON/REST API. > > E.g. see #addRuleToEncode:to:using: in. > https://github.com/ba-st/Stargate/blob/release-candidate/source/Stargate-Ex… > > Has a separate mapper for encoding and decoding, depending on the endpoint: > > Regards, > > Esteban A. Maringolo > > El mar., 12 feb. 2019 a las 19:34, Esteban Maringolo > (<emaringolo(a)gmail.com>) escribiÃ³: >> >> Hi all, Sven, :) >> >> I'm working on a domain model that will have different JSON >> representations for the same domain objects, so depending on the >> context it will return one representation or another. >> >> In the past to solve the multiple representations, what I did was to >> build "helper" methods that added the mappings to the mapper. >> >> So the process was like: >> 1. instantiate the mapper >> 2. call a #neoJsonSimple: mapper >> 3. configure the mapper by calling other mapping defining methods >> 4. convert the object to a JSON string. >> >> If I wanted an "extended" representation, in the step 2 I would call >> #neoJsonExtended: instead. >> >> But I find this "too manual" to scale. >> >> So... is there a better, Â¿canonical?, way to achieve this? >> >> >> Thanks! >> >> >> ps: By now it will be only object -> JSON (so NeoJSONWriter), but in >> the future I might need to instantiate objects back from JSON, so the >> mappings should be for both mappers. >> >> Esteban A. Maringolo >

Feb. 13, 2019

Re: [Pharo-users] Multiple NeoJSON mappings for the same domain object

by Norbert Hartl

Forgot to add the links https://github.com/zweidenker/JSONSchema https://github.com/zweidenker/OpenAPI Norbert > Am 13.02.2019 um 08:44 schrieb Norbert Hartl <norbert(a)hartl.name>: > > If you are not in a hurry you can use JSON schema. That is also an external mapper which can validate. And the spec is serializable. You might miss some functionality but I could try to add that if you donât do. I would be happy to have more users of the library. > > If you use it for REST you could also use OpenAPI which I did. It uses the JSON schema stuff for doing it. > > Norbert > >> Am 13.02.2019 um 02:58 schrieb Esteban Maringolo <emaringolo(a)gmail.com>: >> >> Meanwhile I found another approach to solve this in the context of a >> JSON/REST API. >> >> E.g. see #addRuleToEncode:to:using: in. >> https://github.com/ba-st/Stargate/blob/release-candidate/source/Stargate-Ex… >> >> Has a separate mapper for encoding and decoding, depending on the endpoint: >> >> Regards, >> >> Esteban A. Maringolo >> >> El mar., 12 feb. 2019 a las 19:34, Esteban Maringolo >> (<emaringolo(a)gmail.com>) escribiÃ³: >>> >>> Hi all, Sven, :) >>> >>> I'm working on a domain model that will have different JSON >>> representations for the same domain objects, so depending on the >>> context it will return one representation or another. >>> >>> In the past to solve the multiple representations, what I did was to >>> build "helper" methods that added the mappings to the mapper. >>> >>> So the process was like: >>> 1. instantiate the mapper >>> 2. call a #neoJsonSimple: mapper >>> 3. configure the mapper by calling other mapping defining methods >>> 4. convert the object to a JSON string. >>> >>> If I wanted an "extended" representation, in the step 2 I would call >>> #neoJsonExtended: instead. >>> >>> But I find this "too manual" to scale. >>> >>> So... is there a better, Â¿canonical?, way to achieve this? >>> >>> >>> Thanks! >>> >>> >>> ps: By now it will be only object -> JSON (so NeoJSONWriter), but in >>> the future I might need to instantiate objects back from JSON, so the >>> mappings should be for both mappers. >>> >>> Esteban A. Maringolo >> > >

Feb. 13, 2019

Re: [Pharo-users] Multiple NeoJSON mappings for the same domain object

by Norbert Hartl

If you are not in a hurry you can use JSON schema. That is also an external mapper which can validate. And the spec is serializable. You might miss some functionality but I could try to add that if you donât do. I would be happy to have more users of the library. If you use it for REST you could also use OpenAPI which I did. It uses the JSON schema stuff for doing it. Norbert > Am 13.02.2019 um 02:58 schrieb Esteban Maringolo <emaringolo(a)gmail.com>: > > Meanwhile I found another approach to solve this in the context of a > JSON/REST API. > > E.g. see #addRuleToEncode:to:using: in. > https://github.com/ba-st/Stargate/blob/release-candidate/source/Stargate-Ex… > > Has a separate mapper for encoding and decoding, depending on the endpoint: > > Regards, > > Esteban A. Maringolo > > El mar., 12 feb. 2019 a las 19:34, Esteban Maringolo > (<emaringolo(a)gmail.com>) escribiÃ³: >> >> Hi all, Sven, :) >> >> I'm working on a domain model that will have different JSON >> representations for the same domain objects, so depending on the >> context it will return one representation or another. >> >> In the past to solve the multiple representations, what I did was to >> build "helper" methods that added the mappings to the mapper. >> >> So the process was like: >> 1. instantiate the mapper >> 2. call a #neoJsonSimple: mapper >> 3. configure the mapper by calling other mapping defining methods >> 4. convert the object to a JSON string. >> >> If I wanted an "extended" representation, in the step 2 I would call >> #neoJsonExtended: instead. >> >> But I find this "too manual" to scale. >> >> So... is there a better, Â¿canonical?, way to achieve this? >> >> >> Thanks! >> >> >> ps: By now it will be only object -> JSON (so NeoJSONWriter), but in >> the future I might need to instantiate objects back from JSON, so the >> mappings should be for both mappers. >> >> Esteban A. Maringolo >

Feb. 13, 2019

Re: [Pharo-users] Running test

by Sean P. DeNigris

HilaireFernandes wrote > I could try to fetch one from PharoLuncher on Mac OSX I just dl-ed the new Launcher on Mojave and it seems that I had to temporarily disable Gatekeeper via command line to get around a similar error. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 13, 2019

Re: [Pharo-users] Multiple NeoJSON mappings for the same domain object

by Esteban Maringolo

Meanwhile I found another approach to solve this in the context of a JSON/REST API. E.g. see #addRuleToEncode:to:using: in. https://github.com/ba-st/Stargate/blob/release-candidate/source/Stargate-Ex… Has a separate mapper for encoding and decoding, depending on the endpoint: Regards, Esteban A. Maringolo El mar., 12 feb. 2019 a las 19:34, Esteban Maringolo (<emaringolo(a)gmail.com>) escribiÃ³: > > Hi all, Sven, :) > > I'm working on a domain model that will have different JSON > representations for the same domain objects, so depending on the > context it will return one representation or another. > > In the past to solve the multiple representations, what I did was to > build "helper" methods that added the mappings to the mapper. > > So the process was like: > 1. instantiate the mapper > 2. call a #neoJsonSimple: mapper > 3. configure the mapper by calling other mapping defining methods > 4. convert the object to a JSON string. > > If I wanted an "extended" representation, in the step 2 I would call > #neoJsonExtended: instead. > > But I find this "too manual" to scale. > > So... is there a better, Â¿canonical?, way to achieve this? > > > Thanks! > > > ps: By now it will be only object -> JSON (so NeoJSONWriter), but in > the future I might need to instantiate objects back from JSON, so the > mappings should be for both mappers. > > Esteban A. Maringolo

Feb. 13, 2019

Re: [Pharo-users] Calypso documentation? Or understanding menu building

by Tim Mackinnon

Thanks Denis - lots for me to look through there. Iâll also add a PR to add those documentation links to the Calypso readme. Tim > On 12 Feb 2019, at 19:32, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Tim > > Ð²Ñ, 12 ÑÐµÐ²Ñ. 2019 Ð³. Ð² 13:42, Tim Mackinnon <tim(a)testit.works>: > Is there any documentation on Calypso application contexts? I am trying to add a menu item to a package tag (the bit underneath a package - which I often call a sub-package). > > Only class comments are available for Calypso. Also there are a Commander booklet <https://github.com/SquareBracketAssociates/Booklet-Infrastructure>which describes contexts and ClassAnnotation github readme <https://github.com/pharo-ide/ClassAnnotation> (together with class comments). > > > Iâve specified: > > ^CmdContextMenuActivation > byItemOf: ClyQueryMenuGroup for: RPackage asCalypsoItemContext > > > The #for: argument of command activations is a context where command should be available. Context describes condition where given command (its activation strategy) should be visible for users. > In your example "RPackage asCalypsoItemContext" is an instance of ClyBrowserItemContext which matches any selected package in the browser (when a kind of RPackage is selected). > And that's why you do not see it on selected tag because the tag is not a package. > > But that puts my menu on the package and not the tag > - and if I use the inspect extra menu in calypso, I get what looks to be something that could help me determine what I want but Iâm struggling to understand what ClyTaggedClassGroup does, and what a context is all about. > > Inspect command opens inspector of actually selected object which is an instance of ClyTaggedClassGroup in that case (try inspect selected method and you will get a CompiledMethod). > Children of package in browser are instances of ClyClassGroup and subclasses. So they are not raw tags. If you need a command for a tag you should add a command for ClyTaggedClassGroup items: > > ^CmdContextMenuActivation > byItemOf: ClyQueryMenuGroup for: ClyTaggedClassGroup asCalypsoItemContext > > Look for example at SycPromotePackageFromTagCommand class>>#fullBrowserMenuActivation which is defined this way. > > There are other kind of contexts which can be used in command annotations. For example if you want a command for selected method only in full browser then you should use ClyMethodContextOfFullBrowser: > > ^CmdContextMenuActivation byItemOf: ClyQueryMenuGroup for: ClyMethodContextOfFullBrowser > > it can be confusing that simple class is used in this case. But underhood it is converted to the instance of context where command should be available. > > > Has anyone else played around with this at all? > > Ideally I want to have a menu appear on all the tags underneath a particular package - and possibly including that package (or maybe not - I havenât decided as I want to try it in the wild). > > While Iâm at it - I have quite understood how to create submenuâs either - as Iâd like to have several commands all as sub items of a menu item âExercismâ. > > Look at commander booklet. It includes example. > > > Tim > > >

Feb. 12, 2019