Tag Archives: javascript

CRM 2015: Get your field value without losing focus

In CRM 2015 (and most probably in 2013), an entity attribute is not updated with the typed-in value until you exit that particular field via pressing Tab or by clicking somewhere else.

We have a few entities where we don’t necessarily expect the user to exit a field that needs to be validated. Usually these are end-of-form fields, where there’s nowhere else to go in that form, if you get what I mean. If they type a value and save the entity, the value wouldn’t register and the user would get an error, even though they are seeing their typed characters right in front of them.

Pretty confusing.

Seeing this, I wrote a very simple, quick JavaScript function that’s accessible to all our entities, since it resides in what we call our “root” script library. This is unsupported code, but we know and accept the risks; I expect that you understand that before going ahead and implementing this. Here’s the code:

function GetValue (fieldName, getText) {
    var inputType = Xrm.Page.getControl(fieldName).getControlType();

    if (getText == null) getText = false;

    if (inputType == "lookup") {

        if (getText)
            return Xrm.Page.getAttribute(fieldName).getValue()[0].id;
        else
            return Xrm.Page.getAttribute(fieldName).getValue()[0].name;

    }

    if (inputType == "optionset") {

        if (getText)
            return Xrm.Page.getAttribute(fieldName).getText();
        else
            return Xrm.Page.getAttribute(fieldName).getValue();

    }

    if (inputType != "standard") return null;
    var id = fieldName + '_i';
    var inputElement = document.getElementById(id); 
   
    if (inputElement !== null)
        return inputElement.value;
    else
        return Xrm.Page.getAttribute(fieldName).getValue();

}

The first thing we do is check the type of field we’re working with. Using that, we have some code to send back values for lookups and option lists. The parameter getText allows you to get the name or text descriptions if it’s set to true for these type of fields.

We now evaluate if the field is standard type; if not, we return a null value.

Finally, this is the part where we do the switcheroo. We create an id for a DOM element. The reason for this is that when a CRM field gets focus, an HTML input element is created on the fly; this is where you actually type into. As soon as you focus out of the field, that input is gone. The name format for that element is attributeName + “_i”. 

We build that name and then try to get an element with that name in our DOM. We only do it once because your cursor can only be focused in one field at a time. Wrapping things up, we check if the HTML input element exists (meaning that a field has focus and hasn’t been exited by the user). If found, we return the value of this input, otherwise we return the actual attribute.

Pretty straightforward, and works like a charm for us.

Advertisements
Tagged , , , ,

CRM 2015: Business Rules and JavaScript don’t mix, unless you really like acetaminophen

frustration-600x450_1-100521350-origYep, I said it. And this might be my first real random musing, so bear with me.

In our CRM 2015 implementation with the Unified Service Desk we decided that, for some of the simpler custom entities, we would change the validation from JavaScript to Business Rules. That way we would be able to have an easy way to establish client-side validations and rules, and avoid having to code those rules. We would also have elegant field-level error messages instead of things like pop-ups. Sounded like an ideal thing.

In our real world, unfortunately, didn’t work out that way. Or at least it hasn’t so far.

There’s a few corny things about Business Rules. First, they execute in the order you activate them. Excuse me, Microsoft, but that’s a bit of a bone-headed implementation. That means that developers would need to have a list of the correct order of activation just in case they needed to work with the rules. Why couldn’t they implement a relative sequence number is beyond my comprehension. Hey, they did it with USD window navigation rules!

Second, they need to be defined at the entity level to be executed on save. That means that now you have a process running all the time, every time, for every save you perform in that entity, regardless if you activate the validation only 5% of the time.

Third, as I mentioned above, if you throw JavaScript into the mix, with Ajax calls, XRM, etc… Let’s say it gets really busy. Especially since Business Rules are nowhere as easy to debug and trace as JavaScript validations.

So what’s my final take on all this?

If you have a mostly vanilla CRM implementation, Business Rules might be the thing for you. This carries even more weight if you have Business Analysts putting in validations in your organization. No need to code these is a huge advantage.

However, if you have a highly-modified organization, with lots of heavy XRM, jQuery, and even DOM manipulation, your best bet is to stay away from Business Rules. In our implementation with the Unified Service Desk, where we have custom code for managing tabs in Save & Close, getting the Business Rules to work reliably has been a hair-pulling experience. The time you’ll spend spinning your wheels trying to get things working together is akin to herding cats: you might be able to pull it off, but in the end wonder if it was worth all the effort.

What’s your take on this? I’m interested to read other CRM developers opinion on this.

Tagged , , , ,