You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by 王曾wang_zeng <wa...@gmail.com> on 2006/05/02 01:48:54 UTC
Re: Where dose JSP works in JSF request lifecycle?
2006/4/28, Craig McClanahan <cr...@apache.org>:
>
> You are correct. There is special handling defined in the Restore View
> phase. If that phase discovers that there is no state to be restored
> , then JSF will immediately forward to Render Response phase.
>
> So, how do you make sure that the right dynamic data gets loaded so that
> the
> page displays the right stuff? That's where Shale comes in handy. If
> your
> backing bean implements the ViewController interface, then prerender()
> will
> get called just before the JSP page is invoked. This is the perfect place
> to grab any data you need from your database to display the requested
> page.
>
> Craig
>
>
Craig, When the page is first viewed,If I want to dynamically set the inital
value of the property of the UI component (for exsample, text of a
textbox), how can I set the value of it. Even if I crab the data in
prerender() method, how can I get the reference to the component without a
tree in session, when Restore the View phase is skiped.
--
Wang Zeng
Re: Where dose JSP works in JSF request lifecycle?
Posted by Craig McClanahan <cr...@apache.org>.
On 5/3/06, 王曾wang_zeng <wa...@gmail.com> wrote:
>
> But the prerender() is called before the tag being processed. when the
> prerender() is called, the reference is still null if this is an initial
> request. Tree hasn't been constructed, when the prerender() is called.
> I guess maybe if I want to set a initial value of a component when the
> page
> is viewed the first time, the reference to the component must be assigned
> using a *new* keyword.
Not quite.
IF you use a "binding" attribute on your component, AND IF the getter method
on your backing bean returns a component instance that has been previously
configured (in the backing bean's prerender() method), THEN the component
tree will include *your* instance instead of creating a new one. The nitty
gritty details of how this works are found in Section 3.1.5 of the JSF
1.1specification.
Craig
Re: Where dose JSP works in JSF request lifecycle?
Posted by 王曾wang_zeng <wa...@gmail.com>.
But the prerender() is called before the tag being processed. when the
prerender() is called, the reference is still null if this is an initial
request. Tree hasn't been constructed, when the prerender() is called.
I guess maybe if I want to set a initial value of a component when the page
is viewed the first time, the reference to the component must be assigned
using a *new* keyword.
2006/5/4, Craig McClanahan craigmcc@apache.org:
>
> No ... if the getter method returns null, the tag handler will create a
> new
> component instance, just as if you hadn't declared a binding attribute ...
> but then it will call the setter so your backing bean still has access to
> the component instance actually being used.
>
> --
> > Wang Zeng
> >
> > Craig
>
>
--
Wang Zeng
Re: Where dose JSP works in JSF request lifecycle?
Posted by Craig McClanahan <cr...@apache.org>.
On 5/3/06, 王曾wang_zeng <wa...@gmail.com> wrote:
>
> Oh,yeah,I see, that's why you use "new" keyword in the code above.
>
> >private HtmlOutputText dynamicText = new HtmlOutputText();
>
> Then,I have a pretty weird idea. If you dosen't new a HtmlOutputText,will
> there be a NullpointerException popped up in this case?
No ... if the getter method returns null, the tag handler will create a new
component instance, just as if you hadn't declared a binding attribute ...
but then it will call the setter so your backing bean still has access to
the component instance actually being used.
--
> Wang Zeng
>
> Craig
Re: Where dose JSP works in JSF request lifecycle?
Posted by 王曾wang_zeng <wa...@gmail.com>.
Oh,yeah,I see, that's why you use "new" keyword in the code above.
>private HtmlOutputText dynamicText = new HtmlOutputText();
Then,I have a pretty weird idea. If you dosen't new a HtmlOutputText,will
there be a NullpointerException popped up in this case?
--
Wang Zeng
Re: Where dose JSP works in JSF request lifecycle?
Posted by Craig McClanahan <cr...@apache.org>.
On 5/2/06, 王曾wang_zeng <wa...@gmail.com> wrote:
>
> Graig, that's very kind of you.
> Are these aproachs feasible,when the page is requested by an inital
> request?
> When an inital request arrives, the view restoring phase is skipped and
> JSF
> goes to the response rendering phase directly. Then there should be no
> component tree constructed at all ,when prerender() is called. I wonder
> how
> can we access the component when they have not been constructed?
Yes, both approaches work even in this scenario.
In the first approach (component binding) the rules for creating the
component tree the first time (which would occur during Render Response
phase) are very specific -- *if* the component has a binding attribute, call
the getter method, and *if* it returns a component, then use that instance
in the tree instead of creating a new one. Thus, the component you have
defined in your backing bean is the one that will be used.
For the second approach, you do not actually care about which component
instance is used -- what you care is that the bindings point at the data you
want to manipulate. So, it works the first time or subsequent times as
well, since the binding expressions point at your backing bean's properties.
Craig
--
> Wang Zeng
>
>
Re: Where dose JSP works in JSF request lifecycle?
Posted by 王曾wang_zeng <wa...@gmail.com>.
Graig, that's very kind of you.
Are these aproachs feasible,when the page is requested by an inital request?
When an inital request arrives, the view restoring phase is skipped and JSF
goes to the response rendering phase directly. Then there should be no
component tree constructed at all ,when prerender() is called. I wonder how
can we access the component when they have not been constructed?
--
Wang Zeng
Re: Where dose JSP works in JSF request lifecycle?
Posted by Craig McClanahan <cr...@apache.org>.
On 5/1/06, 王曾wang_zeng <wa...@gmail.com> wrote:
>
> 2006/4/28, Craig McClanahan <cr...@apache.org>:
> >
> > You are correct. There is special handling defined in the Restore View
> > phase. If that phase discovers that there is no state to be restored
> > , then JSF will immediately forward to Render Response phase.
> >
> > So, how do you make sure that the right dynamic data gets loaded so that
> > the
> > page displays the right stuff? That's where Shale comes in handy. If
> > your
> > backing bean implements the ViewController interface, then prerender()
> > will
> > get called just before the JSP page is invoked. This is the perfect
> place
> > to grab any data you need from your database to display the requested
> > page.
> >
> > Craig
> >
> >
> Craig, When the page is first viewed,If I want to dynamically set the
> inital
> value of the property of the UI component (for exsample, text of a
> textbox), how can I set the value of it. Even if I crab the data in
> prerender() method, how can I get the reference to the component without a
> tree in session, when Restore the View phase is skiped.
Two approaches to this are fairly common.
* Use the "binding" attribute to bind a component instance into your backing
bean, which will get used when the component tree is actually constructed:
<h:outputText binding="#{backing.dynamicText}" .../>
public class Backing implements ViewController {
private HtmlOutputText dynamicText = new HtmlOutputText();
public HtmlOutputText getDynamicText() { return this.dynamicText; }
public void setDynamicText(HtmlOutputText dynamicText) {
this.dynamicText = dynamicText; }
...
public void prerender() {
dynamicText.setVaue("Dynamically calculated value");
}
}
* Use the "value" attribute to bind the component's value property to
a string property of your backing bean
<h:outputText value="#{backing.dynamicValue}" .../>
public class Backing implements ViewController {
private String dynamicValue;
public String getDynamicValue() { return this.dynamicValue; }
public void setDynamicValue(String dynamicValue) { this.dynamicValue =
dynamicValue; }
...
public void prerender() {
dynamicVaue = "Dynamically calculated value";
}
}
The first technique is convenient when you need to dynamically calculate
more than one property of the component (just make sure you don't also try
to set the corresponding attributes in the JSP page). The second technique
is simpler when you just want to dynamically bind the "value" property, and
also makes it a bit easier to build unit tests for the backing bean class.
--
> Wang Zeng
>
>
Craig