Salesforce IdeaExchange
Saved Items
Alternative Ajax Libraries
It would be nice if there was support for some other Javascript/Ajax libraries. I'm not sure if their are barriers to using them in salesforce which led to the decision of using Dojo but The option to use: Prototype, JQuery, or YUI would be very cool.
Make managed packages less restrictive / more intelligent
Making an application "managed" is a big step. Immediately several items become frozen and fixed for all time. Although many of these make sense to permit upgrades, many are unreasonably restricting and do not allow for "normal" evolution of an application over several versions.
Take one example: the text comments in a help popop on a custom object field. They can't be altered after going managed. If user feedback says that the comments aren't helpful enough - tough luck. If the use of a field changes - again tough.
This example is one where the AppExchange system could permit the developer to make the change in the package - and then all future installations of that package have the new text. Anybody that has already installed that app and customised the popup help text would keep that customisation. The change to the managed package would only affect new installs.
There are several examples of the above intelligent approach to managed package upgrades.
Another big example is to permit items to be depreciated. This includes custom objects, fields and scontrol. These would be flagged as "no longer used". Or better still, not included in new installs of the package. Like the previous example older installations would not have the depreciated item automatically removed (although they could be given to option too if they wish).
AppExchange standardized packaging of App config/properties
It would be nice if we could provide a (free as in edition limits wise) special custom object per AppExchange app installed for configuration properties of the application.
Giving developers the ability to store Application configuration as custom fields on this object using any or a subset of the available field types.
The record type (a singleton enforced by a trigger) for org wide configuration, the second record type for user specific configuration, so values from this are both available as global merge fields for the developer. And can be easy configured/adjusted by the admin, having an consistent ui/interface to this objects edit view via the setup admin area as well as audit trail of changes made.
Many apps implement the org wide config with a custom object storing key/value pairs and a custom scontrol ui, and then user specific config as custom fields on the user record which is fine, it would just be nice if we acknowledged this need for storing application preferences/properties and provided a more standardized way of achieving this.
Being able to set default values when packaging applications would be a logical enhancement to this functionality as well.
The object names could be easily generate e.g.
config_namespace__appname__c
As well as the global merge fields:
{!$Appname.Property}
Perhaps just making this another benefit of managed packages initally would be the right approach.
Intellectual Property Rights- Code Protection
One of the major drawbacks of Salesforce is that the s-controls which we code are exposed to the clients, who if are resellers they tend to be at an disadvantage.
A partial solution that we can have by "Manage Packaging" our code in which we mode as much as we can on to Apex as then it is hidden from users.
With Visual force around , will it help us in sheilding our code from the users?
We have tried "Obfuscation" but it at times causes some issues. We would suggest Salesforce comes up with some in built API for hashing code.
Thanks and regards,
Ispita Saha.
POST IDEA