You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2005/11/17 15:03:58 UTC
managed-property not set during valueChangeEvent?
Hi!
Is it true that managed-properties are not processed during a
valueChangeEvent?
I mean my managed-property IS null with myfaces SVN head during such an
event.
Is this by intention?
---
Mario
Re: managed-property not set during valueChangeEvent?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Mario Ivankovits wrote:
> Mike Kienenberger wrote:
>> Well, you can either implement StateHolder and restore the values in
>> restoreState
I tried it now but it wont work.
If I implement SateHolder only in my managed bean I'll get a "Not
Serializable Exception" when using x:saveState.
So it looks like I have to stick to my "State" inner class if I still
would like to have dependency injection.
---
Mario
Re: managed-property not set during valueChangeEvent?
Posted by Mike Kienenberger <mk...@gmail.com>.
There's no real advantage of using StateHolder over Serializable.
Whichever one you like is fine. Neither will initialize/preserve your
managed properties without your intervention.
You may as well stick with Serializable if you've already got that in place.
On 11/18/05, Mario Ivankovits <ma...@ops.co.at> wrote:
> Mike Kienenberger wrote:
> > Well, you can either implement StateHolder and restore the values in
> > restoreState
> If I implement StateHolder the bean will be created using the default
> faces routines, right?
> So this will initialize the properties as described by the
> managed-property, isnt it?
>
> This will be great, I'll try this.
>
> If this works, next thing will be to create some helper class which will
> create/read the save/restoreState structure using reflection and
> skipping transient members.
>
> Thanks!
> ---
> Mario
>
>
Re: managed-property not set during valueChangeEvent?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Mike Kienenberger wrote:
> Well, you can either implement StateHolder and restore the values in
> restoreState
If I implement StateHolder the bean will be created using the default
faces routines, right?
So this will initialize the properties as described by the
managed-property, isnt it?
This will be great, I'll try this.
If this works, next thing will be to create some helper class which will
create/read the save/restoreState structure using reflection and
skipping transient members.
Thanks!
---
Mario
Re: managed-property not set during valueChangeEvent?
Posted by Mike Kienenberger <mk...@gmail.com>.
Well, you can either implement StateHolder and restore the values in
restoreState or implement readObject() and relink them there using
code like this.
FacesContext facesContext = FacesContext.getCurrentInstance();
setShopContext(facesContext.getApplication()
.getVariableResolver().resolveVariable(facesContext, "prShopContext"));
http://wiki.apache.org/myfaces/FAQ#Bean
On 11/18/05, Mario Ivankovits <ma...@ops.co.at> wrote:
> Mario Ivankovits wrote:
> > So my next guess is: I use saveState and then the bean isnt generated
> > through the managed bean facility and thus no managed property
> > configuration will be processed.
> > I'll look in this direction.
> Ok, it IS saveState.
> If you saveState, but left out (transient) those members which are set
> through managed-property those members are no reset.
>
> I use a "context" bean which is set on my beans using
> <managed-property>
> <property-name>shopContext</property-name>
> <value>#{prShopContext}</value>
> </managed-property>
>
> In saveState this "shopContext" should not be saved nor restored (thus
> transient), but should be set using the default myFaces factories.
> I think it is not possible to fix saveState to reinitialize the bean as
> values set by <managed-property might only be the "default value" and
> can be overwritten by the bean.
> Thus, it cant know if a managedProperty should be reset or not.
>
> The object should be created throug myFaces, and its state restored onto
> this object.
> As far as I know this is only possible if one implement something like
> saveState() and restoreState(), but this is error prone.
>
> Another solution can be to not directly save the bean but a inner class
> instance which holds the state.
>
> public class MyBean
> {
> public static class State implements Serializable
> {
> private String needSave;
> }
>
> private String transientNotSaved;
> }
>
> and use saveState that way:
> <x:saveState value="#{myBean.state}" />
>
> Then myBean is create through myFaces and the "state" restored through
> saveState.
>
> I can add this "trap" to the wiki if you find this information important
> enough.
>
> ---
> Mario
>
>
Re: managed-property not set during valueChangeEvent?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Mario Ivankovits wrote:
> So my next guess is: I use saveState and then the bean isnt generated
> through the managed bean facility and thus no managed property
> configuration will be processed.
> I'll look in this direction.
Ok, it IS saveState.
If you saveState, but left out (transient) those members which are set
through managed-property those members are no reset.
I use a "context" bean which is set on my beans using
<managed-property>
<property-name>shopContext</property-name>
<value>#{prShopContext}</value>
</managed-property>
In saveState this "shopContext" should not be saved nor restored (thus
transient), but should be set using the default myFaces factories.
I think it is not possible to fix saveState to reinitialize the bean as
values set by <managed-property might only be the "default value" and
can be overwritten by the bean.
Thus, it cant know if a managedProperty should be reset or not.
The object should be created throug myFaces, and its state restored onto
this object.
As far as I know this is only possible if one implement something like
saveState() and restoreState(), but this is error prone.
Another solution can be to not directly save the bean but a inner class
instance which holds the state.
public class MyBean
{
public static class State implements Serializable
{
private String needSave;
}
private String transientNotSaved;
}
and use saveState that way:
<x:saveState value="#{myBean.state}" />
Then myBean is create through myFaces and the "state" restored through
saveState.
I can add this "trap" to the wiki if you find this information important
enough.
---
Mario
Re: managed-property not set during valueChangeEvent?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Craig,
sorry it wasnt my intention to attack shale ;-)
> As Simon points out, managed bean property initialization occurs
> *only* if the managed bean facility actually created the bean. This
> is exactly equivalent to the way that <jsp:setProperty> elements
> inside a <jsp:useBean> element are *only* processed if the bean was
> actually created. It has nothing to do with Shale -- this is
> fundamental to the way that the JSF specification defines the
> functionality of the managed bean facility.
Ok, now I got it!
So my next guess is: I use saveState and then the bean isnt generated
through the managed bean facility and thus no managed property
configuration will be processed.
I'll look in this direction.
---
Mario
Re: managed-property not set during valueChangeEvent?
Posted by Craig McClanahan <cr...@apache.org>.
On 11/17/05, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Simon Kitching wrote:
> >> Is it true that managed-properties are not processed during a
> >> valueChangeEvent?
> >>
> >> I mean my managed-property IS null with myfaces SVN head during such
> >> an event.
> >>
> >> Is this by intention?
> > Do you have any more info?
> I'll try to workout a small example, maybe its a problem in shale?
As Simon points out, managed bean property initialization occurs *only* if
the managed bean facility actually created the bean. This is exactly
equivalent to the way that <jsp:setProperty> elements inside a <jsp:useBean>
element are *only* processed if the bean was actually created. It has
nothing to do with Shale -- this is fundamental to the way that the JSF
specification defines the functionality of the managed bean facility.
Thanks Simon!
>
> Craig
Re: managed-property not set during valueChangeEvent?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Simon Kitching wrote:
>> Is it true that managed-properties are not processed during a
>> valueChangeEvent?
>>
>> I mean my managed-property IS null with myfaces SVN head during such
>> an event.
>>
>> Is this by intention?
> Do you have any more info?
I'll try to workout a small example, maybe its a problem in shale?
Thanks Simon!
Re: managed-property not set during valueChangeEvent?
Posted by Simon Kitching <sk...@obsidium.com>.
Hi Mario,
Mario Ivankovits wrote:
> Is it true that managed-properties are not processed during a
> valueChangeEvent?
>
> I mean my managed-property IS null with myfaces SVN head during such an
> event.
>
> Is this by intention?
I'm pretty sure managed properties are *always* configured whenever a
managed bean instance is created. See ManagedBeanBuilder.java.
The phase doesn't matter as far as I can see; whenever an EL expression
of form "#{bean....}" is evaluated and the bean doesn't exist then it is
immmediately created and initialised. See
VariableResolverImpl.resolveVariable.
Do you have any more info?
Regards,
Simon