Apex Code Development You need to sign in to do that
Don't have an account?
BBeaird Javascript access to standard page components/DOM ID's
Is there any way I can access the fields on a standard page with javascript using the $Component function or something similar without needing to hard-code the element ID?
I'm using the standard asset page. I have a button that calls a webservice to update a couple fields on the page. I would like to write some additional javascript to update the appropriate fields on the page without needing to initiate a page refresh. I know I can probably accomplish this by hard-coding the element ID's based on what I see in the generated page source, but I know that's not a good practice. All the javascript component documentation I've found assumes you are doing a visualforce page, but I really need to figure this out from within the standard page, where I have no control over what ID's are assigned to components.
hi,
you can use like this...
<apex:commandButton id="cmdNextProduct" value="Next" />
No, this is actually for the standard asset page, so I can't do that. I have no access to the actual page code to set ID's like that manually. I need to know what ID's salesforce uses by default.
There is no way that you can do this on standard page and you rightly mentioned using hard coded ids is not the good idea to do this. If VFP does not suits to you then no way to do this.
You have two real choices: 1) use screen scraping methods, or 2) use the hard-coded ID values.
I used the former method once in a Field Level Help integration (now defunct due to changes in browser XML reading APIs, and largely obsolete, thanks to standard functionality released after my code was). This was done by using the field's label as the selector. Of course, it's not foolproof: if an administrator creates multiple fields of the identical label, then there's no way to identify which is which using this method. And, of course, you have to translate the label for each language to be used (my code handled this by detecting the user's selected language).
The latter method is the usual manner in which fields are used (e.g. custom buttons). Hard-coding is, as mentioned previously, a generally bad idea. However, in the six years of working on the platform, I have never observed a standard field changing its ID value, and I believe those values have been consistent since salesforce.com's public release in 2000 (I don't have any way to prove or disprove this, however).
Both methods should be considered unreliable at best, but if you have a compelling reason to do so, and you do not mind the risk that your integration will break in the future, then by all means, use those ID values. I'd recommend that you use a configuration block so you can easily change your code in the future:
var config = { 'field1':'acc1','field2':'acc2' ... }Then, you can reference a field's translated name, using something like config['field1']. It should ease changing your code later if something breaks.
Or... use a VF page. This is what VF was made for. You can use the standardController attribute to create a page that can completely override the standard system page.
Thanks for the response. I realize that VF was intended for just this purpose, but for now, we are still trying to use standard pages wherever possible because we do not have an abundance of Salesforce programmers around here and are not ready for a lot of custom code floating around. We will probably stick with using hard-coded id's for a while longer.