001// Copyright (c) 2001 Hursh Jain (http://www.mollypages.org) 
002// The Molly framework is freely distributable under the terms of an
003// MIT-style license. For details, see the molly pages web site at:
004// http://www.mollypages.org/. Use, modify, have fun !
005
006package fc.web.forms;
007
008import javax.servlet.*;
009import javax.servlet.http.*;
010import java.io.*;
011import java.util.*;
012import java.sql.*;
013  
014import fc.jdbc.*;
015import fc.io.*;
016import fc.util.*;
017
018/** 
019A dependency changes the values or state of some form element based
020on the user selection or choice of some <i>other</i> form element. 
021<p>
022A typical example includes filling later select/popup values based on 
023the user chosen value of an earlier select in the form. So, for example,
024if the user chooses a country, then the later select shows the states
025just for that country. 
026<p>
027There are several ways to handle dependency changes:
028<ol>
029<li>The data for some fields (like database based lookup tables) can be
030looked up every time. 
031<li>All possible options can be looked up ahead of time and then a
032subset displayed accordingly. This can be done on the server side (on
033form submit) or by client side javascript (using various javascript
034arrays containing different sets of data, the arrays are written out
035by the server as part of the page and swapped out by client side js).
036<p>
037Orthogonal to all this is field and form validation. Validation only
038makes sense <b>after</b> we have displayed the updated fields to the user
039For example, initially a country popup may be empty and a state popup
040may be empty. When the user selects a country, then the form is submitted.
041At that point, the states popup is still empty and we should *not* validate
042the states data (i.e., not show the user a message that a state must be
043chosen or show a validation error for any other fields which the user hasn't 
044filled out yet). 
045<p>
046Validation can always be controlled by enabled/disabled flag on the field
047since field validators are not run for fields that are disabled. In addition,
048any time a field has new dependent values, the form is not validated by field
049validators. 
050
051@author hursh jain
052**/
053public interface Dependency
054{
055
056/**
057Sets new values for target field in the FormData object. The target field
058then uses those values to render itself to the client. The data should be
059saved in FormData with the field name as the key.
060<p>
061<b>Note:</b>This method <blink>must</blink> invoke {@link FormData#setDependencyUpdated}
062if it sets new values in the formdata object. New values are values that
063are different from the values that were last displayed to the client.
064<p>
065There are 2 conditions that typically must be satisfied for this to be
066true:
067<ol>
068<li><i>Source not null</i>: The source fields must have some data. For
069example, a country popup needs to be selected to some country value before
070the target dependent field (a state popup) can be populated. If no country
071is selected, we cannot calculate a dependent state value.
072</li>
073<li><i>Source changed:</i> The source fields must have different data than
074the last time the form was rendered (which means that the client made a
075different selection/choice). For example, previously, the source field
076could have been 'usa'. The client then either changes that to 'uk' or
077leaves it alone. The last_value (which is rendered as a hidden field in the
078form) in conjunction with the submittd value of the source field(s) can be
079used to figure out if there was a dependency change. If the source value is
080'usa' and the last_value is 'usa', then we know there is no need for any
081dependency updates (since the usa values are already shown to the user).
082</li>
083</ol>
084*/
085public void updateValues(FormData fd, HttpServletRequest req) throws DependencyException;
086
087/**
088The inverse of {@link renderDependencyData}, sets any depedency data submitted
089as part of the form. This data is set in the specified {@link FormData} object
090and can be later used by the {@link updateValues} method.
091*/
092public void setDependencyDataFromSubmit(FormData fd, HttpServletRequest req);
093
094/**
095Writes out data to keep track of dependency state. This data is typically
096the last selected values of some source field (say last selected source 
097country for a target dependent state field) and usually written out as a
098hidden field in the form.
099*/
100public void renderDependencyData(FormData fd, Writer writer) 
101throws SQLException, IOException;
102
103/**
104Returns the initial values for the target field  These are the values that
105are displayed when the form is first rendered. The returned object is of a
106type that is suitable for the data of the target field. (typically an instance
107of a static inner data class of that field).
108<p>
109If there is no initial data, the returned object can also be <tt>null</tt> or
110an empty data object, depending on what the target field expects when there
111is no data.
112*/
113public Object getInitialValues(Field f);
114
115/**
116Returns true if the submitted values are in a valid range of values. 
117For ultra-secure applications, the validity can be computed every time by
118recomputing/retrieving the dependent data and of-course, database
119constraints should always be employed.
120<p>
121If this method is not applicable, this method should return
122<tt>true</tt> every time.
123*/
124public boolean  isSubmitDataValid(FormData fd);
125}
126