Obtain Label" metadata property of field in renderer"

Hi Barry,

field.label is the value that should have this information. This actually works correctly for the table component. I’ll put this down as a bug in the field editor component. I think because of this bug, this is not currently possible without parsing the xml of the field editor component yourself. Which would be a total drag.

Thanks Ben.  Should this be marked as a Problem instead of Question?  Also, while your in there, a few related issues that are causing similar difficulties:

https://community.skuid.com/t/overridden-field-metadata-not-used-when-model-is-marked-to-process-client-side-update-7?rfm=1&topic_submit=true

https://community.skuid.com/t/length-not-enforced-when-overriding-field-metadata

https://community.skuid.com/t/merge-syntax-not-processed-when-overriding-label-on-model-field?rfm=1&topic_submit=true

https://community.skuid.com/t/field-editor-labels-built-using-merge-syntax-do-not-update-when-model-changes-occur?rfm=1&topic_submit=true

Thanks!

Ha! I see what you did there.   Thanks for all your recent postings Barry.  We are looking into them and will respond.  You just give us such thorny problems that it takes us some time to really understand what’s going on… 

Like that one huh?  :)  In all seriousness, the combination of all of these issues has me pretty well stuck on several fronts.  Appreciate you guys (expeditiously) reviewing and addressing.  Thanks Rob!

This issue is now resolved as of Banzai - Update 7.4, available via Skuid Releases.

Hi JD -

I tested this with Update 7.4 and the field.label no longer contains the model label as it did prior to Update 7.4.  Unfortunately, the string value exposed to the custom renderer on field.label has already gone through merge syntax processing so there still is not a way to obtain the actual field level override in its raw form that was specified in the field editor.

For example, if the label override on the field editor is “Name is {{Name}}”, I would expect field.label to contain “Name is {{Name}}” not “Name is JD”.  

Is this something that was overlooked?  Expected Behavior?   I would think that merge processing would occur during the rendering of the HTML itself but not the “metadata” that was specified during configuration on field.label.  

On a related note, in order to tackle the issue identified at https://community.skuid.com/t/field-editor-labels-built-using-merge-syntax-do-not-upda…, I would anticipate that leaving field.label in its raw form would be required in order to properly respond to changes in model data.  Instead of using text() during rendering as Skuid does currently when building the label elements, I’m thinking, more than likely, a TemplateComponent will be used to address this issue in which case the raw property value would be needed.

Look forward to your thoughts.  Thanks!

Hi Barry,

I think I agree with you on all these points, and Skuid is not being consistent. Just to clarify, here are the steps I think we should take.

1. Label overrides should be sent to custom renderers raw, and un-merged, no matter whether they originate in the field metadata label override, or in the field component label override.

2. It should be up to the custom renderer author to use the correct skuid apis to populate the merges manually.

3. Skuid should correctly merge label overrides in its standard renderers no matter whether they originate in the field metadata label override, or in the field component label override. (I believe there is currently a bug where field metadata label overrides are not being correctly merged in standard renderers)

Am I understanding this right?

You’ve pretty much nailed it Ben.  My thoughts are Skuid core/runtime pass in raw (unmerged) and renderer is responsible for renderering.  This would apply to things like helptext, etc., not just labels.

Regarding standard renders, is currently uses “text(…)” to set the value of the div.  My thought is that it should use a TemplateComponent passing it field.label (which would be raw/unmerged given the above) and then you’d solve the issue at https://community.skuid.com/t/field-editor-labels-built-using-merge-syntax-do-not-upda…

By the way, I think the model merge issue you’re thinking of is here: https://community.skuid.com/t/merge-syntax-not-processed-when-overriding-label-on-mode…

Thanks!

Great, I’ve got these issues recorded. I think if we change how things are sent into custom renderers, it would have to be done in a Major update (Skuid 8).

Makes sense, thanks again Ben!

Hi, Barry. I’ve been working on this for the Rockaway release, and I think I’ve got it sorted in our dev environment (pending review now). The actual rendering of the label on the screen is still going to be the responsibility of the Component itself (no change there). We’ll now send the raw value to the field renderer via the options object, i.e.:

skuid.snippet.register('customFieldRenderer',function(field,value) {<br> console.log(field.options.label);<br>});

It looks like we weren’t even sending the help text value, so we’ll now be sending that in the options object too (field.options.inlineHelpText). As before, field.label will still contain the text of the field’s label (i.e. the merged value). This way, anyone who was depending on that merged value won’t get caught off guard, but there will now be a way to get the raw value, if you need it.

We’re tracking the issue of the labels not updating on model changes separately, but when we have a fix for that one, we’ll let you know. Thanks again!

This is great J, thank you!

This fix is now available from Get the Latest Skuid Releases & Everything That Came Before in the Rockaway Release.

Tested and confirmed with Skuid 8.8.  Thank you!