While this feature is interesting and can further optimize the time it takes to open a form there are some important limitations. That is if you scroll down to the bottom of the article it contains a table showing when the "read optimized form" is loaded. And you will quickly realize that if a form has client side scripts it cannot take advantage of this feature.
I tested this out. I took a completely vanilla invoice form and - as advertised - when I opened the record it opened in the nice and clean Read Optimized format.
I then went ahead and added a jscript web resource to the form. To be clear I just added the web resource that are "available to the form", I did not actually wire up any OnLoad, OnSave, or OnChange functions. That is, this web resource was effectively doing nothing.
After I published this, I onced again opened up the invoice form and the Read Optimized setting was no longer respected i.e. it opened in full edit mode. In short, the mere presence of a jscript resource will make the form non-Read Optimized capable.
I am sure there are reasons why it was designed this way. There is certainly some jscript logic that can be impeded by the Read Optimization. Although I guess I'm wondering why Microsoft couldn't have introduced a 7th form type (in addition to create, update, read, disabled, quick, and bulk) in order to target this form option rather than taking the "all or nothing" approach. Perhaps that will be accomodated in a future enhancement or perhaps I haven't properly considered the technical issues that would accompany such a feature...
Anyway, in terms of the practical usage of this feature in it's current incarnation - I have to say I'm a little skeptical.
First of all, it has to be said - what percentage of forms have no jscript acting on them? Jscript really brings tremendous flexibility to form rendering etc. to the extent that not many forms (at least the ones that I touch) remain jscript-less. And even for those that do not have any jscript acting on them - it is of course quite likely over the course of time that you'll want to add some scripting to the form to accomodate some customer requirement. And at this juncture - assuming the client has been happily using Read Optimization for this form - you'll have to explain to the client that this feature that they've now come to know and love will no longer be available.
So when all is said and done, I think I'll personally be employing this feature quite sparingly.
I think this feature makes most sense when it is used in combination with multiple forms. In other words, you have a slimline form with maybe not all fields on which is delivered as the default form only to a key set of users who mostly use that entity for reference, eg for checking a customer address or a contact's phone number, but would rarely be updating the data on it. These same users are set to operate in read-optimised mode.
ReplyDeleteYou also publish a full-fat form with all your javascript goodies to those users who would normally expect to do editing or need the added value of the scripts (many of which will most likely be triggered by updates anyway which means they don't apply to a read-only form).
So some entities will have two forms and the default may be different according to a user's security groups. Your forms might be delivered to mutually exclusive sets of users, or just to deliver the read-optimised version to some but allow everyone to access the editable version if they choose.
Other entities might have only one form if most users normally expect to edit these records and almost never just read them (activities being a prime example).
As you have seen, putting a null script on a form will make sure it is always opened in edit mode even for the users who are set to use read-optimised ones. This way you have some element of control on a per-entity basis as well as per-user.
So it is not suited to all use cases, nor to all users, but there is sufficient flexibility for it to be useful in a variety of different ways for different implementations.
That's actually a very interesting approach. Thanks for mentioning it.
ReplyDeleteI think the argument is a good one in that this feature may make most sense in a multi-form scenario. Although if that's the case, it is a pity that the "Read Optimized" can only be set on each individual's personal settings. Given all the ins and outs of making this actually work, I can see users setting up their Read Optimized settings and then wondering why it doesn't work... So a group or security role setting would make sense in light of this scenario not to mention simplifying the maintenance overhead. At least to my mind.
But there's one thing in what you said that I'm struggling with. I get that you are able to target a particular form to a user group using security roles. But how can the following be accomplished:
"...just to deliver the read-optimised version to some but allow everyone to access the editable version if they choose"
I am not aware of any form "choice" option when you open a record to edit it. The choice is automatic based on the combination of assigned security roles and available forms on the entity. I guess you could set up a custom ribbon button to allow the user to jump to the full form by specifying the form to open in the URL. Is that what you were thinking or did you have something else in mind?