You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Luther Baker <lu...@gmail.com> on 2008/12/09 04:19:25 UTC

passivate/activate

Question about the flow.

I GET ViewProject.tml with an activation context of "1" which invokes:
    ViewProject.onActivate(Integer projectId)

I echo the projectId to the screen as a context for a CreateIssue pagelink.
I visit or GET CreateIssue.tml which invokes:
    CreateIssue.onActivate(Integer projectId)
    Createissue.onPassivate()


*Q1*: ?? Why does onPassivate get called here - but not when I visited
ViewProject ??


I complete two fields on the CreateIssue.tml form and submit the form to
CreateIssue.java which invokes
    CreateIssue.onActivate(Integer projectId)
    CreateIssue.onSuccess()


*Q2*: ?? Why isn't CreateIssue.onPassivate called ??


I return CreateIssue.onSuccess returns "ViewProject.class" which invokes:
    ViewProject.onPassivate()
    ViewProject.onActivate(Integer projectId)


*Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml --- and yet,
onPassivate is invoked first. obviously, ViewProject has NO IDEA what
projectId to return since, it was invoked without an ACTIVATION context. Is
that why onPassivate is called? to find an activation context? I know the
docs say that if no activation context is passed - Tapestry will ask the
page for one. Is this how? If so - one need be a bit careful about how
onPassivate is implemented?

Is there an HttpSession free way to forward to have CreateIssue.onSuccess >>
ViewProject.onActivate(Integer projectId) ?

So - I'm not sure how I can forward to another page and pass an activation
context along with the forward ... Is there a way? After taking a look here,
http://tapestry.apache.org/tapestry5/tapestry-core/guide/pagenav.html, I
decided to try to @InjectPage so that

CreateIssue.onSuccess()
{
   nextPage.setProject(project);
   return nextPage;
}

and changed ViewProject.onPassivate() to return project.getId() ... which,
is naturally used by ViewProject.Activate(Integer projectId) which is called
next.

Does that seem like the right way to do this? I don't need to @Persist as
the example has done - since with this method, I can cause onPassivate to
return what onActivate needs ... and I really don't need to save this info
after the request is handled... But, is it safe to assume that the instance
of the page returned by CreateIssue will be the instance that handles the
request ... ie: do I have a pooling concern when I'm directly assigning page
properties?

Man ... this is cool.

-Luther

Re: passivate/activate

Posted by Luther Baker <lu...@gmail.com>.
@Geoff

Thanks for the URLs!

In your first example, you are injecting _page2 into Forms1, setting the
_firstName and _lastName ... and then returning that page instance. Then, in
Forms2 you DEPEND on _firstName and _lastName already being set!

Then, it seems like Forms2.onPassivate will return these (just set) values
to be used as the activation context ...

	Object[] onPassivate() {
		return new String[] { _firstName, _lastName };
	}

Doesn't this pattern contradict your statement:

> Regardng pooling, you should assume the page instance you set up is NOT
the same instance that will be rendered.


IE: you set the firstname and lastname of the injected page ... but then it
seems you are depending on rendering that very instance?

Does that make sense? Thanks for your time and example,

-Luther



public class Forms1 {

	@Property
	private String _firstName;

	@Property
	private String _lastName;

	@Component(id = "names")
	private Form _form;

	@Component(id = "firstName")
	private TextField _firstNameField;

	@Component(id = "lastName")
	private TextField _lastNameField;

	@InjectPage
	private Forms2 _page2;

	void onValidateForm() {
		if (_firstName == null || _firstName.trim().equals("")) {
			_form.recordError(_firstNameField, "First Name is required.");
		}
		if (_lastName == null || _lastName.trim().equals("")) {
			_form.recordError(_lastNameField, "Last Name is required.");
		}
	}

	Object onSuccess() {
		_page2.set(_firstName, _lastName);
		return _page2;
	}


}

public class Forms2 {

	private String _firstName;

	private String _lastName;

	// set() is public so that other pages can use it to set up this page.
	
	public void set(String firstName, String lastName) {
		_firstName = firstName;
		_lastName = lastName;
	}
	
	// onPassivate() is called by Tapestry to get the activation context
to put in the URL.
	
	Object[] onPassivate() {
		return new String[] { _firstName, _lastName };
	}

	// onActivate() is called by Tapestry to pass in the activation
context from the URL.

	void onActivate(String firstName, String lastName) {
		_firstName = firstName;
		_lastName = lastName;
	}

	public String getName() {
		return _firstName + " " + _lastName;
	}
}



On Tue, Dec 9, 2008 at 7:44 AM, Eric Ma <er...@db.com> wrote:

>
> Very useful info, if you change http://localhost:8080 to
> http://jumpstart.doublenegative.com.au:8080 :-)
>
> Thanks Geoff for the great service to the community.
>
> Eric
>
>
> Geoff Callender-2 wrote:
> >
> > Do these links help?
> >
> > http://localhost:8080/jumpstart/examples/input/forms1
> >
> http://localhost:8080/jumpstart/examples/navigation/onactivateandonpassivate/3
> > http://localhost:8080/jumpstart/examples/navigation/whatiscalledandwhen
> >
> > Regardng pooling, you should assume the page instance you set up is
> > NOT the same instance that will be rendered.
> >
> > Geoff
> >
> > On 09/12/2008, at 2:19 PM, Luther Baker wrote:
> >
> >> Question about the flow.
> >>
> >> I GET ViewProject.tml with an activation context of "1" which invokes:
> >>    ViewProject.onActivate(Integer projectId)
> >>
> >> I echo the projectId to the screen as a context for a CreateIssue
> >> pagelink.
> >> I visit or GET CreateIssue.tml which invokes:
> >>    CreateIssue.onActivate(Integer projectId)
> >>    Createissue.onPassivate()
> >>
> >>
> >> *Q1*: ?? Why does onPassivate get called here - but not when I visited
> >> ViewProject ??
> >>
> >>
> >> I complete two fields on the CreateIssue.tml form and submit the
> >> form to
> >> CreateIssue.java which invokes
> >>    CreateIssue.onActivate(Integer projectId)
> >>    CreateIssue.onSuccess()
> >>
> >>
> >> *Q2*: ?? Why isn't CreateIssue.onPassivate called ??
> >>
> >>
> >> I return CreateIssue.onSuccess returns "ViewProject.class" which
> >> invokes:
> >>    ViewProject.onPassivate()
> >>    ViewProject.onActivate(Integer projectId)
> >>
> >>
> >> *Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml ---
> >> and yet,
> >> onPassivate is invoked first. obviously, ViewProject has NO IDEA what
> >> projectId to return since, it was invoked without an ACTIVATION
> >> context. Is
> >> that why onPassivate is called? to find an activation context? I
> >> know the
> >> docs say that if no activation context is passed - Tapestry will ask
> >> the
> >> page for one. Is this how? If so - one need be a bit careful about how
> >> onPassivate is implemented?
> >>
> >> Is there an HttpSession free way to forward to have
> >> CreateIssue.onSuccess >>
> >> ViewProject.onActivate(Integer projectId) ?
> >>
> >> So - I'm not sure how I can forward to another page and pass an
> >> activation
> >> context along with the forward ... Is there a way? After taking a
> >> look here,
> >> http://tapestry.apache.org/tapestry5/tapestry-core/guide/
> >> pagenav.html, I
> >> decided to try to @InjectPage so that
> >>
> >> CreateIssue.onSuccess()
> >> {
> >>   nextPage.setProject(project);
> >>   return nextPage;
> >> }
> >>
> >> and changed ViewProject.onPassivate() to return project.getId() ...
> >> which,
> >> is naturally used by ViewProject.Activate(Integer projectId) which
> >> is called
> >> next.
> >>
> >> Does that seem like the right way to do this? I don't need to
> >> @Persist as
> >> the example has done - since with this method, I can cause
> >> onPassivate to
> >> return what onActivate needs ... and I really don't need to save
> >> this info
> >> after the request is handled... But, is it safe to assume that the
> >> instance
> >> of the page returned by CreateIssue will be the instance that
> >> handles the
> >> request ... ie: do I have a pooling concern when I'm directly
> >> assigning page
> >> properties?
> >>
> >> Man ... this is cool.
> >>
> >> -Luther
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/passivate-activate-tp20908072p20914947.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: passivate/activate

Posted by Geoff Callender <ge...@gmail.com>.
Oops.  Thanks Eric. The links should be:

http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/forms1
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/navigation/onactivateandonpassivate/3
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/navigation/whatiscalledandwhen

Geoff

On 10/12/2008, at 12:44 AM, Eric Ma wrote:

>
> Very useful info, if you change http://localhost:8080 to
> http://jumpstart.doublenegative.com.au:8080 :-)
>
> Thanks Geoff for the great service to the community.
>
> Eric
>
>
> Geoff Callender-2 wrote:
>>
>> Do these links help?
>>
>> http://localhost:8080/jumpstart/examples/input/forms1
>> http://localhost:8080/jumpstart/examples/navigation/onactivateandonpassivate/3
>> http://localhost:8080/jumpstart/examples/navigation/whatiscalledandwhen
>>
>> Regardng pooling, you should assume the page instance you set up is
>> NOT the same instance that will be rendered.
>>
>> Geoff
>>
>> On 09/12/2008, at 2:19 PM, Luther Baker wrote:
>>
>>> Question about the flow.
>>>
>>> I GET ViewProject.tml with an activation context of "1" which  
>>> invokes:
>>>   ViewProject.onActivate(Integer projectId)
>>>
>>> I echo the projectId to the screen as a context for a CreateIssue
>>> pagelink.
>>> I visit or GET CreateIssue.tml which invokes:
>>>   CreateIssue.onActivate(Integer projectId)
>>>   Createissue.onPassivate()
>>>
>>>
>>> *Q1*: ?? Why does onPassivate get called here - but not when I  
>>> visited
>>> ViewProject ??
>>>
>>>
>>> I complete two fields on the CreateIssue.tml form and submit the
>>> form to
>>> CreateIssue.java which invokes
>>>   CreateIssue.onActivate(Integer projectId)
>>>   CreateIssue.onSuccess()
>>>
>>>
>>> *Q2*: ?? Why isn't CreateIssue.onPassivate called ??
>>>
>>>
>>> I return CreateIssue.onSuccess returns "ViewProject.class" which
>>> invokes:
>>>   ViewProject.onPassivate()
>>>   ViewProject.onActivate(Integer projectId)
>>>
>>>
>>> *Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml ---
>>> and yet,
>>> onPassivate is invoked first. obviously, ViewProject has NO IDEA  
>>> what
>>> projectId to return since, it was invoked without an ACTIVATION
>>> context. Is
>>> that why onPassivate is called? to find an activation context? I
>>> know the
>>> docs say that if no activation context is passed - Tapestry will ask
>>> the
>>> page for one. Is this how? If so - one need be a bit careful about  
>>> how
>>> onPassivate is implemented?
>>>
>>> Is there an HttpSession free way to forward to have
>>> CreateIssue.onSuccess >>
>>> ViewProject.onActivate(Integer projectId) ?
>>>
>>> So - I'm not sure how I can forward to another page and pass an
>>> activation
>>> context along with the forward ... Is there a way? After taking a
>>> look here,
>>> http://tapestry.apache.org/tapestry5/tapestry-core/guide/
>>> pagenav.html, I
>>> decided to try to @InjectPage so that
>>>
>>> CreateIssue.onSuccess()
>>> {
>>>  nextPage.setProject(project);
>>>  return nextPage;
>>> }
>>>
>>> and changed ViewProject.onPassivate() to return project.getId() ...
>>> which,
>>> is naturally used by ViewProject.Activate(Integer projectId) which
>>> is called
>>> next.
>>>
>>> Does that seem like the right way to do this? I don't need to
>>> @Persist as
>>> the example has done - since with this method, I can cause
>>> onPassivate to
>>> return what onActivate needs ... and I really don't need to save
>>> this info
>>> after the request is handled... But, is it safe to assume that the
>>> instance
>>> of the page returned by CreateIssue will be the instance that
>>> handles the
>>> request ... ie: do I have a pooling concern when I'm directly
>>> assigning page
>>> properties?
>>>
>>> Man ... this is cool.
>>>
>>> -Luther
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/passivate-activate-tp20908072p20914947.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: passivate/activate

Posted by Eric Ma <er...@db.com>.
Very useful info, if you change http://localhost:8080 to
http://jumpstart.doublenegative.com.au:8080 :-)

Thanks Geoff for the great service to the community.

Eric


Geoff Callender-2 wrote:
> 
> Do these links help?
> 
> http://localhost:8080/jumpstart/examples/input/forms1
> http://localhost:8080/jumpstart/examples/navigation/onactivateandonpassivate/3
> http://localhost:8080/jumpstart/examples/navigation/whatiscalledandwhen
> 
> Regardng pooling, you should assume the page instance you set up is  
> NOT the same instance that will be rendered.
> 
> Geoff
> 
> On 09/12/2008, at 2:19 PM, Luther Baker wrote:
> 
>> Question about the flow.
>>
>> I GET ViewProject.tml with an activation context of "1" which invokes:
>>    ViewProject.onActivate(Integer projectId)
>>
>> I echo the projectId to the screen as a context for a CreateIssue  
>> pagelink.
>> I visit or GET CreateIssue.tml which invokes:
>>    CreateIssue.onActivate(Integer projectId)
>>    Createissue.onPassivate()
>>
>>
>> *Q1*: ?? Why does onPassivate get called here - but not when I visited
>> ViewProject ??
>>
>>
>> I complete two fields on the CreateIssue.tml form and submit the  
>> form to
>> CreateIssue.java which invokes
>>    CreateIssue.onActivate(Integer projectId)
>>    CreateIssue.onSuccess()
>>
>>
>> *Q2*: ?? Why isn't CreateIssue.onPassivate called ??
>>
>>
>> I return CreateIssue.onSuccess returns "ViewProject.class" which  
>> invokes:
>>    ViewProject.onPassivate()
>>    ViewProject.onActivate(Integer projectId)
>>
>>
>> *Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml ---  
>> and yet,
>> onPassivate is invoked first. obviously, ViewProject has NO IDEA what
>> projectId to return since, it was invoked without an ACTIVATION  
>> context. Is
>> that why onPassivate is called? to find an activation context? I  
>> know the
>> docs say that if no activation context is passed - Tapestry will ask  
>> the
>> page for one. Is this how? If so - one need be a bit careful about how
>> onPassivate is implemented?
>>
>> Is there an HttpSession free way to forward to have  
>> CreateIssue.onSuccess >>
>> ViewProject.onActivate(Integer projectId) ?
>>
>> So - I'm not sure how I can forward to another page and pass an  
>> activation
>> context along with the forward ... Is there a way? After taking a  
>> look here,
>> http://tapestry.apache.org/tapestry5/tapestry-core/guide/ 
>> pagenav.html, I
>> decided to try to @InjectPage so that
>>
>> CreateIssue.onSuccess()
>> {
>>   nextPage.setProject(project);
>>   return nextPage;
>> }
>>
>> and changed ViewProject.onPassivate() to return project.getId() ...  
>> which,
>> is naturally used by ViewProject.Activate(Integer projectId) which  
>> is called
>> next.
>>
>> Does that seem like the right way to do this? I don't need to  
>> @Persist as
>> the example has done - since with this method, I can cause  
>> onPassivate to
>> return what onActivate needs ... and I really don't need to save  
>> this info
>> after the request is handled... But, is it safe to assume that the  
>> instance
>> of the page returned by CreateIssue will be the instance that  
>> handles the
>> request ... ie: do I have a pooling concern when I'm directly  
>> assigning page
>> properties?
>>
>> Man ... this is cool.
>>
>> -Luther
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/passivate-activate-tp20908072p20914947.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: passivate/activate

Posted by Geoff Callender <ge...@gmail.com>.
Do these links help?

http://localhost:8080/jumpstart/examples/input/forms1
http://localhost:8080/jumpstart/examples/navigation/onactivateandonpassivate/3
http://localhost:8080/jumpstart/examples/navigation/whatiscalledandwhen

Regardng pooling, you should assume the page instance you set up is  
NOT the same instance that will be rendered.

Geoff

On 09/12/2008, at 2:19 PM, Luther Baker wrote:

> Question about the flow.
>
> I GET ViewProject.tml with an activation context of "1" which invokes:
>    ViewProject.onActivate(Integer projectId)
>
> I echo the projectId to the screen as a context for a CreateIssue  
> pagelink.
> I visit or GET CreateIssue.tml which invokes:
>    CreateIssue.onActivate(Integer projectId)
>    Createissue.onPassivate()
>
>
> *Q1*: ?? Why does onPassivate get called here - but not when I visited
> ViewProject ??
>
>
> I complete two fields on the CreateIssue.tml form and submit the  
> form to
> CreateIssue.java which invokes
>    CreateIssue.onActivate(Integer projectId)
>    CreateIssue.onSuccess()
>
>
> *Q2*: ?? Why isn't CreateIssue.onPassivate called ??
>
>
> I return CreateIssue.onSuccess returns "ViewProject.class" which  
> invokes:
>    ViewProject.onPassivate()
>    ViewProject.onActivate(Integer projectId)
>
>
> *Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml ---  
> and yet,
> onPassivate is invoked first. obviously, ViewProject has NO IDEA what
> projectId to return since, it was invoked without an ACTIVATION  
> context. Is
> that why onPassivate is called? to find an activation context? I  
> know the
> docs say that if no activation context is passed - Tapestry will ask  
> the
> page for one. Is this how? If so - one need be a bit careful about how
> onPassivate is implemented?
>
> Is there an HttpSession free way to forward to have  
> CreateIssue.onSuccess >>
> ViewProject.onActivate(Integer projectId) ?
>
> So - I'm not sure how I can forward to another page and pass an  
> activation
> context along with the forward ... Is there a way? After taking a  
> look here,
> http://tapestry.apache.org/tapestry5/tapestry-core/guide/ 
> pagenav.html, I
> decided to try to @InjectPage so that
>
> CreateIssue.onSuccess()
> {
>   nextPage.setProject(project);
>   return nextPage;
> }
>
> and changed ViewProject.onPassivate() to return project.getId() ...  
> which,
> is naturally used by ViewProject.Activate(Integer projectId) which  
> is called
> next.
>
> Does that seem like the right way to do this? I don't need to  
> @Persist as
> the example has done - since with this method, I can cause  
> onPassivate to
> return what onActivate needs ... and I really don't need to save  
> this info
> after the request is handled... But, is it safe to assume that the  
> instance
> of the page returned by CreateIssue will be the instance that  
> handles the
> request ... ie: do I have a pooling concern when I'm directly  
> assigning page
> properties?
>
> Man ... this is cool.
>
> -Luther


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: passivate/activate

Posted by Luther Baker <lu...@gmail.com>.
Ah ... thanks James.

I didn't realize that rendering a page would invoke onPassivate for the
pages included via *link tags.

I need to look for and watch this happen ... thanks very much.

-Luther



On Tue, Dec 9, 2008 at 1:38 AM, James Hillyerd <ja...@hillyerd.com> wrote:

> (I'm still learning to anyone feel free to correct me!)
>
> Think of it this way: onPassivate() is used to generate links to your a
> page.  Anytime you to t:pagelink, t:actionlink, or t:form - they all create
> an instance of your page (even if you don't specify a context), then call
> onPassivate on it.   I *think* each link/form etc will create it's own
> instance of the page (actually more likely fetching it from the cache) and
> call onPassivate.  So you could see this many times for a single .tml
> render.
> onActivate() doesn't necessarily need to be called first.  You could
> @Inject
> a page, call a setter on it, and then return it from an event handler.  I
> think Tapestry would then call onPassivate and use that to generate the
> redirect URL for the browser.  Then when your browser requests that URL,
> Tapestry will call the pages onActivate method to attempt restore the state
> you wanted.
>
> Does that make sense?  I know the labeling seems backwards, that's what
> made
> it hard for me to grasp - seems weird to passivate something that was never
> activated!
>
> -james
>
> On Mon, Dec 8, 2008 at 7:19 PM, Luther Baker <lu...@gmail.com>
> wrote:
>
> > Question about the flow.
> >
> > I GET ViewProject.tml with an activation context of "1" which invokes:
> >    ViewProject.onActivate(Integer projectId)
> >
> > I echo the projectId to the screen as a context for a CreateIssue
> pagelink.
> > I visit or GET CreateIssue.tml which invokes:
> >    CreateIssue.onActivate(Integer projectId)
> >    Createissue.onPassivate()
> >
> >
> > *Q1*: ?? Why does onPassivate get called here - but not when I visited
> > ViewProject ??
> >
> >
> > I complete two fields on the CreateIssue.tml form and submit the form to
> > CreateIssue.java which invokes
> >    CreateIssue.onActivate(Integer projectId)
> >    CreateIssue.onSuccess()
> >
> >
> > *Q2*: ?? Why isn't CreateIssue.onPassivate called ??
> >
> >
> > I return CreateIssue.onSuccess returns "ViewProject.class" which invokes:
> >    ViewProject.onPassivate()
> >    ViewProject.onActivate(Integer projectId)
> >
> >
> > *Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml --- and
> yet,
> > onPassivate is invoked first. obviously, ViewProject has NO IDEA what
> > projectId to return since, it was invoked without an ACTIVATION context.
> Is
> > that why onPassivate is called? to find an activation context? I know the
> > docs say that if no activation context is passed - Tapestry will ask the
> > page for one. Is this how? If so - one need be a bit careful about how
> > onPassivate is implemented?
> >
> > Is there an HttpSession free way to forward to have CreateIssue.onSuccess
> > >>
> > ViewProject.onActivate(Integer projectId) ?
> >
> > So - I'm not sure how I can forward to another page and pass an
> activation
> > context along with the forward ... Is there a way? After taking a look
> > here,
> > http://tapestry.apache.org/tapestry5/tapestry-core/guide/pagenav.html, I
> > decided to try to @InjectPage so that
> >
> > CreateIssue.onSuccess()
> > {
> >   nextPage.setProject(project);
> >   return nextPage;
> > }
> >
> > and changed ViewProject.onPassivate() to return project.getId() ...
> which,
> > is naturally used by ViewProject.Activate(Integer projectId) which is
> > called
> > next.
> >
> > Does that seem like the right way to do this? I don't need to @Persist as
> > the example has done - since with this method, I can cause onPassivate to
> > return what onActivate needs ... and I really don't need to save this
> info
> > after the request is handled... But, is it safe to assume that the
> instance
> > of the page returned by CreateIssue will be the instance that handles the
> > request ... ie: do I have a pooling concern when I'm directly assigning
> > page
> > properties?
> >
> > Man ... this is cool.
> >
> > -Luther
> >
>
>
>
> --
> James A. Hillyerd <ja...@hillyerd.com>
>

Re: passivate/activate

Posted by James Hillyerd <ja...@hillyerd.com>.
(I'm still learning to anyone feel free to correct me!)

Think of it this way: onPassivate() is used to generate links to your a
page.  Anytime you to t:pagelink, t:actionlink, or t:form - they all create
an instance of your page (even if you don't specify a context), then call
onPassivate on it.   I *think* each link/form etc will create it's own
instance of the page (actually more likely fetching it from the cache) and
call onPassivate.  So you could see this many times for a single .tml
render.
onActivate() doesn't necessarily need to be called first.  You could @Inject
a page, call a setter on it, and then return it from an event handler.  I
think Tapestry would then call onPassivate and use that to generate the
redirect URL for the browser.  Then when your browser requests that URL,
Tapestry will call the pages onActivate method to attempt restore the state
you wanted.

Does that make sense?  I know the labeling seems backwards, that's what made
it hard for me to grasp - seems weird to passivate something that was never
activated!

-james

On Mon, Dec 8, 2008 at 7:19 PM, Luther Baker <lu...@gmail.com> wrote:

> Question about the flow.
>
> I GET ViewProject.tml with an activation context of "1" which invokes:
>    ViewProject.onActivate(Integer projectId)
>
> I echo the projectId to the screen as a context for a CreateIssue pagelink.
> I visit or GET CreateIssue.tml which invokes:
>    CreateIssue.onActivate(Integer projectId)
>    Createissue.onPassivate()
>
>
> *Q1*: ?? Why does onPassivate get called here - but not when I visited
> ViewProject ??
>
>
> I complete two fields on the CreateIssue.tml form and submit the form to
> CreateIssue.java which invokes
>    CreateIssue.onActivate(Integer projectId)
>    CreateIssue.onSuccess()
>
>
> *Q2*: ?? Why isn't CreateIssue.onPassivate called ??
>
>
> I return CreateIssue.onSuccess returns "ViewProject.class" which invokes:
>    ViewProject.onPassivate()
>    ViewProject.onActivate(Integer projectId)
>
>
> *Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml --- and yet,
> onPassivate is invoked first. obviously, ViewProject has NO IDEA what
> projectId to return since, it was invoked without an ACTIVATION context. Is
> that why onPassivate is called? to find an activation context? I know the
> docs say that if no activation context is passed - Tapestry will ask the
> page for one. Is this how? If so - one need be a bit careful about how
> onPassivate is implemented?
>
> Is there an HttpSession free way to forward to have CreateIssue.onSuccess
> >>
> ViewProject.onActivate(Integer projectId) ?
>
> So - I'm not sure how I can forward to another page and pass an activation
> context along with the forward ... Is there a way? After taking a look
> here,
> http://tapestry.apache.org/tapestry5/tapestry-core/guide/pagenav.html, I
> decided to try to @InjectPage so that
>
> CreateIssue.onSuccess()
> {
>   nextPage.setProject(project);
>   return nextPage;
> }
>
> and changed ViewProject.onPassivate() to return project.getId() ... which,
> is naturally used by ViewProject.Activate(Integer projectId) which is
> called
> next.
>
> Does that seem like the right way to do this? I don't need to @Persist as
> the example has done - since with this method, I can cause onPassivate to
> return what onActivate needs ... and I really don't need to save this info
> after the request is handled... But, is it safe to assume that the instance
> of the page returned by CreateIssue will be the instance that handles the
> request ... ie: do I have a pooling concern when I'm directly assigning
> page
> properties?
>
> Man ... this is cool.
>
> -Luther
>



-- 
James A. Hillyerd <ja...@hillyerd.com>