Thanks for the comments Gauthier, I came to a similar conclusion for
the simpler scenarios (i.e. rendering a long answer question vs
rendering a select one option question) and I have built a component
for each of the scenarios where this is appropriate (answering /
editing answer / reviewing) that simply reders a template based on the
question type name. Now I am trying to build a component that allows
the analysis of the results and the behaviour here may differ
significantly between questions e.g. display a list of all the
responses to a short answer question vs display a bar graph showing
how many of each option were selected for a select one option
question.
The obvious solution to this example is that I create a component that
renders either a link (to an action that will display all of the
responses to the short text question), or an image tag (to display the
graph) however while this is fine where I know / can create actions to
handle these scenarios at the moment, I need to be able to handle
different scenarios that might arise from the addition of new question
types.
My goal is to be able to add question types with new behaviours etc
without needed to alter large parts of the code to support the new
question. Currently all I need to do is add a couple of view
templates and implement one interface for processing the results that
are posted back when the question is filled in.
I think originally I was looking for the view component to do too much
and this is what caused the over-complication and confusion. Now I
can see I need to spread the work into the controller / repository /
container to achieve a solution that will allow the kind of
extensibility I require.
On Sep 5, 11:29 am, Gauthier Segay <[EMAIL PROTECTED]> wrote:
> As a quick note, I would think about:
> - component view templates (make one for each question type), or new
> components (as you do)
> - think out a view specific data model hierarchy and parameters needed
> for each template
> - not mess with the PropertyBag by using viewcomponent parameters
>
> Your current approach could be simplified if :
> - populating view data according to the current question to display in
> Initialize method
> - calling RenderView("questiontype.singleselect") according to the
> current question to display in Render method
>
> it depends on how you want to put the code/logic (one component vs
> many).
>
> On Sep 4, 11:03 pm, Neal Blomfield <[EMAIL PROTECTED]> wrote:
>
> > I am building a survey tool that allows users to answer / edit their
> > answer / review the answer / analyse the results of a question. The
> > problem I have is that the actual behaviour in each of these scenarios
> > may differ depending on the type of question (i.e. analysing a select
> > single option question will show a bar graph whereas the same action
> > for a short answer question will show all of the answers).
>
> > Currently I have a view component for each of the tasks (answer /
> > edit, review, analyse) and this component looks up another component
> > based on the question type to do the actual rendering. This second
> > component is currently implemented as a view component and I simply
> > initialise it from the Render method of the first component and then
> > call Render on the second component.
>
> > While this allows me to create the illusion of a polymorphic view
> > component, it feels somewhat clunky and I am wondering if the view
> > component is the best place to make these kind of decisions. Being
> > new to MonoRail and working on my own means discussions at the
> > whiteboard are a little one-sided so...
>
> > ... am I on the right track here or is there a better approach that
> > will
> > 1. Allow me to alter the way a question is rendered based on the
> > question type
> > 2. Allow me to add question types without having to alter code (i.e.
> > follow OCP).
>
> > Comments, thoughts, pointers to other posts much appreciated (I'm sure
> > this is a common requirement but I must be looking in the wrong
> > places / using the wrong search terms as I haven't found anything of
> > use yet)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---
