Apex Code Development You need to sign in to do that
Don't have an account?
Setup in Dev Console, please say "No".
I heard a rumor that setup is moving to Dev Console. Anyone thing it's true?
Please say it ain't so.
I really am not at all impressed with Dev Console.
First, javascript in a web browser is just not a robust architecture. It's slow. It hangs. I loses some of the regular old browser features.
Second, the best thing about SF it it is mostly just web pages retrieved with HTTP gets. That makes it simple and reliable. It lets you cut and paste links. So you want another developer to look at a field definition, just copy the URL. You want the same window, a new tab, a new tab, just click or right-click and pick where you want the link target in to appear.
Hi Ken,
Salesforce is prominent of adding features with the Point and Click method and Dev console was added after the platform was launched, the Setup would continue to exist.
Have you read it anywhere or can you share the link if possible, we will look into it.
#Safeharbour
Regards,
Ashish
Hey,
I think setup is mostly for admin users, where as the Dev console, as the name suggests for Developers. There is very little overlap, in the skill set of users of these categories. I dont think it would make any sense to move / merge these two.
Do share the source of your information ;-)... Looks like someone is spreading silly roumours,
-Cheers!
Gunish
Please mark my answer as a solution if it was helpful so it is available to others as a proper solution.
If you felt I went above and beyond, please give me Kudos by clicking on the star icon.
However, there MIGHT be some functions that are eventually retired from setup but will still be available in the dev console and other tools. There have been some conversations around this, #safeharbor, and might be what you are referring to.
For example, editing of Apex classes. Although you will still be able to view classes in setup, supporting the edit page which uses an out-of-date editor and some other legacy code should be retired. As I said though, that is just an example.
I heard the rumor in another thread on the Dev boards.
Things like edit apex/vf or no big deal. We always use only the IDE to edit. In fact we have a moratorium on ever editing outside the IED as it messes up the white-space characters and then you can't do a compare in Eclipse and gleaned what lines changed.
For the most part, the less stuff in Dev Console the better as far as I'm concerned. I just do not like heavy-weight applications written in javascript that run in a browser. All I pretty much use Dev Console for is kicking off anonymous apex. I don't like the log viewer that as the log isn't an HTML page. I have to download the log anyway to work on it.
The Dev Console, is pretty much the future of cloud based development. There are great JS based online editors which work great! and So does dev console in my opinion. (look as JSHint.com) With Dev Console, I get the additional advantage of intelligent profiling for my code, and great performance breakdown. Dont think we get that in Eclipse. As far a DIFF and escape characters go. Never had a problem with those as long as you use the right diff tool. PS : Look as DiffDog.
All IDE will eventually end up being in your browser anyways!
-Gunish
Well there are a few things about the IDE I find annoying. My biggest peeve is when you do another metadata operation like a Save, you get locked out until it completes.
But there are still loads of issues for heavyweight JS in a browser. Biggest is browser support. I'm used to FF and like Firebug so I mostly work in FF. I have had Dev Console be real slow or hang in FF, although lately it has been better. I do believe Chrome has a much faster JS engine than FF. I do know of at least one issue with Dev Console in Chrome in that start date on test runs is not displayed correctly. Which versions of which browsers will Dev Console be certified in?
The big thing about source code is I need to compare modules between several sandboxes and production. Also, the ability to scan all source for items. Now maybe all that could be put in the Dev Console. But Eclipse does all out of the box if you extract metadata into Force.com projects. That would all have to be written into the Dev Console. I need to diff foo.cls between SB1 and SB2, will the Dev Console do that? I need all page layouts, vf code, and apex code where API name "my_field_name__c" is referenced. Will the Dev Console do that? Build all that kind of stuff into Dev Console and then it is an IDE. Would it be cool to do that all out of the org without having to extract all the metadata locally? Oh yeah, it would be way cool. But would those features be added to Dev Console? Could the metadata within the org be scanned as fast as local flat files?
As Ken points out, there are a lot of key features that the dev console doesn't have, which is why we stayed away from calling it an IDE. Will we ever? Who knows. It also has its fair share of bugs and performance problems, but it has gone a long way from where it started, and will continue to be getting only better and faster.
With that said, the goal is to NOT force everyone to the developer console. With it, we have build out a more complete set of APIs that Brain Engine and Mavens Mate are starting to use. If you haven't read http://blogs.developerforce.com/engineering/2013/09/updated-force-com-ide-plugin-available-more-on-the-way.html you should. In other words, the Force.com IDE will start to consume the Tooling API and become more rich and performant as well. Like quicker deploys anyone? Please!
Ken, you asked a lot of questions there at the end, and all I have to say is yes. It will have better filtering and searching of all metadata and references. When is another story. Could the metadata within an org be scanned as fast as local flat files? I argue yes, eventually. Salesforce does a lot of indexing and caching. That is why eclipse can take a while when first searching, because it is doing the indexing. With the servers already doing that, image a world where you could go to any machine in the world, pull up a web browser, have your exact same workspace with insanely fast searching and compiling. That would be amazing. It just might take 1, 2, 30 years. Who knows. Do I live in a dream world? Maybe, but I'm a dreamer and dedicated to making that dream a reality!
Well this thread certainly has become a healthy discussion. Now I glad I brought the subject up.
I don't know if there's a DF '14 session on what is new and what the road map is for dev tools. I didn't see one but I scanned 1000+ session when I picked mine out so who knows what I missed.
-Ken
However, I will be around the dev zone most of DF if you feel like picking my brain or ranting about our current tools =). Feel free to message me on here or twitter as it gets closer and we can find a time to chat.
Diff-ing is my favourite subject, I wrote a starter desktop tool a while ago to look at two eclipse projects and produce a report. It was simply a XML Comparison implementation, but since it being desktop, and quite hard coded, was very limited.
I then started to work on an online version of the project, which got put away because of obviously other high priority work.
It would be interesting to know what are other people's experiences with Diff-ing orgs ? or Sandboxes.
I know dreamfactory has a tool which does this as well... but it is quite tardy and dated.
... ... ... ???
Hi Thomas,
Thanks a lot for lending your hand on the Dev Boards!
I would also appreciate Ken for bring this topic up -much ahead of actual incubation.
Regards,
Ashish
Hi Gunish,
Thanks for participating here,
You may have a look at the "DiffDog" for Salesforce.com at the link below,
http://www.modelmetrics.com/tomgersic/setting-up-and-using-diffdog-for-salesforce-com-deployment-validation/
http://www.altova.com/download/diffdog.html
Regards,
Ashish
If all dev goes to the cloud the other essential gotta have is revision history, comparison, and souce control.
The ability to extract any prior version from, any edit session, not necessarily a deployed version, and diff it against the current version, or diff any two prior versions is pretty darn important in any IDE.
Back in the days of command line source control, like SCCS and RCS, you had all that at your finger tips.
Fancy tools are great if you don't have to give up the stuff that was convenient and easy with more primitive tools.