A question of style - pass a context or embed one?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

A question of style - pass a context or embed one?

Tim Mackinnon
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?

Tim
Reply | Threaded
Open this post in threaded view
|

Re: A question of style - pass a context or embed one?

Esteban A. Maringolo
Hello Tim,

2017-06-12 16:15 GMT-03:00 Tim Mackinnon <[hidden email]>:

> 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

Reply | Threaded
Open this post in threaded view
|

Re: A question of style - pass a context or embed one?

philippeback
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 <[hidden email]> wrote:
Hello Tim,

2017-06-12 16:15 GMT-03:00 Tim Mackinnon <[hidden email]>:
> 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



Reply | Threaded
Open this post in threaded view
|

Re: A question of style - pass a context or embed one?

Tim Mackinnon
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, [hidden email] 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 <[hidden email]> wrote:
Hello Tim,

2017-06-12 16:15 GMT-03:00 Tim Mackinnon <[hidden email]>:
> 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




Reply | Threaded
Open this post in threaded view
|

Re: A question of style - pass a context or embed one?

Esteban A. Maringolo
2017-06-13 7:39 GMT-03:00 Tim Mackinnon <[hidden email]>:

> 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

Reply | Threaded
Open this post in threaded view
|

Re: A question of style - pass a context or embed one?

Stephane Ducasse-3
In reply to this post by Tim Mackinnon
Hi tim

what was the result of you chat?
Because to me I would go for the first solution because in any case
you would have to modify the sprintsIn: method if the argument is
really changing so I do not see the point to carry around and extra
arguments to all the methods.

stef

On Mon, Jun 12, 2017 at 9:15 PM, Tim Mackinnon <[hidden email]> wrote:

> 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?
>
> Tim