Apex Code Development You need to sign in to do that
Don't have an account?
garyb Handling variable differences between environments
Would like to hear other people's opinions on this thorn in my side...
I'm trying to tidy up some parts of the application I'm developing by limiting the impact of (for example) ID changes between environments. In a Java environment, you could hold this sort of information in .conf files.
For example, let's say I have a VF page that contains links to certain list views. These list views are not likely to have the same ID in my Dev org as my Production org. How best to manage this? Hold it in a static variable in one place in code? Downside there is I have to update the code with the values for Production before I deploy. What about a custom setting? Custom Setting objects are deployable, but the records are not so I'd have to import data into the production org first, and makes deployment more complicated.
What are people's best practices/workarounds for this sort of situation? The above is just an example rather than a specific problem (though if there is an elegant solution to that problem, I'd love to hear it).
Hey
Custom settings are good but they way they're used is a bit strange. I don't find the many-records-per-custom-setting thing equates very well .properties/.conf files but it is a lot closer than what we had before (nothing).
Recently I've gotten a bit tired of using a triangle peg in a square hole so I thought why not get as close to .conf files as possilbe. How could you do that? Static Resources of course. Upload your properties files, build a small key-value parser and have a class that declares all your static vars but references the static resource for values (Map would work well). Note that you can select records from the staticResource object so it's all quite viable. I haven't implemented any of this just yet but I'm quite certain you'll have everything you need to do it.
Wes
And you can use this to edit your properties files: http://www.tgerm.com/2010/04/edit-static-resource-eclipse-forcecom.html
Wes
Wouldn't work with managed packages...
Oh managed packages.. what sneaky fellows they are. Refresh my memory, is it because something isn't packageable (Static Resources?) or is it the namespaces that have some side effect?
Wes
Wes, the geek inside of me loves the roll-your-own parser idea, sort of thing I could see myself doing to distract me from the other stuff I'm supposed to be doing ;) We're not going to be packaging this application either, so that's not an issue either. Might be a nice feature to be added as standard actually, I'll think about raising an idea...
I don't mind the "many-records-per-custom-setting" of custom settings so much, what I do mind is that it throws a spanner in the works for deployment. Off the top of my head, you'd have to deploy the custom settings, populate them on the destination org and then deploy anything else (triggers, code etc) that use the custom settings. Plus it breaks the rule of "don't rely on data being in a target org".
Thanks for the suggestions though :) Anyone else care to weigh in with their opinions and solutions?
Actually, I was misled by an unanswered community board post. You can edit Static Resources in managed packages. I think I might roll your solution Wes, though the parsing options we have available to us seem a bit limited...
Which would you use?
There's a Java util class that I used to use.. can't remember if it was mine or part of a lib. But on this platform I'd probably just use key-value pairs; each on a line of their own separated by '=' or something similar. Nice and simple.
Wes
Dunno. If you are going to do that might as well go straight up XML. I'll see if I can find time to try something...