|
Tech forum
Enhance your Web pages with DHTML – III
 (This
is the concluding article in the series on DHTML. If you find this
article useful, you should also look at past two articles for continuity,
and for exploring related ideas.)
Dynamic Properties
What is the difference between Windows forms and a Web interface? The dynamism.
Right? It was so easy to enable or disable buttons or textboxes depending upon
what user did in other controls on the same form in Windows forms. Unfortunately
HTML was not designed for such level of flexibility. DHTML solves this problem
by providing similar functionality at the client browser side. This feature
called Dynamic Properties, when used effectively can provide a very sleek user
interface and eliminate many unnecessary server trips, thus improving performance.
It also reduces coding because property-level dependencies eliminate a lot of
event-level scripting.
l What are Dynamic Properties?
What are properties? You know so many of them. Like color of text, size of font,
style of text, size of controls and so on. These are properties which are hard
coded into the HTML page or generated on-the-fly by the ASP page. But once it
is finally rendered in the browser, these are read-only. These can not be changed
now.
What if property values can be changed at runtime? Better still, these can now
depend upon some other properties of other controls of the page? Would it not
be great? That is exactly what Dynamic Properties do.
Example: This is a slightly complex topic. But once you understand it, you will
thank me lifelong for showing this method! So let us go step by step.
Consider this simple HTML page. Save and run it.
<html>
<HEAD> </HEAD>
<BODY>
<input id=”in1”
>
<br>
<input id=”in2”
style=“background-color:expression(in1.value)”
>
<br>
<script></script>
</BODY>
</html>
Looks simple. Is it not? Just two textboxes ‘in1’ and ‘in2’.
The background color of ‘in2’ is based upon whatever you type in the
textbox ‘in1’. If it is a valid color, it will work. Else it won’t.
Simple.
Now run the page. Click on the first textbox and type ‘red’. The moment
you finish typing ‘d’ the second textbox has a red background. Great,
is it not?
How would you have done this otherwise? By writing some event handler for textbox
‘in1’. Which means writing a function and calling that all the time.
Typically you would not have hooked the keypress event here. You would have
used the event.
Here we defined the fact that the background color is dynamic and it depends
upon whatever is written in textbox in1. This required the expression function
to be used in the style clause. Initially there is no value in ‘in1’.
Try putting a valid color value (or name) there and rerun the page. You will
see that the second textbox has the appropriate background color.
<input id=”in1” value=”lawngreen”
>
Brilliant is it not?
Now let us twist the code some more.
Let us also automatically put the name of the color in the second textbox. That
means specifying the value property of the textbox. Usually we either specify
it at design time, or set it to some value (typically database based) programmatically.
In this case, we will do neither. We will make the value property depend upon
the background color of the textbox ‘i2’ itself. That means one property
of the object is now determining another property of the same object! To simplify
the syntax, we have used the setExpression method. This method can be applied
to any property of a given object. In this case we are interested in the ‘value’
property of object ‘in2’.
We do this while the window is loading using the ‘onload’ event. Here
is the code. Put this in the <Head> section of the above page.
<script language =jscript >
// runs myInit funciton on loading of Web page
window.onload=myInit;
function myInit()
{
// sets the value property to the background
// color of self
document.all.item(“in2”).setExpression(“value”,
“document.all.item(‘in2’).style.backgroundColor”);
}
</script>
Simple script really. Just sets the value property to the ‘backgroundColor’
property of self. Nothing great once you know that there is something called
dynamic properties.
Why did we not specify the expression for the Value property directly? Like
we did for the backgroundColor style? Because that type of inline expression
is allowed only for styles, not for direct properties. Hence we have to use
the slightly round-about method of doing it in the onload event.
Now run the page and try it out. When you put a valid colour name in first textbox,
the background colour of the second textbox changes as earlier, But the colour
name also appears in the second textbox. Now, this is not a great achievement
in our example. Because you just typed the color name and it appeared in next
texbox. But the thing to appreciate here that the value property of the ‘in2’
object depends upon another property of the same object.
Now let us extend the example a little further.
Remove the input textbox ‘in1’ completely. Just delete the line
<input id=”in1” >
Next, delete the script also completely.
And change the in2 input box line to depend upon itself! Like this:
<input id=”in2”
style=“background-color:expression(in2.value)” >
Now run the example. Only one textbox. Type any valid colour and change the
background colour of the same textbox! Powerful isnt’ it?
Now just out of curiosity I tried the colour by names as well as the ‘#’
values. Both work. Then I tried just numbers – these also work. Then just
out of unnecessary curiosity I tried the RGB function . Even that worked. Try
it out. RGB (255,255,0) will give yellow color.
What is to be learnt from here? Generic design. I am sure when the backgroundColor
style property was being coded they did not even know there would be something
called Dynamic Properties in future. But once you have a property accept colour
information, it should accept any type of valid colour values. And that happened
here. There is so much to learn.
1. To enable / disable appropriate UI elements based upon data input by users
2. Make hidden elements (entire sections if required) visible for conditional
inputs. For example, if there is a combo box which asks you type of travel.
If travel type is air the details required are different. So is the case for
train travel. You have defined the train and air UI in separate sections. Visibility
of these can now be dependent upon an expression which looks at the value selected
in the combo box!
3. Online calculations without server trips. Simple things. You are accepting
line items and want to show grand total. That can now be dynamically calculated
without additional event based scripting.
4. Probably the most important use of this is CSS positioning. Based upon the
browser screen sizes, you can dynamically manage the UI without any events.
- Manipulating dynamic properties
Dynamic properties are themselves dynamic. Which means, the expression for the
dynamic property itself can be changed at runtime. You change expression using
‘setExpression’. View existing one using ‘getExpression’,
and delete it by using ‘removeExpression’. Simple.
Improving HTML page performance
Here are some tips and tricks.
1. Minimize the size of the page contents.
This may sound primitive but still this mistake is committed by many. During
code audit assignments, we still find large images, huge script (without reuse
of course), large blocks of data (for populating combo boxes, etc), verbose
text in the page itself, large animations (unnecessary – in most cases!)
and so on. So always find out what is the page size of your final HTML page.
This sometimes becomes difficult when you are building ASP or ASP.NET pages.
A good idea is to view the final page output in the client browser on and choose
Edit in Frontpage. This gives the total size of the downloaded page content
much more easily. This is simpler than right-clicking on each element and trying
to total up the size.
2. Reuse
This is another important method. Very often we keep writing repetitive code
or using repeated functionality, not realizing that it could be unified and
reused. Often pages are created once and changed so often, we tend to lose track
of these reuse opportunities. CSS, HTC, script blocks, behaviours—there
are so many features which are designed for reuse. It is important to proactively
find these opportunities. It may not be practical to apply so much thought for
each page. But at least do it for pages which have (or could have) performance
related problems. An external script file containing all common routines is
one of the simplest and most effective ways of reducing size, improving reuse
and reducing server trips.
3. Use CSS positioning instead of tables
Many developers and designers still use traditional tables to position elements
with respect to each other on a page. This works. But with CSS positioning you
have much more control and flexibility available. CSS positioning offers absolute
as well as relative positioning. It also offers clipping and overflow control.
Further it allows overlapping objects with a layering effect using z order.
Further it provides control over whether the item is visible or not. Now the
best part of this is all these things can be manipulated at runtime! If you
have not tried it yet, do it now and see for yourself how useful it is.
4. Use fixed width tables using ‘table-layout’
It requires longer time and processing to render variable width tables. Use
the table-layout CSS property and set it to Fixed. Also specify width in all
columns. This way, rendering is much faster.
5. Close tags
Although it works without closed tags, the browser then has to search for corresponding
elements to decipher where the tag should have ended. This takes up processing
time. So closing tags will improve performance. VS automatically closes tags
for you using intellisense. So implementing this simple thing should not be
a problem at all.
6. Rewrite your scripts!
Too drastic a step? I know. But I have come to the conclusion that this is the
only way of writing best possible code. Generally we write code and keep modifying
it till we finally roll out the site – or even after it – till things
stabilize. During the process the base purpose is to get the functionality working.
Code level excellence is typically not looked at. No time, you see! Now, take
all the code and rewrite it. Many will tell you to Optimize the code. But that
does not happen. Rewriting is the best optimization. Of course, retain the part
of the code which cannot be improved further. But approach it as a rewrite.
See the results for yourself. Try it out. Simple things to do – think of
reuse, defer the script parsing if it does not require anything to be done at
load time, use minimum number of dots in referring to object hierarchies (yes
it matters), and so on.
7. Use client side caching
There are great features available for client level caching. Content can be
specified to be looked up on the server based upon your perception of how often
it changes. Depending upon that we can specify the expiry time. Further, we
can control whether to show content first and then check for expiry. This allows
background refresh of expired content. This uses header tags post-check and
pre-check in the cache control header expression.
Summary
Well, that felt a fairly long journey into DHTML.
But, by the way, that was only scraping the surface. Please explore
it fully. The MSDN site has full coverage of the entire programmability
of IE and related topics. It is definitely worth not just a look,
but warrants regular reading, practicing and even re-engineering
your existing code. To pursue excellence you have to explore! You
are the Infinite Explorer
 |
About the Author:Dr
Nitin Paranjape is the Chairman and MD of Maestros (Mediline).
He is a consultant with many organisations, covering appropriate
technology utilisation, business application of relevant technology,
application architecture and audit as well as knowledge transfer.
He has authored more than 650 articles on various technology-related
subjects. He can be contacted at nitin@mediline.co.in |
|
