I'm trying to figure out if there's a way to get a list of the attributes for custom global Visualforce components in an installed managed package.  Obviously Salesforce is able to do it because they present the list as a table in their own Setup UI, but I can't find anything that seems to provide that information in the metadata or tooling APIs.  Obviously if I try to get the markup/body of the component, the IP protection features of managed packages just return "(hidden)".  Any thoughts?

I'm very far along on an IDE plugin for Apex development and one of its features is generation of an offline symbol table for completion, reference navigation, etc.  After a significant effort I think I've managed to put together the most complete symbol table possible using the Tooling, Partner, and Metadata APIs including the "private" APIs used by the Eclipse plugin, e.g., ApexClassIdentifier.  At this point there are a few things that are still missing to complete it, though, and I'm hoping they're available and I'm just not finding them.  Any insights on these is greatly appreciated!

1. Base class information - The Tooling API supplies the names of implemented interfaces but not the base class, in particular for System classes and classes from installed managed packages.  Without this information I can't reliably provide information about base classes such as potential completions, navigation, polymorphic type behavior, etc.  The best workaround I have for this is to manually supply this information for the System classes in my plugin, but that still doesn't help with classes from installed managed packages that extend other classes.
2. Type declaration information - The Tooling API's "completions" resource provides a decent amount of information about the System types, but one thing it doesn't include is the actual declaration type, i.e., class vs. interface vs. enum.  I'm able to infer that a declaration is an enum because it has a very specific signature that includes a values() method that returns a list of the same type, but I have no way to determine which declarations are interfaces.  As a result, I can't determine whether a type should be valid for extension vs. implementation in local classes.
3. Enum constants - The Tooling API's ApexClass information doesn't include enum constants.  This is less of an issue because in general these files would typically exist in the local filesystem, but in the case that the developer only keeps a subset of the org's unpackaged classes in the local filesystem, the API leaves a gap in the symbols it provides.  I have a workaround for this that allows me to get enum constants for all enums that are public visibility or higher, but it seems like an odd omission.

Thanks in advance for any thoughts on how I might address these gaps!

I'm thinking about putting together a simple plugin for IntelliJ IDEA for Force.com development that uses the Tooling API to provide Apex code completion and symbol navigation.  I've explored the API a bit and understand that you can build a pretty comprehensive symbol table for the code deployed into an using a combination of completions for platform APIs and Apex class symbol tables.  That symbol table represents what's been deployed into the org at that point, but of course in an IDE the user is actively creating/changing code.

Any decent modern IDE provides completion against this work-in-progress code, but I don't see how I can provide this with the Tooling API since the symbol tables are returned as part of the saved ApexClass definition.  Is there a way to get the Tooling API to provide a symbol table for a transient Apex class without actually saving it?  If so, does that work even if the Apex class isn't currently 100% valid?

The documentation for the Tooling API states very clearly that it should be used in place of a custom lexer/parser for Apex, but this seems to be one of a few places I've found where it doesn't seem to provide everything needed to avoid at least a simple understanding of the language locally, another being code formatting.

Any thoughts on this?  I guess that minimally being able to perform completion against the known symbols as of the last successful save is more valuable than absolutely nothing, but this really seems required to provide the expected coding experience.

I can see clearly that the "API Enabled" permission must be granted to a user before that user can invoke the standard platform Web services APIs (CRUD, metadata, etc.), but what I still can't verify for sure is whether that permission is also required for custom Apex REST services.

 

I ask because we'd like to enable bidrectional integrations with our OEM applications via standard Web services, ideally without requiring that the "API Enabled" permission be granted to all of the users that would invoke these APIs.  My hope is that it's only required to invoke platform services and not custom services delivered in managed packages.

 

Does anyone know the answer to this one?  If so, is there any supporting documentation that you can provide?

 

Thanks!

I'm thinking about putting together a simple plugin for IntelliJ IDEA for Force.com development that uses the Tooling API to provide Apex code completion and symbol navigation.  I've explored the API a bit and understand that you can build a pretty comprehensive symbol table for the code deployed into an using a combination of completions for platform APIs and Apex class symbol tables.  That symbol table represents what's been deployed into the org at that point, but of course in an IDE the user is actively creating/changing code.

Any decent modern IDE provides completion against this work-in-progress code, but I don't see how I can provide this with the Tooling API since the symbol tables are returned as part of the saved ApexClass definition.  Is there a way to get the Tooling API to provide a symbol table for a transient Apex class without actually saving it?  If so, does that work even if the Apex class isn't currently 100% valid?

The documentation for the Tooling API states very clearly that it should be used in place of a custom lexer/parser for Apex, but this seems to be one of a few places I've found where it doesn't seem to provide everything needed to avoid at least a simple understanding of the language locally, another being code formatting.

Any thoughts on this?  I guess that minimally being able to perform completion against the known symbols as of the last successful save is more valuable than absolutely nothing, but this really seems required to provide the expected coding experience.

I can see clearly that the "API Enabled" permission must be granted to a user before that user can invoke the standard platform Web services APIs (CRUD, metadata, etc.), but what I still can't verify for sure is whether that permission is also required for custom Apex REST services.

 

I ask because we'd like to enable bidrectional integrations with our OEM applications via standard Web services, ideally without requiring that the "API Enabled" permission be granted to all of the users that would invoke these APIs.  My hope is that it's only required to invoke platform services and not custom services delivered in managed packages.

 

Does anyone know the answer to this one?  If so, is there any supporting documentation that you can provide?

 

Thanks!

We're in the process of evaluating the Force.com PaaS.  We've happily used Perforce as our SCM tool for many, many years, and of course Eclipse (and most other tools) offer extremely robust support for Perforce.  While I've found that the Force.com IDE plug-in and the Perforce plug-in can co-exist, it doesn't exactly seem to be a harmonious pairing.  Operations in Perforce are much more explicit than in other SCM systems, in particular SVN.