A dynamic variable could work too. But domain objects are somewhat hard to do in my view because we are dealing with an API that has tons of options and customizability in its results + people can define their own types and fields. That's why I went for a JiraBuilder thing that has a reference to a Jira instance. That builder is allowing one to make higher level queries for the users (like doing Epics, Stories, links, custom fields resolution, meta data grabbing, prototype creation etc). I didn't want to have an Epic class, a Story class, etc. Because my idea of an Epic may not be your idea, so we may end up with a PluggableEpic etc and it will never end. My take is that it is better to use the vocabulary of the domain in the method names but still work with dynamic structures like dictionaries and some helpers. I am still curious to see those domain objects because I understand that they would ease inspection etc. Maybe we should have a generator for these so that we can regenerate the classes based on the metadata provided by Jira. Phil On Mon, Jun 12, 2017 at 9:28 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

Hello Tim,

2017-06-12 16:15 GMT-03:00 Tim Mackinnon <tim@testit.works>:

...

Hi - I’m after some ideas or maybe previous examples that might guide me in the best approach of wrapping a low level library (essentially the Jira connector that Phil demo’d at Pharo days this year).

There are some low level commands that will fetch json arrays for you given a “lira” instance- e.g:

board := JiraBoard fromJira: jira named: ‘Project'. sprints := board sprintsFrom: jira.

My question is related to building on top of this - and its a style question.

I want model objects that wrap the json arrays and let me navigate things a bit more simply, and query details more naturally - however I can’t decide whether my model objects should “contain” a jira when you instantiate them - which can be re-used for subsequent queries - OR - whether I should view jira as a from of context, and keep passing it to methods when I need to retrieve more details, or child objects?

e.g. myBoard := ModelBoard fromJira: jira named: ‘Project’. mySprints := myBoard sprints. “No need to pass the jira again”.

vs.

mySprints :- myBoard sprintsIn: jira.

I’m wondering if anything might guide me one way or the other? Is one more tasteful/elegant than the other?

I'd go for the first option. It is, every JIRA object knows the "jira" it belongs to.

Although the second option is better for decoupling, not having to pass objects around to obtain properties allows you to better integrate with the tools (think GTInspector with specific inspector for cards).

I don't understand what the "jira" is exactly, if a whole JSON object (a Dictionary) containing everything, a connection to JIRA API, or just the JSON object/Dictionary branch containing the attributes specific of the "wraping" object (the board, in this case).

Regards!

Esteban A. Maringolo

2017-06-13 7:39 GMT-03:00 Tim Mackinnon <tim@testit.works>:

Phil - to be clear, I think your underlying implementation is great - it provides a great building block.

However, just as with databases, when you build something higher level on top - the question comes up about how much you hide that retrieval mechanism. The GTInspector argument is an interesting one from a pure domain understanding - and possibly armed with the underlying piping you have provided, it is then up to me to layer my understanding of the higher level model on top.

I perhaps should look at glorp a bit more carefully as maybe there is inspiration there.

Let's talk on the Discourse chat about this, but as a short description, Glorp has a Facade object (the GlorpSession) that knows how to delegate most actions to internal parts. But objects don't "know" the session they belong to, because the ORM is orthogonal to the domain model. Esteban A. Maringolo