Wednesday 16 November 2011

VF Woes

Very quick blog this week and it's around an issue I had allocating dynamic Ids to Apex Input fields.

I had a recent requirement that needed me to change the values in some input fields in a targetted way on a VF page. My first thought was to assign a dynamic ID to the <apex:inputfield> only to find that you need concrete values in here.

Found a clever way round this that allows you to find fields by their <apex:inputfield styleclass="{!variable}"

As the JavaScript function getByElementClass is not support in all browsers I needed to write something quick and functional (read dirty) that did the job without using any external libraries or Frameworks i.e. jQuery Here is a very simple JS function that will retrieve all the elements of a certain classname to allow you to 'do stuff' to them.
function getElementByClassName(cl) {
    var elements = [];
    var elem = document.getElementsByTagName('input');
    for (var i = 0; i < elem.length; i++) {
        if (elem[i].className.indexOf(cl)!=-1) elements.push(elem[i]); 
    }
    return elements;
}; 
Not rocket science but you can extend it to use regular expressions etc... and all you need to do it pass it the classname you are looking for. Won't solve a lot of problems but it definitely solved one for me today :)

Thursday 3 November 2011

What did that chap just say?

Business and IT, two bodies working for the same company on the same project separated by a common language. How many times in your working life have you as a business user come out of a meeting or workshop and thought,

"What on Earth were those techy guys going on about? A workflow with a field update and an outbound call to a web service to integrate with the outlying systems via the middleware tier, I have no idea what that means"

You are not alone in this, many's the time I have left a workshop and had a developer ask what the business users meant by:

"We need a solution which will enable our back office staff to get all the information necessary for fulfilment without having to go back to the front office B2B reps to get extra detail."

Neither of these statements are complicated per se but, one of my jobs as a consultant is to make sure that when communications happen between technical resources and business users that they communicate in a common language and my role is interpreter.

Luckily this is not a difficult problem to overcome. All you need to do is invest a little time in the technical team prepping them. Here is a short list of what I like to do to better faciliate the conversation
  1. Get a list of all the issues that the technical team need to discuss up front, find out what the developer needs to know to complete the work. This way, you will be having the conversation.
  2. Coach/Mentor your technical team. Have a pre-meet with the team to make sure there are some simple ground rules laid down:
    1. Under no circumstances should the developer talk about code or offer to show it
    2. Business users do not want to hear about the details, Workflows, Classes, Triggers, Unit tests. None of these should be mentioned
    3. Where appropriate, try and ask the question to your own consultants. It’s their job is to translate between Business and IT
Communications between Business and IT need not be a stressful ordeal. With a little preparation then it can become a productive and stress-free experience.