I'm working on a customizable questionaire application and I'm running into a situation where I'm a bit confused how to handle it.
One form in the application is for a user to answer the questions. The list of questions is immutible, but the answers obviously need to be edited and saved back to the database. My gut reaction is that I want to use the following object structure:
questionaireItem (editable) --> questionList (read-only) --> questionItem (editable)
The logical hiccup I'm running into is that there doesn't seem to be a way to pass the Save instruction down to the individual questionItems. I'm pondering switch the questionList to an editable list and just closing off access to add/delete member items, but I don't want to carry overhead that I don't need.
Has anyone run into a similar situation or have a suggestion on how to handle this? Is this just inexperience with the framework biting me?
If the list of questions is immutable why are they not properties of the questionaireItem? For instance questionaireItem.question1, questionaireItem.question2 etc thus eliminating a read only list since the list doesn't change.
Now if the reason it is a list is because it can be changed by a admin/supervisor type and not a developer with acces to change the source then I would approach that as a buiness rule such that the List is editable but rejects saves unless the questionaireItem is being edited by the proper user.
Justin
It seems to me that you've missed a step here. What you actually need to save are the responses to the questions, not the questions themselves, as would be indicated by your model. May I suggest the following:
with the Questionnaire object exposing the QuestionList and ResponseCollection as properties. The Response object would have a referece to the Question and a Value property that is used to persist the user's answer. Then, when you call Questionnaire.Save() it will pass the operation through the ResponseCollection to the individual Response objects.
HTH
The questions are, in fact, editable by the admin. There are actually six different questionaires that I know will be available to begin with. My plan had been to create a separate set of objects to edit the questions because, as SonOfPirate indicated, the actual questionaire is really just editing the answers.
SonOfPirate, your model would still require passing a save call to an editable child of a read-only parent, which is what's perplexing me about this circumstance. Could you elaborate a bit?
mercule:
The questions are, in fact, editable by the admin. There are actually six different questionaires that I know will be available to begin with. My plan had been to create a separate set of objects to edit the questions because, as SonOfPirate indicated, the actual questionaire is really just editing the answers.
SonOfPirate, your model would still require passing a save call to an editable child of a read-only parent, which is what's perplexing me about this circumstance. Could you elaborate a bit?
Why are you describing an editable list as read-only? As already suggested, this looks like a fairly simple permissions issue to me.
Why are you describing an editable list as read-only?
Lack of experience with the framework and some of the thought processes behind it. My understanding was that the difference between an editable list and a read-only one was whether a child element could be added to them.
In this case, there is significant difference in logic between the use case for maintaining the questions list vs. actually answering them. If I'm understanding Mr. Lhotka's book correctly, that is ample justification for making two different families of objects.
For admin/maint:
Questionaire --> Questions (with the ability to add children) --> Question
For user responses:
Questionaire --> Answers (w/o the ability to add) --> Answer (w/ QuestionText as a property)
As already suggested, this looks like a fairly simple permissions issue to me.
That's the answer I was looking for. Thank you much.
Copyright (c) Marimer LLC