3 Replies Latest reply on Feb 3, 2009 6:21 PM by Stefano Travelli

    polymorphism and rendering

    Eric Freed Newbie

      I am having a hard time coming up for a say to do this in Seam...

      Let's say I have a questionnaire or survey with a set of questions. Each question can be one of many types, such as plain text, date or numeric entry only, multiple choice (radio box or pull down), etc. So the survey has a Set<Question> and the Question class (or interface) has a number of subtypes. 

      When I iterate the questions list in JSF/Richfaces of the survey, can I do some sort of switch statement to do the correct component for each question? Do I cast it? Do I have a bunch of tags with rendered="#{question.type= }" to control how the questions are rendered? Or is an c:if with includes better? And then each one might have its own validation (text only, numeric only, etc).  I am at a loss at how to deal with the polymorphic set.

      Any advice?

        • 1. Re: polymorphism and rendering
          Stefano Travelli Newbie

          I did something similar and I used a sequence of rendered="#{question.type== }", one for each type, so that for a particular type only the right control get rendered.

          Validation was not a particular issue with the seam-gen style <s:validate> stuff. It just worked.

          • 2. Re: polymorphism and rendering
            Eric Freed Newbie

            What about casting? Do cast each question to its proper subclass?  

            If I don't cast, wouldn't there be an EL error? e.g. A multiple choice might have a Set<String> choices that would need to be accessed and iterated ( question.choices ), but a text entry would not have such a field. Wouldn't that cause an error (even it it is not rendered)? Or should I just eliminate the subclasses, and make a big ugly non-abstract Question class?

            • 3. Re: polymorphism and rendering
              Stefano Travelli Newbie

              I went for the big ugly non-abstract class and type is an enum.

              I chosen this approach because I found subclasses over engineered for this purpose.

              Thought, I think casting should not be an issue for EL.