June 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Understanding ZnJSONReader mapping?

by Tim Mackinnon

Its sort of an awkward format, so maybe mapping is just not the way to go (but Iâm still keen to learn how to properly use it when it is appropriate). For the record (if anyone is interested), an example json sample is here (https://sprintdemo.prismic.io/api/v1/documents/search?q=%5B%5Bat(document.t… <https://sprintdemo.prismic.io/api/v1/documents/search?q=[[at(document.tags,…>). It ends up giving you something like below (the names like heading, effectivefrom are names you define in your Prismic page type, but their values are then a standard format (almost) - so maybe those I can usefully map? Or maybe I just stick to dictionaries and plough on. Tim page: { --heading: { type: "StructuredText" --value: [ --{ type: "heading1" text: "Sample Page" spans: [ ] } ] } --effectivefrom: { type: "Timestamp" value: "2018-06-20T23:00:00+0000" } --department: { type: "Select" value: âSMA" } - - content: { type: "StructuredText" --value: [ --{ type: "paragraph" text: "This is a sample page with some content." spans: [ ] } -+{ â¦ } --{ type: "paragraph" text: "There are 4 rules:" --spans: [ --{ start: 10 end: 17 type: "strong" } ] } > On 7 Jun 2018, at 21:58, Tim Mackinnon <tim(a)testit.works> wrote: > > Hey thanks - so maybe there are more legs to this - although itâs the decoding Iâm currently interested in (but Iâm sure encoding will come up at some point on my journey). > > So it seems that my mapper can have multiple entries (that bit I had missed - although seems obvious in retrospect now). > > But then you have have to say #nextAs: and this is what I donât get for anything more complicated - how do I choose as it could be any one of the patterns I want to map? > > Sadly itâs not my scheme - itâs a prismic.io one so Iâm trying to follow what the equivalent python/js/csharp libs do - but they are horrid, filled with tons on instanceof crap... > > Iâve gotten reasonably far but as the structures can be recursive for a cms, I think I can do much better somehow. > > Tim > > Sent from my iPhone > >> On 7 Jun 2018, at 21:44, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >>> On 07/06/2018 17:21, Tim Mackinnon wrote: >>> Hi - is there something I can read/study to get a bit more familiar with Json mapping? I have read the Pharo enterprise book (chapter 8). >>> >>> Iâve been using NeoJSONObject but then it occurred to me that maybe I could map better domain objects directly and simplify things. However it seems that the intent of mapping is just for simple things like an array of points - whereas if I have 15 different domain objects (albeit with a type key), then Iâm wondering if I should just wrap json nodes on usage? >>> >>> In fact Iâm wondering what the point of mapping is if itâs so simple - or maybe Iâm missing an important concept? >> If your objects just hold data, then you can get very far with >> NeoJSONObject, but if you want to do more, you can get pretty extensible >> mappings with the use of the valueSchema: option in the mapper. >> >> For instance, to write a TsOrder (a model of an purchase order) I >> configured the mapper this way: >> >> mapper for: TsOrder do: [ :mapping | >> mapping mapAccessors: #(id). >> (mapping mapAccessor: #date) valueSchema: Date. >> (mapping mapAccessor: #edd) valueSchema: #NamedModel. >> (mapping mapAccessor: #provider) valueSchema: #NamedModel. >> (mapping mapAccessor: #status) valueSchema: #NamedModel. >> (mapping mapAccessor: #customerCode). >> (mapping mapAccessor: #totalOriginalPrice to: 'total') valueSchema: >> #monetary. >> ]. >> >> mapper for: Date customDo: [ :mapping | >> mapping encoder: [ :date | date ddmmyyyy ] ]. >> >> mapper for: #monetary customDo: [ :mapping | >> mapping encoder: [ :price | price printShowingDecimalPlaces: 2 ] ]. >> >> mapper for: DateAndTime customDo: [ :mapping | >> mapping decoder: [ :string | DateAndTime fromString: string ]. >> ]. >> >> mapper for: #NamedModel customDo: [ :mapping | >> mapping encoder: [ :persona | persona displayString ] ]. >> >> >> For decoding it might be trickier, because you might need more objects >> other than just deserializing from JSON, e.g. to avoid instantiating >> twice the same domain object, or if you need to lookup an entity in the >> database by ID, and then you need access to the database, etc. >> >> Throughout my journey of developing a few JSON-REST APIs I started using >> the NeoJSON approach, then JsonObject and then WAJsonCanvas. >> >> I found myself more confortable writing JSON with the latter (I like the >> canvas approach of Seaside) and instantiating NeoJSONObject/JsonObject >> and building my business objects from these cherry picking what I needed. >> >> What NeoJSON offers as a "differentiator" is that it is stream based, so >> there is no need to have intermediate "structures" (it is, >> dictionaries), and the mappers are orthogonal to the objects (unless you >> use the default class side #neoJsonMapping:) >> >> WAJsonCanvas offers stream based writing, but there are no mappings, but >> if you always serialize a proper hierarchy of renderJsonOn: implementors >> could prove to be effective, in particular if you have to build your >> objects manually from a JSON stream. >> >> Regards, >> >> >> -- >> Esteban A. Maringolo >> > >

June 7, 2018

Re: [Pharo-users] Understanding ZnJSONReader mapping?

by Tim Mackinnon

Hey thanks - so maybe there are more legs to this - although itâs the decoding Iâm currently interested in (but Iâm sure encoding will come up at some point on my journey). So it seems that my mapper can have multiple entries (that bit I had missed - although seems obvious in retrospect now). But then you have have to say #nextAs: and this is what I donât get for anything more complicated - how do I choose as it could be any one of the patterns I want to map? Sadly itâs not my scheme - itâs a prismic.io one so Iâm trying to follow what the equivalent python/js/csharp libs do - but they are horrid, filled with tons on instanceof crap... Iâve gotten reasonably far but as the structures can be recursive for a cms, I think I can do much better somehow. Tim Sent from my iPhone > On 7 Jun 2018, at 21:44, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> On 07/06/2018 17:21, Tim Mackinnon wrote: >> Hi - is there something I can read/study to get a bit more familiar with Json mapping? I have read the Pharo enterprise book (chapter 8). >> >> Iâve been using NeoJSONObject but then it occurred to me that maybe I could map better domain objects directly and simplify things. However it seems that the intent of mapping is just for simple things like an array of points - whereas if I have 15 different domain objects (albeit with a type key), then Iâm wondering if I should just wrap json nodes on usage? >> >> In fact Iâm wondering what the point of mapping is if itâs so simple - or maybe Iâm missing an important concept? > If your objects just hold data, then you can get very far with > NeoJSONObject, but if you want to do more, you can get pretty extensible > mappings with the use of the valueSchema: option in the mapper. > > For instance, to write a TsOrder (a model of an purchase order) I > configured the mapper this way: > > mapper for: TsOrder do: [ :mapping | > mapping mapAccessors: #(id). > (mapping mapAccessor: #date) valueSchema: Date. > (mapping mapAccessor: #edd) valueSchema: #NamedModel. > (mapping mapAccessor: #provider) valueSchema: #NamedModel. > (mapping mapAccessor: #status) valueSchema: #NamedModel. > (mapping mapAccessor: #customerCode). > (mapping mapAccessor: #totalOriginalPrice to: 'total') valueSchema: > #monetary. > ]. > > mapper for: Date customDo: [ :mapping | > mapping encoder: [ :date | date ddmmyyyy ] ]. > > mapper for: #monetary customDo: [ :mapping | > mapping encoder: [ :price | price printShowingDecimalPlaces: 2 ] ]. > > mapper for: DateAndTime customDo: [ :mapping | > mapping decoder: [ :string | DateAndTime fromString: string ]. > ]. > > mapper for: #NamedModel customDo: [ :mapping | > mapping encoder: [ :persona | persona displayString ] ]. > > > For decoding it might be trickier, because you might need more objects > other than just deserializing from JSON, e.g. to avoid instantiating > twice the same domain object, or if you need to lookup an entity in the > database by ID, and then you need access to the database, etc. > > Throughout my journey of developing a few JSON-REST APIs I started using > the NeoJSON approach, then JsonObject and then WAJsonCanvas. > > I found myself more confortable writing JSON with the latter (I like the > canvas approach of Seaside) and instantiating NeoJSONObject/JsonObject > and building my business objects from these cherry picking what I needed. > > What NeoJSON offers as a "differentiator" is that it is stream based, so > there is no need to have intermediate "structures" (it is, > dictionaries), and the mappers are orthogonal to the objects (unless you > use the default class side #neoJsonMapping:) > > WAJsonCanvas offers stream based writing, but there are no mappings, but > if you always serialize a proper hierarchy of renderJsonOn: implementors > could prove to be effective, in particular if you have to build your > objects manually from a JSON stream. > > Regards, > > > -- > Esteban A. Maringolo >

June 7, 2018

Re: [Pharo-users] Understanding ZnJSONReader mapping?

by Esteban A. Maringolo

On 07/06/2018 17:21, Tim Mackinnon wrote: > Hi - is there something I can read/study to get a bit more familiar with Json mapping? I have read the Pharo enterprise book (chapter 8). > > Iâve been using NeoJSONObject but then it occurred to me that maybe I could map better domain objects directly and simplify things. However it seems that the intent of mapping is just for simple things like an array of points - whereas if I have 15 different domain objects (albeit with a type key), then Iâm wondering if I should just wrap json nodes on usage? > > In fact Iâm wondering what the point of mapping is if itâs so simple - or maybe Iâm missing an important concept? If your objects just hold data, then you can get very far with NeoJSONObject, but if you want to do more, you can get pretty extensible mappings with the use of the valueSchema: option in the mapper. For instance, to write a TsOrder (a model of an purchase order) I configured the mapper this way: mapper for: TsOrder do: [ :mapping | mapping mapAccessors: #(id). (mapping mapAccessor: #date) valueSchema: Date. (mapping mapAccessor: #edd) valueSchema: #NamedModel. (mapping mapAccessor: #provider) valueSchema: #NamedModel. (mapping mapAccessor: #status) valueSchema: #NamedModel. (mapping mapAccessor: #customerCode). (mapping mapAccessor: #totalOriginalPrice to: 'total') valueSchema: #monetary. ]. mapper for: Date customDo: [ :mapping | mapping encoder: [ :date | date ddmmyyyy ] ]. mapper for: #monetary customDo: [ :mapping | mapping encoder: [ :price | price printShowingDecimalPlaces: 2 ] ]. mapper for: DateAndTime customDo: [ :mapping | mapping decoder: [ :string | DateAndTime fromString: string ]. ]. mapper for: #NamedModel customDo: [ :mapping | mapping encoder: [ :persona | persona displayString ] ]. For decoding it might be trickier, because you might need more objects other than just deserializing from JSON, e.g. to avoid instantiating twice the same domain object, or if you need to lookup an entity in the database by ID, and then you need access to the database, etc. Throughout my journey of developing a few JSON-REST APIs I started using the NeoJSON approach, then JsonObject and then WAJsonCanvas. I found myself more confortable writing JSON with the latter (I like the canvas approach of Seaside) and instantiating NeoJSONObject/JsonObject and building my business objects from these cherry picking what I needed. What NeoJSON offers as a "differentiator" is that it is stream based, so there is no need to have intermediate "structures" (it is, dictionaries), and the mappers are orthogonal to the objects (unless you use the default class side #neoJsonMapping:) WAJsonCanvas offers stream based writing, but there are no mappings, but if you always serialize a proper hierarchy of renderJsonOn: implementors could prove to be effective, in particular if you have to build your objects manually from a JSON stream. Regards, -- Esteban A. Maringolo

June 7, 2018

Understanding ZnJSONReader mapping?

by Tim Mackinnon

Hi - is there something I can read/study to get a bit more familiar with Json mapping? I have read the Pharo enterprise book (chapter 8). Iâve been using NeoJSONObject but then it occurred to me that maybe I could map better domain objects directly and simplify things. However it seems that the intent of mapping is just for simple things like an array of points - whereas if I have 15 different domain objects (albeit with a type key), then Iâm wondering if I should just wrap json nodes on usage? In fact Iâm wondering what the point of mapping is if itâs so simple - or maybe Iâm missing an important concept? Tim Sent from my iPhone

June 7, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Esteban A. Maringolo

On 07/06/2018 13:59, Sven Van Caekenberghe wrote: >> On 7 Jun 2018, at 14:42, Norbert Hartl <norbert(a)hartl.name> wrote: >> And safer. The current implementation of NeoJSONObject is not ver good. It returns nil on any missing key so you mask a lot of errors in your code which I find dangerous. > > Haha, it was modelled after a JavaScript object, of course it is worse, but more convenient in scripting code. > Sure, a plain Dictionary is better. Nothing that syntax sugar mapping some convenient property accessor to #at: couldn't fix. :) -- Esteban A. Maringolo

June 7, 2018

Re: [Pharo-users] more on "can't get keyboard shortcuts to work on Mac"

by GreggInCA

Paul and Tim. Nope, still doesn't work. It might be some hacker-level customization I've forgotten about. Anyway, it's not worth my time or yours to track this down. Thanks for all your help. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 7, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Sven Van Caekenberghe

> On 7 Jun 2018, at 14:42, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> Am 07.06.2018 um 14:16 schrieb Tim Mackinnon <tim(a)testit.works>: >> >> Thanks guys - it seems like I was on the right track. >> >> Making my own NeoJsonObject did work, but I will go back and see if Iâm really using the js nature of the values and if for this, just an OrderedDictionary might be clearer. >> > And safer. The current implementation of NeoJSONObject is not ver good. It returns nil on any missing key so you mask a lot of errors in your code which I find dangerous. Haha, it was modelled after a JavaScript object, of course it is worse, but more convenient in scripting code. Sure, a plain Dictionary is better. > Norbert > >> As an aside, I was doing some experiments with prismic.io (a headless cms) and the order of your content when rendering it on a page(generically) is obviously important. >> >> Tim >> >> Sent from my iPhone >> >>> On 7 Jun 2018, at 07:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>> >>>> On 7 Jun 2018, at 08:16, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> >>>> >>>>> Am 07.06.2018 um 07:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>> >>>>> Tim, >>>>> >>>>>> On 7 Jun 2018, at 01:37, Tim Mackinnon <tim(a)testit.works> wrote: >>>>>> >>>>>> Hi - Iâve hit some Json where the outputted values (they are field names) are written out in a specific order - and the author hasnât chosen to use an array to represent those fields in a specific order. >>>>>> >>>>>> { âfield1â : { â¦.}, âfield2â: { â¦ } } >>>>>> >>>>>> I think this is technically incorrect and should be: >>>>>> >>>>>> { [ {âfield1â : { â¦.}, âfield2â: { â¦ } ]} >>>>>> >>>>>> Anyway - given what Iâve got, would it be a terrible idea to create my own version NeoJsonObject and just make it a subclass of OrderedDictionary? >>>>>> >>>>>> I canât see any issues - but then I might be kidding myselfâ¦ >>>>>> >>>>>> Tim >>>>> >>>>> Yea, I think you could try making a NeoJSONOrderedObject as a subclass of OrderedDictionary, modelled after NeoJSONObject. Just remember it is implemented using DNU, which will surprise you at one point. >>>>> >>>> Wouldnât be setting #mapClass: on the reader to OrderedDictionary not enough? Dictionary is the default anyway. >>>> >>>> Norbert >>> >>> Yes, of course, Norbert, it keeps the order: >>> >>> (NeoJSONReader on: '{"BB":1,"CC":2,"AA":3}' readStream) mapClass: OrderedDictionary; next. >>> >>> => an OrderedDictionary('BB'->1 'CC'->2 'AA'->3) >>> >>> NeoJSONWriter toString: (OrderedDictionary new at: #BB put: 1; at: #CC put: 2; at: #AA put: 3; yourself). >>> >>> => '{""BB"":1,""CC"":2,""AA"":3}' >>> >>> It is not functionally 100% the same as a hypothetical NeoJSONOrderedObject, but might do. >>> >>> Sven >> >> > >

June 7, 2018

Re: [Pharo-users] Problem to use GZIPReadStream

by Serge Stinckwich

On Thu, Jun 7, 2018 at 4:59 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Serge, > > What Pharo version are you on? What is your `file` object? If `file` is a > FileReference, you need to know that by default, using `readStream` > provides now an encoded file (to keep backwards compatibility with what > most users were doing until now). > And I think that GZip should just decode/decompress binary data. > > Instead of asking it for a readStream, try asking for a `binaryReadStream`. > > compressed := file binaryReadStream. > stream := (GZipReadStream on: compressed) upToEnd asByteArray readStream. > > âThank you Guille, it works now :-) -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

June 7, 2018

Re: [Pharo-users] Problem to use GZIPReadStream

by Guillermo Polito

Hi Serge, What Pharo version are you on? What is your `file` object? If `file` is a FileReference, you need to know that by default, using `readStream` provides now an encoded file (to keep backwards compatibility with what most users were doing until now). And I think that GZip should just decode/decompress binary data. Instead of asking it for a readStream, try asking for a `binaryReadStream`. compressed := file binaryReadStream. stream := (GZipReadStream on: compressed) upToEnd asByteArray readStream. Guille On Thu, Jun 7, 2018 at 4:41 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com > wrote: > I try to decompress a gzip file like that: > > compressed := file readStream. > stream := (GZipReadStream on: compressed) upToEnd asByteArray readStream. > > âbut I have the following error: > Illegal leading byte for utf-8 encoding > â > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for > machines to execute."http://www.doesnotunderstand.org/ > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 7, 2018

Problem to use GZIPReadStream

by Serge Stinckwich

I try to decompress a gzip file like that: compressed := file readStream. stream := (GZipReadStream on: compressed) upToEnd asByteArray readStream. âbut I have the following error: Illegal leading byte for utf-8 encoding â -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

June 7, 2018