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. Tim > On 12 Jun 2017, at 20:53, p...@highoctane.be wrote: > > 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 <emaring...@gmail.com > <mailto:emaring...@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 > > >
