These are chat archives for WebDevStudios/CMB2

1st
Sep 2015
Justin Sternberg
@jtsternberg
Sep 01 2015 00:05
Yes, absolutely agree. So I take it your testing user profile fields as well
PG Lewis
@pglewis
Sep 01 2015 00:05
yeah, user profile mb as in the example functions
it looks like the example functions registers an options page mb that's never hooked up, as far as I could find, so I replaced that one with the example code from the snippet lib
what I test against will grow as I go along too, I'll pull more from the snippet library, or any other source for testing stuff I can get my hands on
Justin Sternberg
@jtsternberg
Sep 01 2015 00:08
You're right about options page snippet in example functions
PG Lewis
@pglewis
Sep 01 2015 00:09
at least not an indicator that I'm going crazy yet
Justin Sternberg
@jtsternberg
Sep 01 2015 00:09
Another good test bed would be the third party addons: https://github.com/WebDevStudios/CMB2#3rd-party-resources
yah, not yet. :P
PG Lewis
@pglewis
Sep 01 2015 00:10
I'm always careful to be clear with my language, there is no definitive proof that I'm not going crazy, after all
and yeah, custom field types are high on my list of testing to expand to
currently back to evaluating if I can just remove the redundant field arrays stored
that branch is instantiating field objects when they're created now, so objects always exist
and the arrays keys are accessible via ->args, so we can still return that when requested
PG Lewis
@pglewis
Sep 01 2015 00:15
but keeping both an array of arrays and an array of the objects seems redundant and full of confusion for me lol
pitfalls with back compat for sure, but I'm still slowly working around them
Justin Sternberg
@jtsternberg
Sep 01 2015 00:16
agree, it's pretty terrible.. updating one of the arrays in the array doesn't update the corresponding object
PG Lewis
@pglewis
Sep 01 2015 00:16
I /think/ it can be done
just harder than I originally thought lol
Justin Sternberg
@jtsternberg
Sep 01 2015 00:16
worst case, can re-build the array on the fly if the fields array is requested, right?
PG Lewis
@pglewis
Sep 01 2015 00:17
still, tests will improve regardless of whether or not this experiment proves worthwhile
and that's nearly as important as making this branch work
unsure what to do if it's just not viable to remove the arrays
I'm still working under the stubborn assumption that it'll be doable, but not pretty in spots
and then evaluate where it lands and decide if that's better than where it started or not
but it clears up one potential issue of nesting fields in other ones
as objects will always be available and can be found by ID (you don't necessarily need an object ref if you have ID)
which could in turn mean the original syntax scott tried might be feasible
or something very close to it
since now having a field ID DOES mean you have access to the object
Justin Sternberg
@jtsternberg
Sep 01 2015 00:20
that would be awesome.. a unique id per field, yah?
basically a handle
PG Lewis
@pglewis
Sep 01 2015 00:21
still just using the same IDs for fields
Justin Sternberg
@jtsternberg
Sep 01 2015 00:21
based on "as objects will always be available and can be found by ID"
PG Lewis
@pglewis
Sep 01 2015 00:21
if it translates as a straight refactor, I think what I'll end up with is an args->fields[] array of more field objects for nested ones
Justin Sternberg
@jtsternberg
Sep 01 2015 00:22
I see
PG Lewis
@pglewis
Sep 01 2015 00:22
same array keys for the object list right now as the array list
as the branch stands, so it's been easy to start converting sections of code that were referencing the arrays
just point them at $field_objects instead of $fields_array
and refactor to call through to ->args on the object for the arrray stuff
current state is I'm still keeping both parallel but soon will drop the arrays hopefully and see how bad it blows up
and all of it seems to be working except for group fields, which was known it would be broken
none of that has been comitted or pushed yet though
no-fields-array is probably just a clone of no-metabox-array right now in the repo
PG Lewis
@pglewis
Sep 01 2015 00:28
the no-metabox-array branch is just the refactor to remove the $meta_box property and transition to object props and I think that's viable
the no-fields-array branch will build from there, taking it the next step of trying to rid the field arrays... tougher
a unique ID per field-- a field GUID-- would be a great idea because it removes the need to have the parent ID for nested fields
but it has to work with the field ID / parent ID for back-compat first, so I'm starting the refactor that way
PG Lewis
@pglewis
Sep 01 2015 00:33
thus field IDs only should need to be unique within their field group
which is how it is now, pretty sure
Justin Sternberg
@jtsternberg
Sep 01 2015 00:35
yep, that's how it is currently, but seems to me we should generate a guid and store it as a field object property
and add_field could return that guid
PG Lewis
@pglewis
Sep 01 2015 00:36
I like that idea as an enhancement if we get it that far
Justin Sternberg
@jtsternberg
Sep 01 2015 00:36
yah for sure
PG Lewis
@pglewis
Sep 01 2015 00:36
simplifies things from the consuming side of the API
Justin Sternberg
@jtsternberg
Sep 01 2015 00:37
and that guid could maybe be generated programmatically by parsing all the field parents so that it can be reverse-engineered to figure out its nesting level.. may be too ambitious, but a thought
PG Lewis
@pglewis
Sep 01 2015 00:37
and, yeah, for back compat, I think we can just foreach and dump each object's args for calls to cmb2::fields
Justin Sternberg
@jtsternberg
Sep 01 2015 00:37
or I guess parent guid, like a term's parent id
to get to the top, keep checking parent guid till it's 0
PG Lewis
@pglewis
Sep 01 2015 00:38
pulling the stack and answering something you asked a while ago :)
Justin Sternberg
@jtsternberg
Sep 01 2015 00:39
got it
PG Lewis
@pglewis
Sep 01 2015 09:01
with the main field array done away with, field objects always instantiated, and fields and the metabox extending the field group object, nested field handling issue mostly evaporate:
cmb2-nested-data.png
the metabox and fields both have access to the field management functions and can add fields to themselves
so there's nesting two levels right there, and it theoretically should support arbitrary levels
still clean up to do, but that there's a breakthrough
PG Lewis
@pglewis
Sep 01 2015 18:08
discog-nested-01.png
Scott Kingsley Clark
@sc0ttkclark
Sep 01 2015 18:08
So beautiful
@jtsternberg ^^ phil just got that happening
Justin Sternberg
@jtsternberg
Sep 01 2015 19:25
would you look at that!
nice work @pglewis!
PG Lewis
@pglewis
Sep 01 2015 19:25
don't ask if it loads or saves data
Justin Sternberg
@jtsternberg
Sep 01 2015 19:25
ha ha
pglewis @pglewis hand waves past that
PG Lewis
@pglewis
Sep 01 2015 19:26
proof of concept achieved though
Justin Sternberg
@jtsternberg
Sep 01 2015 19:26
absolutely
Scott Kingsley Clark
@sc0ttkclark
Sep 01 2015 19:39
thoughts on anything there we could apply to CMB2 itself?
in terms of UI
Justin Sternberg
@jtsternberg
Sep 01 2015 19:41
I like the hover-highlight thing, though I think it could be a little more subtle. What else do you have in mind?
Scott Kingsley Clark
@sc0ttkclark
Sep 01 2015 19:43
just threw that out there in case it was something we could reach into for the CMB2 refactor of the frontend
any plans for time on backbone / etc there for you? know anyone we could reach out to for additional help?
PG Lewis
@pglewis
Sep 01 2015 19:49
the time is now for me to get onboard with backbone anyway, so within a week I'll be a fledgling resource there
Justin Sternberg
@jtsternberg
Sep 01 2015 19:50
based on your work so far, that's an encouraging aspect.
@sc0ttkclark my only thought is possibly @ericandrewlewis would be interested.
PG Lewis
@pglewis
Sep 01 2015 19:51
my js is reasonably solid and backbone isn't a giant library thankfully
Scott Kingsley Clark
@sc0ttkclark
Sep 01 2015 19:59
i'd like @pglewis and us to focus on the backend, there's much more to do on the pods implementation, so if we can get @jtsternberg and possibly @ericandrewlewis on the front, life would be much much better
Scott Kingsley Clark
@sc0ttkclark
Sep 01 2015 20:28
eric doesn't really use CMB2, so may not be a great fit overall there
PG Lewis
@pglewis
Sep 01 2015 20:54
@jtsternberg: this sort of thing will be needed some in the tests:
pods-framework/CMB2@949884
cggit
@cggit
Sep 01 2015 20:54
im using a cmb2 textarea_code to store some JS but its converting & to & is there a quick way to prevent this?
PG Lewis
@pglewis
Sep 01 2015 20:55
the straight array to array comparison breaks if new elements are introduced
Justin Sternberg
@jtsternberg
Sep 01 2015 20:55
'escape_cb' => false // to disable
@pglewis yah, that's fine
PG Lewis
@pglewis
Sep 01 2015 20:57
I'll collect 'em all and submit a PR at the end of the rabbit hole here
cggit
@cggit
Sep 01 2015 21:10
@jtsternberg with escape_cb false it still goes from the &.a.m.p.; to &
Justin Sternberg
@jtsternberg
Sep 01 2015 21:11
@gc
@cggit then you may also need: 'sanitization_cb' => false // to disable
cggit
@cggit
Sep 01 2015 21:16
@jtsternberg thanks I had looked there but failed. Having both set to false didnt work but only having the saniatize_cb false did the trick