I think that tapestry pages should be as simple as they can be. Every
non tapestry logic should go in service. Your "Answers" object is kind
of entity collection. So you can design service with method like
public Answer getCurrentAnswer(List answerFromASO) {
...//same as in page method
}
and call it from page
public Answer getCurrentAnswer() {
return getAnswerService().getCurrentAnswer(getResponse().getAnswers());
}
Alse if answers are entities from database you can read them from
service and not store them in ASO...
>From my point of view second method is better to leave like it is now...
tomas
2005/9/16, Rob Dennett <[EMAIL PROTECTED]>:
> I have a page class which contains some property accessor functions that
> contain logic to calculate the appropriate property. Here is an example:
>
>
>
> public Answer getCurrentAnswer()
>
> {
>
> //getResponse() will return an ASO
>
> List<Answer> answers = getResponse().getAnswers();
>
> if (answers == null) //create an empty list
>
> {
>
> answers = new ArrayList<Answer>();
>
> getResponse().setAnswers(answers);
>
> }
>
> if (answers.indexOf(getQuestionIndex()) >= 0) //if the list
> element exists
>
> {
>
> return answers.get(getQuestionIndex());
>
> }
>
> Else //create a new list element
>
> {
>
> Answer answer = new Answer();
>
> answers.add(getQuestionIndex(), answer);
>
> return answer;
>
> }
>
> }
>
>
>
> Should this be considered a view concern and left in the page code or should
> it be extracted out to a service? It seems like a view concern to me, but it
> is rather complicated logic and not Tapestry specific. It also appears to be
> independent of any specific view technology. However, the code needs to
> access an ASO. I guess that could be passed to the service object (or
> somehow wired into it)
>
>
>
> Here is another example:
>
>
>
> public void goNext(IRequestCycle cycle)
>
> {
>
> //save answers
>
> getSurveyService().saveResponse(getResponse());
>
> int sectionIndex = getSectionIndex();
>
> if (sectionIndex < getNumSections() - 1) //still more sections
>
> {
>
> setSectionIndex(sectionIndex + 1);
>
> }
>
> else //go to first section of next unit (called a safe practice)
>
> {
>
> int safePracticeIndex = getSafePracticeIndex();
>
> if (safePracticeIndex < getNumSafePractices() - 1)
>
> {
>
> setSafePracticeIndex(safePracticeIndex + 1);
>
> setSectionIndex(0);
>
> }
>
> else //on last section of last unit
>
> {
>
> cycle.activate("SubmitResponse");
>
> }
>
> }
>
> }
>
>
>
> This is a listener and a classic application for extracting out to a service.
> However, the code has the side effect of updating some page-specific
> properties. I suppose that could extract all these properties out to the
> service object as well, but notice that the code is also tapestry-aware.
> Again, I suppose I could have the service method return a Boolean and, then,
> based on that call cycle.activate() from within the page method, but aren't
> services suppose to do all the work?
>
>
>
> It seems like this should all be moved out to a service, but it would need to
> be stateful. Is this allowed?
>
>
>
> Thanks for all your help,
>
> Rob
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.10.24/101 - Release Date: 9/13/2005
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
