Armen blogged about the best way how to make java script in code behind, which made me blogging this post.
I really think that the java script doesn't belong to code behind and that in most of the typical use cases can be easily ported to client side
The reasons behind that mine opinion are:
- It is hard to maintain and update java script made by concatenating strings in code behind
- Every single change (no matter how small requires rebuilding) which can take 15-20 minutes in some applications
- UX persons (experts for Java Script kung fu) in general prefer staying in markup level and hate going in code behind
- DEV persons in general prefer UX staying outside of code behind
So an example of typical use case I am seeing on code reviews, is building a java script in code behind because the code need to embed into the script control run time ClientID (in case you don't know what is it take a peak here)
The code I am describing is covering next use case:
There are text box and a button controls on a web form and page defines an integer property called TestProperty.
Click on the button should produce a client side alert message which would show the entered content of the text box and a value of the test property
So the markup looks something like this
The string builder code behind approach to implementing use case (and I am pretty sure you've seen it yourself a lot of times) could look like this:
In lines 1-6 we have a plain old integer property definition which value we set in first line (line 10) of the Page_Load method.
So, in lines 11-18 code is concatenating the text of the java script function with a special cases happening in:
- line 15 where we concatenate to java script string ClientID property value of the InputTextBox server side control
- line 15 where we concatenate to java script string value of the TestProperty
In line 19 then we check if we didn't register the script already and in case not (in line 20) we are registering it.
(I'll live this piece of code in this state fully aware of how unoptimized it is:) )
Obviously, the reason why the server side java script is been used here is the need for accessing some server side property from client side. This java script needs a server side control attribute value and a server side variable value.
The way how to do the same thing on client side is based on very simple idea: usage of good old <%= something %> tag which allows (in place of something) referring any server side, code behind variable
So the same functionality implemented on markup (client side) level would look like this:
- in line 4, I am using <%= InputTextBox.ClientID %> which means something like "Insert here ClientID value of the server side control InputTextBox"
- in line 5, I am using <%= TestProperty %> which means something like "Reach out to server side and give me the value of TextProperty variable
With this approach no code in page load is required, Print function can be modified on client side only without the need of rebuilding the web application and making changes in code such is changing property name breaks the build
That contributes a lot to increasing productivity and happiness of UX people
|Share this post :|