In some situation, such as my example "Silent Form" and on-demand tree, you can optionally use Remote Scripting
to do a better job. But in some other cases, you have to use it otherwise it is hard to solve the problem.
Dependent section is one of these cases. A page with Dependent sections is divided into more than one sections
where content of one section is depended on content of a field in another section. In other words, selection of a
Key field in one section will determent what to be loaded in another section.
[Why do you place multiple sections in a single page? Show details].
One of the reasons you want to place many sections in a single page is that you want to reduce number of page load
and giving users an overall view all the time that makes it to be easier for users to complete the selctions and,
technically, minimize numberof iterations. A typical example is a wizard with dependent steps ("sections").
A traditional wizard normally has one step a page. This is good for simple cases but may not be able to satisfy
more complicate situation and a high requirement for scalability. The cons of the approach are
use need to make a lot of page-level request back to the server in case the wizard has many steps
users have to finish the current step to satisfy the validation before they can see next step
In the case user need to adjust their decision in the previous step after they see the next step, they
need to repeatly submit a particular page when iterating and this will also hurt your scalability.
Lack of ability to overall view the entire process and the relation between steps
You may say, it is a "wizard" so users don't need to know more. They only need to follow the steps.
Well, the problem is in many cases, we try to use "wizard" like process to let user feel easier but the
fact we face is not 100% wizardable since some of steps are not necessary in a certain order. For example,
you want to build a "wizard" for people to arrange their vacation trips. So which step should be the first?
Destination, airlines, or hotels? To people who knwo where to go, destination is their first step while destination
may not be the first for those who are looking for great deals or last minute discount. The result is that
users make many iteration within your "wizard" before they can reach the last step (of course, pay you). This
means your server will have to handle a user so many page-level request for each wizard trip.
So placing the wizard in a single page may work better in some cases.
In fact, in some other cases, having all the steps in a single page is necessary. One of the example is listed below.
As you can see in the screen below, there are two subframes: listing frame at the top and editing frame at the bottom.
The editing frame will display details about the selected item in listing frame and allow you to modify the item.
The details of each item in the list frame contains multiple dependent sections. So you can not display one section
(step) at a time in the editing frame since you need to load, edit and submit them all together on a single page.
So far, Remote Scripting is not "necessary" yet since you can always send back fields in all the sections to achieve
the dependency. But here is a situation where you can only partially load the page which makes the Remote Scripting
necessary: in the example below, there are tables in some sections and input fields in the table have no attribute "name".
This means that we don't want those input fields in tables to be sent back to the server as parameter when the page is submitted.
In other words, the state of these input fields in tables are preserved in the client side and only the client-side calculated result
from these table input fields is sent back to the server as a dynamic-built parameter. You may say, well, when I load the next dependent
section, I can just send the "calculated result" back to server and then recover the states for the input fields in tables. You can't
because users may try to load the dependent section before they complete the tables - in that case you can't calculate the result. But if
you send the entire page back the state in tables will be lost. So in this case you have to update your page partially.
The following is a demo to show you how the dependent sections be loaded using Mark's
Communicator. There is a Key field in each section. Making a selection in the
Key field will cause a dependent section to be loaded. Changing the selction
in a Key field to see how the dependent section is changed.
The newly loaded section also contains a Key field. A selection made on the Key field in the new
section will cause another new section to be loaded and so on.
The number of sections that can be loaded is infinity so you can load
as many section as you can by making selection in the key field...until your browser
crash.
Note: after making a selection on a Key field, you need to scroll down to
to see the newly added section below.
Compatibility: IE (6.x, 7.x), FireFox (1.5.0.4), Mozilla/Netscape(7.2), Opera(9.0)
were fully tested and worked in XP (v2002. sp2).
