Month: March 2014

Looping Slideshow Display With Visualforce and Apex Charting

Anyone ever seen pictures of west-cost start-ups with those TV screens front and center showing some sort of stat or metric? If it is a dev house maybe it is the builds, bugs, & deadlines. A sales firm may have revenue, opportunities and a highlight of recently closed deals. Either way, they are meant to highlight data and allow it to be consumed in a very passive manner, reading it as you pass by. Salesforce makes reports a breeze and dashboards are a snap too. However, what if you wanted to recreate that seamless look, without the tabs, browser UI, or any indication of what is driving the display at all? Sure, there are tons of articles that show you how to get PowerPoint to do that, but using stale data is for suckers. Let’s take a look at what some Apex, Visualforce and JavaScript could do for you.

We should start with the controller.

A good start but missing any real meat. Let’s look at what is there, shall we? Pretty much the only thing in this class so far is a nested wrapper class. This is just a convenient way to get data to the charts. Feel free to do your own thing if this isn’t your style. We better add a way to get some data.

This looks promising! This method grabs all the cases, groups them by priority, then counts the number of cases in those groups. We iterate over that data and toss it into that wrapper object from the prior code block. Add as many of these chunks of code as you want, one for each chart you feel like creating. We are almost done the controller, just one more piece.

This to-the-point bit of code is there to erase the current set of data so it can be refreshed. Remember what I said about stale data being for suckers? This prevents you from being a sucker. Put all of those together and you get a completed controller (mine has a second list of chart data because a one slide slideshow is boring).

On to the Visualforce. We will start off small again and build from there.

This is the base, telling the page to use the ChartController and to not show the header or sidebar. Remember, we don’t want this looking like a webpage or a browser, just a slideshow. Now we need a chart.

This is an apex chart. The width and the height shown here are based on my screen size and layout. If you have extra styling or branding on your slideshow (Trust me, you will want it. The end result of this is bare bones.) you will need to change these values to fit. The apex:chart tag also tells the page what data to use and the id will be used to keep the data fresh. The apex:pieSeries tag tells the page that the data comes from the data field on the wrapper and that the label comes from the name field. There is also the apex:legend tag which provides a legend in the position specified. Finally all of that is wrapped in a div that will provide us the means to allow for movement. Like with the controller, you need one of these for each list of ChartData that you created, just leave the ‘activeSlide’ style off the rest. We still need to code to bring this to life. Let’s begin with the styling first.

Simple stuff here. The ‘side’ class has an absolute position, a white background and is glued to the top left. Every slide has that and therefore, every slide is stacked on top of each other. The slide that also has the ‘activeSlide’ class rises to the top, thanks to its high z-index. To make these slides shuffle, we also need some JavaScript.

First off, I am lazy at times. Seriously, no joke. That is why I included JQuery, because it makes things so darn easy. The next bit sets up a JavaScript method named ‘refreshCharts’ that calls the controller method ‘refreshCharts’ and re-renders my two charts with that data. This is done with the apex:actionFunction tag and will automatically generate the appropriate code. After that, I set up another JavaScript method that will determine the next slide, remove the ‘activeSlide’ class from the currently visible slide, and add it to the next one. To set things in motion, I call that method every 5 seconds and the ‘refreshCharts’ method every 10 minutes. Mix it all together and cook at 350 degrees and your Visualforce should look like this:

What does this look like in action? A chart, then another chart. This is not worth a picture because a still image won’t show it in action and an animated gif can be staged. The best way to see this is to follow along and get this code into any developer account. After you do that, just type in the URL, ‘<YOUR_SALESFORCE_URL>/apex/<YOUR_VISUALFORCE_PAGE_LABEL>’. Tapping F11 should remove all of the browser UI and dragging the mouse to the right side will hide it from view. There you go, a live slideshow. This is the perfect project to dedicate some old hardware to.

Apex Analyzer Dev Diary

Well, this is an interesting situation. When I started this blog, my intent was to do reviews, news, and the occasional small project. My post series on using Heroku to host a personal site was just that. My last post which laid the ground work for an Apex static code analyzer took a good deal of time but would have been fine if it ended there. It didn’t end there though. In fact, I poured a pile more work into it this week to hook together the express framework as well as an sqlite database. If you have been watching the git repo, you have likely noticed…. nothing at all. The changes are so drastic, I cannot commit until I have at least the functionality I had before. No real post this week but I wanted to keep people in the loop.

CLI showing the output of the program

Static Code Analysis of Apex

Would you wander down memory lane with me? It was on one of my first projects at Trifecta that I was introduced to Sonar (now SonarQube), a dashboard that aggregated results from a pile of code analysis tools and presented them in a visually appealing way. I loved the kind of insight it provided.When it listed a bunch of unused methods I went to work pruning them. When it found string concatenation in a big, heavily used loop, I replaced it with StringBuilder. When I moved over to Salesforce, I found a number of solutions but most were either costly or incomplete.

SonarQube dashboard
Different name, same usefulness.

I did manage to find a wonderful blog post, written by Andrew Fawcett, which covered using the tooling API to call out methods that are not referenced anywhere and display it on a Salesforce canvas. This was exactly what I was looking for, or at least it had the potential to be. You see, finding unused methods is a great help once a code-base becomes large and complex enough. Removing these relics could reduce your code-base and may reduce your unit test and deploy time. That is what makes unused method finding, my top feature to have. Even so, I wanted more, and given the choice to extend his project or make my own, I of course made my own.

GitHub new repository button
As if this was even a choice.

I started off with Node.js (bffs 4 lyfe) for no other reason than “I wanted to experiment with it.” Then I reimplemented¬†Andrew’s solution using the node-salesforce module to handle authentication and CRUD operations. Finally, I added a basic plugin system to allow for new checks to be added. How did that all turn out? Let’s find out.

CLI showing the output of the program
Well, it’s a start

I hate to say it, but Node may have been a mistake here. Don’t get me wrong, I had a lot of fun doing this, but there is a fundamental difference between Java and JavaScript that cranked the complexity right up. His logic was very sequential, going through steps one at a time with the next step depending on the completion of the last. Java did this very well, executing each call out to Salesforce and waiting for a response. Anybody familiar with AJAX should start to squirm right about now. I ended up with a tremendous chain of call backs, which fulfilled its purpose but got real messy in a hurry.

Reimplementing this solution went well enough minus the previously mentioned call back avalanche (call-backalanche?), but it was not without its drawbacks. These are no fault of Andrew and merely reflect the incomplete state of the Tooling API. For one thing, the method reference count does not count references in Visualforce. This was inconvenient, but to anyone coming from a java background where missing references in the view is par for course. I also ran into an issue trying this on an org with a scheduled job. You see, to build up the symbol table, it is compiled by basically performing a “check only” deploy. Salesforce did not like that one of the classes the scheduled job relies on was one of the classes we were checking. This resulted in total failure.

The plugins were perhaps the smoothest part of this project. Node’s ability to require a directory and a bit of trickery resulted in a plugin system as simple as dropping a properly constructed JavaScript file in the directory. These are not as efficient as if they were all part of the main file, as they end up looping over the same data a few times, but it is dead simple to add new checks, change thresholds, and disable old checks.

“So, is this project done?” I can hear you asking. The answer is an unequivocal no. On the roadmap is a web based interface, greater structure for plugins, ability to configure for multiple orgs, and heavy work trying out different flows and Node modules before I set in stone how everything will work. Until then, everything is in tremendous flux. Check it out at my GitHub repo.

A Quick Update

Sorry for the lack of post this week. House hunting and the depth of the next post are taking a bit more of my time than I expected. If everything goes as planned, I should have a dozy of a post for next week. While I have your attention, don’t be too surprised if the look and feel of the site changes as well, I am experimenting with new styles. I want to keep things simple but pleasing. See you all then!