I don't know if this is something already available or if it's feasible, it's just merely a thought.

It would be useful if we could have, Javascript variables available in every screen, provided by the platform like the already existing _DATE_FORMAT, that would give us some hints about naming nomenclature used by the platform.

That way, for instance, if the transformation from names to id's of screen elements made by the platform was to always be made based on a prefix scheme, knowing that the prefix used was always available we could use it and also make sure it wouldn't break in a future upgrade because if the naming convention were to change the available variables would change with it.

For example if we had a simple form with three inputs, named: nameInput, mailInput, textAreaInput, and we had a screen variable named _TEXT_INPUTS_PREFIX with the value 'wt', we would know that our screen would have the id's wtnameInput, wtmailInput and wttextAreaInput correspondingly and we could develop some code without having to pass around so many arguments with the widget's id's:

function GetFormState() {
var nameWidget = _TEXT_INPUTS_PREFIX + 'nameInput';
var mailWidget = _TEXT_INPUTS_PREFIX + 'mailInput';
var textWidget = _TEXT_INPUTS_PREFIX + 'textAreaInput';

this.name = $(nameWidget).value;
this.mail = $(mailWidget).value;
this.text = $(textWidget).value;

Hi André,

We keep the widget naming internal to promote the reusability of the code, to enable the cacheability of javascript files and to make it easier to refactor (e.g. if you change the widget names your script would still work). Also be aware that when those widgets are inside web blocks the prefix will be different.

This being said we understand that it could be easier to implement client-side functionality with the platform so we are planning some new features around that area (which we can not disclose just yet). Your feedback comes at a very good time and we'll keep your concerns in mind.

Thanks a lot for your feedback,
Tiago Simões
It's not a good approach to think that all the platform does is to insert a prefix. Just think about when you have a widget inside some table record. When it gets rendered on the page, a fixed suffix isn't enough to provide the widget present in every line with different IDs.

You should always do similar javascript code inside an unescaped expression and using WidgetName.Id, like:

"<script type=""text/javascript"">
function () {
var nameWidget = '" + NameWidget.Id + "'; /*...*/ }

I understand, and it probably wasn't a very good idea but I think the pattern to keep the Javascript code independent might be a good solution for heavy JS dependent projects.

My idea was to keep the JS outside any platform dependency and to code it in a reusable way without using inline code on the extended properties and without having to pass arround so many parameters with the id's.
But I think as a pattern I could keep an unescaped expression on the end of the page that would set JS variables with the screen widget's ids that will give exactly the expected result.