You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Rob Dennett <ro...@tmit1.org> on 2005/09/16 18:52:33 UTC
architectural issues
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
Re: architectural issues
Posted by Tomáš Drenčák <to...@gmail.com>.
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 <ro...@tmit1.org>:
> 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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org