You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a data file, property names that contain spaces are parsed with those spaces, so we can have properties such as "Last Name". However, when expressions are parsed in exhibit (e.g., ex:expression="Last Name"), the parser skips over white space. It thus becomes impossible to actually refer to a property containing spaces. This should be resolved. One option would be for the data parser to elide spaces in property names (possibly preserving the name with spaces as the "label" for the property). Another option would be to specify that e.g. underscores in expressions (and possibly in property names) are interpreted as spaces.
The text was updated successfully, but these errors were encountered:
I haven't been able to think of any case where making the expression parser whitespace sensitive on property names would suddenly break it. Since the current implementation chokes on whitespace in expressions, this should be strictly more robust.
In a data file, property names that contain spaces are parsed with those spaces, so we can have properties such as "Last Name". However, when expressions are parsed in exhibit (e.g., ex:expression="Last Name"), the parser skips over white space. It thus becomes impossible to actually refer to a property containing spaces. This should be resolved. One option would be for the data parser to elide spaces in property names (possibly preserving the name with spaces as the "label" for the property). Another option would be to specify that e.g. underscores in expressions (and possibly in property names) are interpreted as spaces.
The text was updated successfully, but these errors were encountered: