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
[vf] Adding support for parsing EL in script tags #284
Merged
Merged
Changes from all commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
2e073a1
Initial
sergeygorbaty 34b7072
Script EL support added
sergeygorbaty a987c77
Added support for quoted context
sergeygorbaty 2106e99
Revert quoted context
sergeygorbaty c4497d5
Logic bug fix
sergeygorbaty b7946ba
fix for special tags
sergeygorbaty 32762c4
fix for unbalanced quotes
sergeygorbaty 6137baf
More test coverage
sergeygorbaty 1942e94
Bug fix
sergeygorbaty 81c67a5
Fallback for JS arrays and defs
sergeygorbaty b38642a
Merged
sergeygorbaty caf27ad
deleted unused file
sergeygorbaty d12c1f7
Iterative DotExpression evaluation instead of checking the first one
sergeygorbaty 309d2d1
Style fix
sergeygorbaty File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sgorbaty I am curious, how does visualforce handle constructs such as
{!function(){console.log("test");}();}
which, even though ugly, are completely valid JS (prints "test", and evaluates to true).I don't think we will ever be able to tell for sure if what we are parsing is actually EL or just more JS, but I wonder on the impact of not being able to tell them apart...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. The only way to solve this is to have a dedicated JS parser (Acorn/Aspree) added. I could do that but figured we should invest in PMD being able to switch parsers on the fly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sgorbaty how would such parser solve this issue?
{!myVar}
could be either valid JS or valid EL... Even more with JS not needing to declare variables.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jsotuyod this is a parser for VF, not Javascript. :)
VF is a very opinionated platform, which treats {! } construct anywhere in code 100% of the time as EL; therefore, any javascript construct that looks like {!varName} would result in compilation error because there would be a missing property with that name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sgorbaty awesome, that is what I was after! Being that way, then this grammar is correct 100% of the time identifying those as EL. This is the best scenario possible.