Weird values about flll HOT 3 CLOSED

this is generated stuff from widgets.
shouldn't be to hard to improve.
Looks like Hex is used 0-f

e.g if this regex is matched it is your value.
([0-9a-f]{14}.[0-9a-f]{8})

Maybe the ids behave differently depending on nesting...

from flll.

@xf- I think the problem (or rather cause) is that the template in question:

• Declares a dynamic "name" for the object
• Does not declare a "label"; neither hardcoded or as fixed LLL:EXT:... or LLL:name reference

What we would be doing by preventing the generating of labels in EXT:flll would just be treating this symptom and it really is hacky. We can't predict if the next use case uses another way to make the "name" dynamic and we'd just have to support that, too. Instead of fixing it at the source.

I suggest telling the template author to use label="LLL:nameOfKey" on the sections/objects/fields which have dynamic names. This ensures that the data is saved with dynamic indexes, but when resolving the label, Flux detects the "LLL:" prefix and instead of building the expected key according to nesting etc., it will look up that value directly - thus completely preventing this problem regardless of the nature of the dynamic "name".

PS: the name in this case would case some strange effects when "thawed" from XML to an array. An additional nesting would be added because the dynamic part contains a . - either that, or there are two dynamic segments at work here. The "LLL:" solution will also prevent that but you may need to add the "label" in more than just the one place - depending on the template.

from flll.

Will take the liberty of closing this and the related PR with reference to the "proper" solution described above. Although it entails a bit more work it also results in a much better solution where the LLL reference is predictable and reusable.

from flll.