Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consistently handling whitespace in property names #74

Open
karger opened this issue Aug 10, 2012 · 2 comments
Open

Consistently handling whitespace in property names #74

karger opened this issue Aug 10, 2012 · 2 comments

Comments

@karger
Copy link
Contributor

karger commented Aug 10, 2012

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.

@karger
Copy link
Contributor Author

karger commented Sep 9, 2013

Small correction: a white space causes the expression parser to halt and output a token; it doesn't elide whitespace.

This is a real problem for people filling exhibits from google spreadsheets/forms, where it is natural to use multi-word column headings.

@karger
Copy link
Contributor Author

karger commented Sep 9, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant