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