I understand the use of javascript in expressions which allows OS at the server to parse serverside functions and objects such as element id's. 

However, when entering javascript in the javascript editor at the web screen level, I don't see anyway to include the same kind of OS serverside functionality. 

How can I capture the HTML element id using the OS element name object (e.g. MyInputField.Id to get the actual HTML element id). 

Javascript at the web screen level doesn't appear to get parsed by OS at the server.  Or am I missing something.

Most of the visual objects (containers, buttons, links...) have the javascript id available in development time.
Just name them and use objectname.id in your expressions. Intellisense can help you with that.

About the code interpretation, are you escaping content? Selecting Escape Content=Yes you can write html code, including javascript.
I still don't understand.  How do I enter javascript as an expression in the 'Web Screen Javascript' editor.  Intellisence doesn't seem to work in the editor and there is no 'Escape Content' option available for the editor.  It's just native javascript that is not entered as an 'Expression'  Again I'm not asking about javascript in 'Expressions' on extended properties, I'm asking about javascript entered at the Web Screen level using the 'Javascript Editor'.  In the 'Editor' how do I get the the actual HTML element id.  I can get the actual HTML element id by looking at the HTML source in the browser, but is it reliable to hard code this in the javascript?  Is it possible that OS might change the string prefixed to the widget 'Name' when forming the actual HTML Id, so that when the eSpace is republished at some future point, my javascript will no longer work?
Hi Bob,

Since the javascript on the screen level is a static resource (and can even be cached) it cannot depend in runtime elements like Id's the depend on the page rendering.

There are 2 usual ways to do what you need:
1- On the webscreen javascript you can write a function that recieves the id as parameter and the in either an expression or on a onload extended property of the screen you can call the function you defined.

2- on the widget you need to call in javascript define a custom data property in the element extended properties. (for example "data-mywidget")
Then in the javascript, instead of refering to it by id, search by attribute. $('[data-mywidget]')

edit: And regarding the last question in your post, yes it can break. Never hardcode the ids/names as they can change.

João Rosado
Thanks Joao,

That's exactly what I've done.  I just created a new attribute in Extended Properties with the same name as the Widget Name and put the WidgetName.Id in the value.  Works fine.  I wanted to verify that there wasn't something I was missing about using javascript at the Web Screen level.

Again Thanks.
Hi Bob,

In short, the javascript editor is used for adding static javascript - so, it's very similar as editing a .js file (actually the server will save it as a .js file). You can't reference UI elements, such as MyInput.Id, directly in there.

When you need to generate dynamic javascript (e.g. for referencing MyInput.Id), you can use an Expression (having escape content = no) or simply reference and use HTTPRequestHandler's RunJavaScript action in the preparation.

Usually, these two options are used together:
  • First, add your big static javascript to the screen using the JS editor (you can also add it to a web block that you can then drag & drop to screens). As a bonus, end-user's browser will load and cache this .js file, improving performance.
  • In the end, you just need to invoke your javascript code, and typically this is where you need to reference UI elements - the dynamic part of the code - e.g. MyCoolJsAPI.DoSomething('" + MyInput.Id + "').

So, answering your question «In the 'Editor' how do I get the the actual HTML element id»: usually you receive the Id (or object, etc) via a parameter, invoked from the "dynamic" code.

There's a very nice example here. Please take a look.

By the way, you should NOT hardcode HTML Id elements in your code. There's no garantee that Ids will be kept in the next compiled version.
Edit: concurrent posting alert! :)
You really have to focus and don't lose time when answering a question here, or João Rosado will probably answer it first. :D
Hi Bob thats not quite what I tried to explain, but yes its basically the idea.

Just 2 differences to keep in mind:
  • Custom attributes should be named data-* , to comply with html5 standards
  • you dont even need to write the id in the attribute, just having it there is enough to locate it with jquery with that syntax $('[data-someattributename]')

@Paulo: hahaha :P
Nice post tho, we talked all about the same points.

João Rosado
I was using the Widget Name as the attribute name to help guarantee uniqueness ( there are several input widgets I'm referencing).  But you're right about Data-, I had forgotten about the HTML5 standard.

Again thanks.
This is wrong: "Selecting Escape Content=Yes". The escape content must be set to NO to enable HTML code.