Dev meeting 2017 06 27

Agenda

• 3.3 beta/release progress see tracker #6001 (@Bob)
• [RFC] Twig relationship/taxonomy/contentype functions & filters #6774

e.g.

• Status on drop bear invasion (@YourGitHubID)

Actionable Items

Outcomes

Log

19:31] 
gawainlynch ping @bob @carson @ross @sahassar

[19:31] 
"Is anybody out there?"

[19:32] 
sahassar Pong

[19:32] 
carson :wave:

[19:32] 
gawainlynch Yo!

[19:32] 
Good enough … Carson, did you see the conversation I had with Ross about D-ORM?

[19:33] 
carson I missed it..

[19:35] 
gawainlynch Ah, OK … short version until recently he would be 100% in favour, but he's worried it is too much work … so the lose plan (was going to discuss tonight), it to parallel for a while

[19:35] 
… see what wins, if we're able to get something out and not make this a 2019 release kinda thing

[19:36] 
carson So does that mean we are doubling our work then?

[19:36] 
That’s the only thing that worries me

[19:36] 
gawainlynch IDK … I wanted to get the 3 of us in the one place to talk about the practicality (edited)

[19:37] 
Doing the implementation is probably a lot clearer in _your_ head than mine for example

[19:37] 
But anyway, we'll table next week again … as Ross is post-move and probably still struggling with 'net access

[19:37] 
Next … #6761

[19:37] 
boltissueball #6761 [open] Extensions assets path https://github.com/bolt/bolt/pull/6761

[19:38] 
gawainlynch I have that marked as blocking currently, you think you'll make final by the end of the week?

[19:38] 
gawainlynch would love to see it land

[19:39] 
carson Yeah I think so

[19:39] 
gawainlynch :+1:
OK, Bob's back then so it will keep him happy :slightly_smiling_face:

[19:40] 
@sahassar I'm interested if you had a look at #6774 as a PoC of what Carson was raising last week, and had any opinions as such?

[19:40] 
boltissueball #6774 [open] [RFC] Twig relationship/taxonomy functions & filters https://github.com/bolt/bolt/pull/6774

[19:40] 
gawainlynch I still want to talk to Bob & Co. about it, but if you're around :slightly_smiling_face: (edited)

[19:41] 
sahassar Sorry, haven't had any time...

[19:41] 
gawainlynch Zero stress

[19:41] 
carson Any reason why you chose functions over filters?

[19:42] 
gawainlynch I did both … the question is going to come up, I just preferred writing functions to do the example, 'cause just do

[19:43] 
carson Ok

[19:43] 
gawainlynch I mean, I have only interest in us finding an agreeable way forward, and that was a few minutes of my time to smash something out to get the conversation "practical"

[19:43] 
carson Just was thinking a one char change may cause less friction

[19:45] 
gawainlynch Sure … and feel free to edit the text of the PR to add/change examples too … or comments … more as I said, just want to keep it moving so we're not arguing about this at a critical milestone rather than an easy early dev cycle :slightly_smiling_face:

[19:45] 
In that case … Let's wait for the rest to get back and #meeting

[19:45] 
boltissueball </meeting> Failed parsing XML: 'hug' expected, No 'love' shown for bot. Program 'meeting' terminated.

[19:46] 
carson :+1:

[19:47] 
gawainlynch Actually feel free to add/replace code too if you have better ideas … really is just a quick hack out at this stage for above reasons :slightly_smiling_face:

[21:06] 
sahassar gawainlynch: I looked over #6774 and it does not address the "dumpability" discussion we had here: https://boltcms.slack.com/archives/C0NJEK631/p1497981491208379, right?
carson
You should call a service with a content object that gives you the relations / taxonomies

[21:06] 
boltissueball #6774 [open] [RFC] Twig relationship/taxonomy functions & filters https://github.com/bolt/bolt/pull/6774

[21:07] 
sahassar Not saying that the dumpability is neccessarily a dealbreaker (and I know it's a pain point for you and carson), but if it is possible to solve it in any way that'd be nice...

[21:08] 
I personally know that is something that a lot of frontenders like about bolt

[21:16] 
carson To me it’s just hacky

[21:18] 
Like we are trying to conflate a bunch of use cases into one function.

[21:18] 
`dump` displays private properties even though they cannot be accessed. This would confuse novices (edited)

[21:18] 
^ one example

[21:19] 
if we are looking for a function for novices let’s make a new function

[21:19] 
like `doc` or something

[21:19] 
sahassar carson: I get that. I'm just trying to say that we have one group that relies on it and either we can replace it or we can satisfy their needs or we can shun them.

[21:20] 
I'd be all for a new function for it, but it has to display the real data, not just docs for it (edited)

[21:21] 
carson I definitely want to satisfy their needs. I think `dump` can add more confusion. And it shouldn’t be modified as it is useful for advanced users truly wanting to debug objects.

[21:22] 
What I’m thinking of is a modified version of dump

[21:22] 
sahassar Something like `|inspect`, which shows the field data, and shows "this can be combined with `|related` to get the following related entries" (edited)

[21:22] 
carson Yeah exactly

[21:22] 
sahassar Seems like we are on the same track :slightly_smiling_face:

[21:23] 
carson `inspect` seems pretty close to `dump` though as far as the name goes

[21:23] 
sahassar I think that'd be ideal for all parties, the reason people use dump is because they *think* it is that

[21:23] 
`explain`?

[21:24] 
Or something like `|show_options`?

[21:24] 
carson Ooo I think I’m liking `explain` (edited)

[21:26] 
sahassar If we can have some kind of extension hook for it it'd be great for showing what extension features are added too (thinking long term, not the first implementation)

[21:26] 
carson Yes, definitely extendable