Visualforce Markup False Errors
Issue #12
resolved
For some .page files, the plugin falsely reports syntax errors. Specifically,
Some Apex attribute values result in "Wrong attribute value." Example: <apex:selectRadio ... layout="pageDirection" ... />
(https://www.salesforce.com/docs/developer/pages/Content/pages_compref_selectRadio.htm)
Also, certain controller expressions result in "expression expected." Example: if ({!placeSymbolBefore})
Refer to ConfigStrategyInputFieldNew.page for these and more examples.
Encountered on 1.0-internal-beta-3, but not available as a "Version" choice.
Comments (21)
-
repo owner
-
repo owner
- changed version to 1.0-internal-beta-3
-
repo owner
- removed version
Removing version: 1.0-internal-beta-3 (automated comment)
-
repo owner
- changed version to Unassigned
-
Just noticed this on one of my pages as well. Happens for
<apex:pageBlockButtons location="both">where it doesn't recognize 'both' as a valid option.Also, the intellisense gives me invalid options:
-
Just to pile on, Visualforce attributes are case insensitive, but the validation appears to be case sensitive?
Example:
-
repo owner
I'll take a look at the valid value options for pageBlockButtons and make sure they're correct in the next build.
As for case-sensitivity, I'm currently using XSDs per-namespace to provide completion and validation for the Visualforce system components, and unfortunately XSD validation is case-sensitive. I've looked for ways to configure that, but so far I haven't been able to find anything. As a result, I've considered adding the most common case variants to the XSD to help with this, e.g., reRender and rerender, but obviously that wouldn't cover other less likely variants such as ReRender or RERENDER. It seems to me that the main offenders are the on* handlers, e.g., onClick vs. onclick, and the one you've identified, reRender vs. rerender. I'd certainly appreciate any thoughts you have on whether supporting the common variants would pretty much solve the problem for you or not...
-
repo owner
Aha! I figured out how to make this work now. I'll be posting an update with case-insensitive resolution/validation for component and attribute names as well as constrained/enumerated attribute values plus a fix for pageBlockButtons>location in a bit.
-
repo owner
Version 1.0.5 uploaded with case-insensitivity in Visualforce and corrected values for apex:pageBlockButtons>location. This doesn't address IDEA's HTML editor thinking that Visualforce {!...} expressions are invalid in certain contexts so I'm keeping this issue open for that aspect.
-
Scott -
I'm still seeing invalid values suggested in
<apex:pageBlockButtons>, same values as before. I'm on v 1.0.6.I'm now also seeing an error about the
c:namespace being unbound, any way to fix that?
-
repo owner
Weird...I just reproduced this as well. I'll look at the XSD and see if for some reason the changes I made didn't get checked in. Should be something I can turn around quickly...
As for the c: namespace, that should work. Obviously I can see the bad behavior in your provided screenshot, though. Let's start with the simplest possible reason...do you have that custom component in the local module source? Right now IC does require that for completion/resolution. I'm not pulling down custom component definitions into the offline symbol table currently. It's something I want to address, particularly for global access custom components from installed managed packages. Let me know and I'll try to hunt that one down quickly as well.
-
repo owner
Okay, so the good news is that the newer plugin does seem to have the corrected XSD in it. Evidently IDEA's caching virtual file system is hanging onto a previous version of it. I was able to get the correct behavior by asking IDEA to force sync/refresh. I can confirm that by navigating into XSD using either CTRL+B or CTRL+CLICK on the "location" atribute. It should refer to "pageBlockButtonsLocationEnum" instead of "locationEnum". Can you click into that and, if you see the wrong definition, use either CTRL+ALT+Y or File>Synchronize and see if it updates to the correct definition?
Hopefully that'll solve at least that one for you... Assuming it does, I'll see if there's a way I can force the IDE to refresh those before using them so this is seamless across upgrades knowing that I'll be evolving/fixing those XSDs over time.
Let me know!
-
Thanks, force refreshing it seems to have fixed the location part.
I do have the custom components in the module:
-
repo owner
Okay. I'll take a look this evening at how I'm resolving local custom components (c: namespace) to their definitions and see if I can find any reasons why this might be happening. Do you mind looking in your idea.log for any diagnostic information that might help, e.g., stack traces? It should be a properly bound namespace with full completion, integrated documentation, and reference navigation for the custom component and its attributes.
-
I actually cannot reproduce this anymore. I rebuilt my OST, and this went away. I think it was just a bad OST? For now I wouldn't worry about this.
I did find another attribute that needs updating -
<apex:outputField label="">label isn't recognized. It's not in the XSD in 1.0.6 either.
-
repo owner
Just to clarify, when you say you can't reproduce "this" anymore, are you referring the unbound "c" namespace for the custom component or something else?
As for the other missing attributes, thanks for sending those on. I put together the XSDs for all standard VF components manually over a period of a few days and, as you can imagine, it's a pretty tedious process. The end result is quite valuable, but obviously in that tedium I missed a few attributes and/or wired in the wrong enums. Hopefully there aren't many more to be found before they're 100% accurate for the current API version!
-
Yes, it appears that if your OST is out of date or not in the right location, it doesn't know what the
c:namespace is. Fixing the OST fixes this too. -
repo owner
Thanks for the update. I'm fixing some of the bugs that you and others have reported in the past day or two now. These two annotations that I missed (InvocableMethod and InvocableVariable) are...interesting. They're the only ones I've seen that take annotation params that aren't comma-delimited!
When I first added parser support and then started testing them, my parser wouldn't show errors but the APIs would. Then I looked closer and of course saw that my assumption of a comma-delimited annotation param list wasn't correct. I wonder if that was their intention... I may reach out to Josh K. about that.
Anyway, I'm just about finished with fixes for apex:outputField>label, not deploying (vs. compiling/validating) when there are local parse errors, and of course support for these two annotations.
I really appreciate all the quick and patient feedback you're providing! Keep it coming!
-
repo owner
Uploading 1.0.7 now that fixes apex:outputField>label from this issue.
-
repo owner
- changed status to resolved
I think I've addressed all of the problems reported in this particular issue with the XSDs and such. The main outstanding issue is around Visualforce expressions being interpreted as invalid by IDEA's native HTML/Javascript/CSS support. I have another enhancement issue to address, so I'm going to resolve this one that had become a more general purpose dumping ground. Feel free to open new issues on specific instances.
-
repo owner
- removed version
Removing version: Unassigned (automated comment)
- Log in to comment
Fixed the values for the layout attribute in selectCheckboxes and selectRadio.