Yes, there is a lot going on. We're still missing a "featured stack" (at least one) that integrates all the parts of a "common" application need. "Necessity is the mother of invention" :) Regards, Esteban A. Maringolo El mié., 13 feb. 2019 a las 5:33, Sven Van Caekenberghe (<sven@stfx.eu>) escribió:
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@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-Exa...
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@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