Skip to content

Dev meeting 2017 10 10

Jump to bottom
Gawain Lynch edited this page Oct 18, 2017 · 2 revisions

Agenda

e.g.

  • Status on drop bear invasion (@YourGitHubID)

Actionable Items

Outcomes

Log

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


[19:31] 
sahassar pong


[19:31] 
ross evening


[19:31] 
bob Back!


[19:32] 
(still chewing my last bite of dinner)


[19:32] 
gawainlynch Damn!


[19:32] 
carson o/


[19:32] 
gawainlynch OK, lets roll with the fun one first


[19:32] 
- Deprecate TemplateFields? (@bob)


[19:32] 
bob Ha!


[19:32] 
Ok, so, the thing is.

[19:33] 
I _like_ templatefields. I do.


[19:33] 
sahassar :-1: Not until we have a replacement IMO (edited)


[19:33] 
bob but, they were a pain to get working in 3.x, and they will probably be a painpoint again for 4.0

[19:33] 
carson GMO uses them too

[19:34] 
bob We use them a lot too.


[19:34] 
ross we could get a replacement in time for 4


[19:34] 
bob But, I was thinking the other day.. There are basically two reasons, why we use them, in practice.


[19:35] 
1) To add some one-off fields, to a specific page.. Like the homepage, or a certain landing page.


[19:35] 
2) To add a group of fields to a type of pages, where you want them for some of the contenttype, and you don't want them for some others. (edited)

[19:36] 
When I looked at the places we've used them, there was really no situation that stood out, that would not be more clear (to the end user (editor)), if instead they


[19:37] 
used either a Singleton (in case of `1)`)


[19:37] 
or a named repeater (in case of `2)`)

[19:37] 
So, i would even argue we make it _easier_ for our users if we deprecate them.

[19:38] 
:microphone: :arrow_down: (edited)

[19:38] 
gawainlynch It "un-crosses the streams" too


[19:39] 
bob
To re-iterate, dropping them has THREE mayor benefits:

[19:39] 
- Code-wise it saves headaches

[19:39] 
- It's more straightforward for users

[19:40] 
euhm.. I should've written this down.

[19:40] 
oh, yes!

[19:40] 
- the UX of the templatefields is horrible! (select, save, hard reload, fill in the fields)

[19:40] 
sahassar One use case that we used a lot at intendit was to allow a customer to pick a "page type", so for example we had a base page contenttype with just like title and body, and then they could choose to make it a "gallery-page" or a "video-page" or whatever. We also used them a lot on "single-page" sites where we had a base ct called sections and then they could pick a section type and get the fields for that section. I think one hazard of doing things the named repeater way is that for many clients that gives them too many options, which usually in my experience leads to them making bad choices.

[19:41] 
bob @sahassar Don't you think you can do the same with named repeaters?

[19:41] 
ross my thinking was that we could re-use the named-repeater code

[19:41] 
for a templatefields replacement

[19:41] 
sahassar bob: Yes, that was my point in the last sentence

[19:42] 
ross and then just add a bit of javascript to change the block based on templatename

[19:42] 
bob
@sahassar Ah, ok! thanks for making that clear to me :slightly_smiling_face:

[19:42] 
@ross So, what you're saying would basically make it an _application_ of named repeaters, to mimic the current templatefields, right?

[19:43] 
ross yes

[19:43] 
sahassar Perhaps having a special case for where a named repeater is set to `limit: 1` and adjusting the GUI then would solve that hazard

[19:43] 
ross I could have that ready for 4.0 no problem

[19:43] 
bob If so, that could surely work.. It's close to the second usecase I mentioned, while at the same time allowing to remove a bunch of sub-standard, code/

[19:43] 
@ross I would like that.

[19:44] 
gawainlynch @ross Is that 3.x-able (easily)

[19:44] 
bob
@sahassar : "Singleton Named Repeater Fields" :wink:

[19:44] 
ross Yes, if we do a 3.5

[19:45] 
sahassar bob: Yeah, exactly. The only difference then would be that it isn't tied to a specific template (unless you handle the mapping itself), so I'm all for that

[19:45] 
bob @sahassar Cool.

[19:45] 
carson So deprecate after that feature is implemented?


[19:46] 
bob @ross I _think_ we'll do a 3.5, although if it's up to me, 3.5 will be "thin", as we push forwards to 4.0.

[19:46] 
gawainlynch
@ross Yeah, there can be more 3.x releases … I just want to (personally) shift focus to 4.x once 3.4 is down, but I see there are other bridging deprecations we'll need

[19:46] 
bob otoh, depracate and replace in 3.x would be nice.

[19:46] 
The alternative is "mark deprecated" now and leave as-is, and build it for 4.0?

[19:47] 
sahassar Personally I don't like deprecating without having an alternative in place


[19:47] 
gawainlynch
Depends on how much of a hair puller it is, if it is low hanging pineapples in 3.x, it gives people a nice bridge

[19:48] 
bob @sahassar I'd be dead set against _disabling_ it now, before we have a replacement.

[19:48] 
I see no real problems with marking it as "Note: this will be replaced with something better, come 4.0" (edited)

[19:49] 
gawainlynch I think we've antagonised users enough making jumps hard though

[19:49] 
sahassar bob: I get that, I'm just saying that it is a lot nicer to say "We will be removing this feature, check out this new equivalent thing" than to say "We will remove this feature, please trust us that we will have comparable stuff sometime in the future" (edited)

[19:49] 
gawainlynch ^

[19:49] 
bob
I do see your point though.. It's really just a matter of wanting to push forward.

[19:49] 
Let's do a quick vote..

[19:49] 
(using thumbs up/down)

[19:50] 
gawainlynch Yeah, that's why features only target `master` past 3.4

[19:50] 
bob
option 1: deprecate and drop in 4.0 (tell people to use singletons and repeaters)


[19:50] 
gawainlynch A "bridging" deprecation isn't a feature in this case

[19:50] 
bob
option 2: deprecate now, replace in 4.0


[19:50] 
option 3: deprecate now, replace in 3.x


[19:51] 
gawainlynch
With named repeaters now, what is missing?

[19:51] 
sahassar option 4: deprecate when we can say that we have equivalent functionality and drop in 4.0 (edited)


[19:51] 
bob
Gawain "UX"

[19:52] 
ross If the replacement is feature identical which I'm hoping it will be then just replace?

[19:52] 
bob
@gawainlynch Slightly longer answer: Basically, it is.. It'll just require a bit more effort on the implementor, to configure a named repeater as such, and also to template it correctly.

[19:52] 
sahassar ross: I'm guessing that we can't just drop it from 3.X due to BC

[19:52] 
And also we shouldn't drop features in minors


[19:53] 
carson ^

[19:53] 
bob
@ross If you think you can make it seamless, that'd be the best option. But would that be possible.

[19:53] 
sahassar So unless it works with old fields/configs/extensions/db's then it'll stay in 3.X, right?

[19:53] 
bob
@sahassar Yeah, "dropping" is out of the question, as far as i'm concerned

[19:53] 
ross I'll have to do some preliminary work to see

[19:54] 
bob
@ross So, how about I make an issue, with an `[rfc]` about it, so we won't forget?

[19:54] 
and you can investigate if it's feasible

[19:55] 
ross It may be that there's a few minor inconsistencies because the storage is different and the hydration uses objects instead of decoded arrays

[19:55] 
And we can decide what is best based on how much will change

[19:56] 
bob
Being able to drop the old templatefields code, and having it as a variant of named repeaters would be worthwhile.


[19:56] 
I can imagine that would save a bunch of hair-pulling for 4.x

[19:56] 
ross Everything will be using the same tested codebase then

[19:56] 
sahassar Well, the new does not need to be compatible with the old, only feature equivalent. The old will be deprecated as soon as it is in, and removed in 4.0, so as long as the old works in 3.X the new can work in any way you like as long as it fills the same use-case, right?

[19:56] 
bob
Ok, good idea, @ross!

[19:57] 
gawainlynch @sahassar That would be my thinking on the safest approach

[19:58] 
sahassar I'm just guessing, but trying to be backwards compatible with code and implementations that we have all cursed might not be the best way to pave a new path forward

[19:59] 
So probably safer to think of them as two separate solutions to the same use-case

[19:59] 
bob
@sahassar I think that should be a decision to make, when we have a POC from ross, so we can better assess the risks of that

[20:00] 
sahassar Yep, agreed :slightly_smiling_face:

[20:00] 
bob
Ok, i put "Make [rfc] about templatefields" on my to-do list

[20:00] 
gawainlynch OK … Done … Next, 3.4 beta

[20:01] 
sahassar bob: #5545 btw... when you do, could you close that one with a reference to the new one?

[20:01] 
boltissueball #5545 [open] [RFC] Successor to templatefields https://github.com/bolt/bolt/issues/5545

[20:01] 
bob
Certainly

[20:02] 
3.4 beta... I'm testing, finding minor quirks..

[20:02] 
I know i need to test `nut deploy` better.

[20:02] 
ross I've found one problem with database:export / import with named repeaters that needs fixing

[20:02] 
gawainlynch
Crap … I am about to hit that one tomorrow then, Ross :wink:

[20:02] 
ross I'll tackle that in the next two days


[20:03] 
gawainlynch
FWIW the new code seems to work well, including normal repeaters, on 3.4

[20:03] 
#teamwork

[20:03] 
boltissueball has boiled some water, and begins to brew gawainlynch a nice cup of tea.

[20:03] 
boltissueball Woo, teamwork! https://koala.kx.nu/teamwork.gif

[20:04] 
gawainlynch
@bob What's your timeline on next beta then?

[20:05] 
bob I want to get a fix in for …

[20:05] 
.. for #6870 and #7064

[20:05] 
boltissueball #6870 [open] Exception thrown when title_format uses multiple select field https://github.com/bolt/bolt/issues/6870

[20:05] 
#7064 [open] [3.4] `title_format` doesn't work. https://github.com/bolt/bolt/issues/7064

[20:06] 
bob .. which are closely related

[20:06] 
Hopefully i can get a `[wip]` PR in tonight.

[20:06] 
So, beta later this week!

[20:06] 
gawainlynch
WFM

[20:07] 
Anything anyone needs/wants to raise?

[20:07] 
bob
I'm good.

[20:07] 
gawainlynch #meeting

[20:07] 
boltissueball </meeting> Failed parsing XML: 'hug' expected, No 'love' shown for bot. Program 'meeting' terminated.
Clone this wiki locally