This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Hi, I have been spinning around in circles trying to think of the best way to implement an application. Unfortunately talking to myself confuses the issue even more I am designing a web app for a friend who has opened a health care clinic. A patient is required to complete a series of questionnaires throughout the treatment process. The questionnaires to be used are based on the stage in their treatment and the type of injury. I am storing this information in a database. My questions are: 1. as each questionnaire has different questions should I create another questionnaire class eg IQuestionnaire interface XYZQuestionnaire implements IQuestionnaire private Question XYZQues1() or should I create a Questionnaire object and populate it with questions at run time ? eg concrete Questionnaire class private Question questions public addQuestion(...) I then create an XML file to map between the web front end and the database fields. 2. what is the best pattern to use for working out the next questionnaire ? My thinking would be to use a service to worker pattern to pass the name of the current questionnaire and finds out the next questionniare. I can keep the name of the web page as a field in the Questionnaire table in the database. Any suggestions would be greatly appreciated. regards, Ralph Roper wannabe Java OO designer
What I tend to do is to start by defining interfaces. So I would want a basic IQuestionairre interface ... it might have method signatures for getNextQuestion(), cancel(), submit(), etc. Then I would define an interface for the question, IQuestion ... it might have method signatures like ... getQuestion(), setResponse(), getAnswer(), etc. Then I would provide base or default implementation these interfaces ... then I would use specific extensions of the base class for the specific questionairres ... then you might want to consider a QuestionairreFactory that would provide instances of the IQuestionairre interface given a patient profile (stage of treatment, and type of injury).
On the other hand, I'd vote for something more like the other choice. The hairs on the back of my neck stand up at the thought of having to recompile and redeploy the application every time anyone changes a question or adds a new questionaire. I'm not sure about the purpose of the XML file in your example, though. I guess I don't know enough about how flexible your questionaires have to be. Presumably you have something like a prompt, some sort of type field (selection, checkbox, textfield etc.) maybe some parameters (select options, field width, whatever), and maybe a default value for each question. Then you need something to associate each question with a position on a questionaire, and something to associate a question with where (and how) to store the answer. This sounds a lot like two or three tables in a database to me. Then you just need a simple create/read/update/delete admin front end (two or three simple JSPs and maybe a servlet) to manage these tables and you can build any questionaire you like. Running these questionaires is the other part of the equation. Perhaps build each page using a single, fairly-general questionaire builder (maybe a JSP or WebMacro servlet). When given the id of a questionaire, it asks the database for all the questions on it, ordered in sequence, then iterates through them rendering them acording to the field type and parameters. A simple servlet can serve as the destination of all the forms. Just make sure the form contains enough hidden fields to tell the servlet how to find out where to store the values. As for your second point. The solution depends on how complex the routing between your forms is. Is it just a sequence (form C always comes after form B and before form D), is the choice of next form always known at the time this form is rendered? Does the choice of next form depend on the same single field on each form? Does the choice of the next form depend on an arbitrary combination of fields, different on each form? For each of these cases I would probably propose a different solution. Oh, and by the way, do any of the forms have more than one "page"?, or can any of the forms legitimately be filled in more than once with different data? These are the sort of things which can greatly complicate the issue. I've done a lot of form-processing web applications, and there is no "one-size" solution. Please let us know a bit more about what you need.
Firstly, thanks for the replies. To answer Frank 1. there is no predefined sequence that these questionniares have to be answered in, 2. at this stage I am keeping one questionniare per page as they are not overly long, 3. I am not updating the questionnaires until they have clicked on the Finish button at the end. Once they are finished I invalidate the session and update the database to say that set of questionnaires are done. 4. the XML stuff was to provide more flexibility but the more I think about it the more it seems like overkill. OK. My design is shaping up as follows. On the database front I will have three tables. QUESTIONNAIRE QUESTION - contains the stuff that Frank mentioned ie type of field, select options, field width, etc ANSWER For java classes I will have a 1. IQuestionnaire interface and a 2. concrete Questionnaire class that will be associated with a 3. Question class that will have an String answer variable. Going with Frank's idea a servlet can pick up the questionnaire and perform the formatting for the output. I am not sure hidden fields are required as I can place html "NAME=" for each of the fields. To control the processing I am looking at using a QuestionnaireController class that will allow me to add a Questionnaire object, give me the next() Questionnaire, etc. Your input has made the design process a lot clearer for me. Are there any glaring holes that I should be aware of? Ralph
Joined: Jan 07, 1999
there is no predefined sequence that these questionniares have to be answered in Ah, are they all available for the user to pick from in any order, then, or are there any limits or preconditions on which questionnaire may be answered next? at this stage I am keeping one questionniare per page as they are not overly long, Good choice. Multi-page stuff is a PITA. I am not updating the questionnaires until they have clicked on the Finish button at the end. Once they are finished I invalidate the session and update the database to say that set of questionnaires are done. This puzzles me a little. You have introduced the new concept of a "set of questionnaires", can you clarify what you mean by this? It also lends more weight to the idea that there is some sort of menu of questionnaires for the user to choose from, and a "Finish" button to indicate that no more are to be filled in. Is a user required to fill in all questionnaires in a "set"? May some of them be ignored? Do any of the questionnaires have "mandatory" fields which must be filled in before the form submission is acceptable? Do any of the fields have validation criteria (like, must be a valid date MM-DD-YYYY etc.)? What happens if the person filling in the form gets a phone call after filling in (say) three of the four forms in a "set" without clicking "Finish". I bet the session will time out and it will alll be thrown away. Is this the desired behaviour ? the XML stuff was to provide more flexibility but the more I think about it the more it seems like overkill. Most likely. Don't drag technology into a solution just because it's trendy. Start by developing the simplest system which does the job as you understand it so far, then listen to what the customer wants once he/she is familiar with what you have delivered. On the database front I will have three tables. QUESTIONNAIRE QUESTION - contains the stuff that Frank mentioned ie type of field, select options, field width, etc ANSWER Looks OK. Can one question appear on more than one form, or are they unique? If they are unique you can probably fold the questionnaire table and the question table together with columns like: form_id, order_on_form, q_id, prompt, type, params, etc. and then all you need in the answer table (if you are collecting copies of the same form for multiple users, for example) is something like user_id, q_id, value
If the questions are not unique, you'll need a questionnaire table more like: form_id, order_on_form, q_id
and a question table like: q_id, prompt, type, params, etc. as well as an answer table like: user_id, form_id, q_id, value Which approach to choose depends very much on the types of questions, and your understanding of the people setting them and answering them. For java classes I will have a 1. IQuestionnaire interface and a 2. concrete Questionnaire class that will be associated with a 3. Question class that will have an String answer variable. I think this is the weakest part of your design. First, please think twice about marking up your class name with an I to indicate that it is an interface. Code using that class should not need to know that it is an interface, so why tell it - it just makes changing your mind whether to use an interface, an abstract class or a concrete class harder. I'm not even sure that you need a Questionnaire class anyway. What behaviour and responsibilities do you think it should have ? To control the processing I am looking at using a QuestionnaireController class that will allow me to add a Questionnaire object, give me the next() Questionnaire, etc. It's good that you are thinking about the behaviour of this class, but it still sounds a lot like just a java.util.List, rather than a domain-specific concept. I can't help feeling that before you get too deep into classes you should be comfortable with the flow of the information from the database to the servlet to the browser and back again. Then only code the classes which are actually needed for this process. Creating lots of classes for the "nouns" in a system, and missing the "verbs", is a classic O-O design problem. If you are not careful, your software will end up mostly just handing information from one data-holding class to another, when it might be a lot simpler in fewer steps. I am not sure hidden fields are required as I can place html "NAME=" for each of the fields. Sure, but what I was trying to get at was that you will need at least some sort of field indicating which questionnaire it is, and probably one indicating something about who is filling it in or who/what it was produced for. Bear in mind that, even though you probably have this stuff in the session, there's nothing to stop a user hitting the BACK button and then submitting a form again, or hitting the REFRESH button (or resizing a Netscape window!) and inadvertently resubmitting the POST. The best way to guard against this is for each form to say what it is, and for the server code to know which forms have already been submitted by the browser.