Hi Thiago, thank you very much by your answer.
The scenario is the next:
I have to create a page to show a survey, so in my model I have some clases:
---------------------------------------------------------------
Survey
+ List<Question> questions
Question
QuestionText extends Question
QuestionRating extends Question
QuestionOptions extends Question
...
---------------------------------------------------------------
So, I need to display each Question to be answered by the user.
With tapestry I think I have to create a component for each question type
and then create a component for decide what component display when I want
to show a survey.
For example, I have a survey with 3 question text, so I have to loop the
survey's questions for display each one like this:
-------------------------------------
question text 1
[text field]
-------------------------------------
-------------------------------------
question text 2
[text field]
-------------------------------------
-------------------------------------
question text 3
[text field]
-------------------------------------
How can I design that scenario with Tapestry?
I appreciate your help, thank you for your time reading the post.
On Thu, Feb 6, 2014 at 4:08 PM, Thiago H de Paula Figueiredo <
[email protected]> wrote:
> On Thu, 06 Feb 2014 18:57:24 -0200, iberck <[email protected]> wrote:
>
> Thank you for your answer Thiago.
>>
>
> ;)
>
>
> I have to create multiple c1,c2,c3,c4,c5,c6,c7,c8,c9 child components of
>> parentcomponent so I prefer to put the logic inside each component and
>> then decide which component use with a separate component:
>>
>
> I have no idea what scenario you're describing now I understand what you
> wrote, to be sincere. And I guess it's not much related to the scenario in
> the original post of this thread.
>
>
> ComponentCase.tml:
>> <t:delegate to="block"/>
>>
>> <t:block id="c1">
>> <t:c1 param1="${param1}" param2="${param2}" param3="${param3}"/>
>> </t:block>
>>
>
> For the love of everything which is sacred for you, never, never, ever use
> ${} expansions when passing parameters*. In 100% of the cases, it's useless
> (when the parameter type value is a string) or completely wrong and causes
> an error (when it isn't).
>
> [*]: According to http://apache-tapestry-mailing-list-archives.1045711.
> n5.nabble.com/template/NamlServlet.jtp?macro=search_
> page&node=2375124&query=never%2C+never+ever+expansion&n=2375124, I've
> said this 47 times already. It seems it wasn't enough, so the 48th is in
> this message! :D
>
>
> What kind of design is better implemented in this case?
>>
>
> It depends on the case. This thread described just very vague scenarios. I
> don't even know why would you need so many component subclasses (the c1,
> c2, cn you described above). You either have a very weird requirement or a
> very bad way of doing code reuse.
>
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
