Visualforce Markup False Errors

Issue #12 resolved
Mike Bordon created an issue

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 (20)

  1. Nathen Drees

    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: invalid location options.png

  2. Nathen Drees

    Just to pile on, Visualforce attributes are case insensitive, but the validation appears to be case sensitive?

    Example: case sensitivity.png

  3. Scott Wells 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...

  4. Scott Wells 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.

  5. Scott Wells 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.

  6. Nathen Drees

    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?

    2015-07-07_11-33-11.png

  7. Scott Wells 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.

  8. Scott Wells 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!

  9. Nathen Drees

    Thanks, force refreshing it seems to have fixed the location part.

    I do have the custom components in the module: 2015-07-07_12-21-48.png

  10. Scott Wells 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.

  11. Scott Wells 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!

  12. Nathen Drees

    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.

  13. Scott Wells 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!

  14. Scott Wells repo owner

    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.

  15. Log in to comment