Re: DialogContext and dataTable
On 6/19/07, samju [EMAIL PROTECTED] wrote:
public class Login extends AbstractViewController{
public String editDataTable(){
FacesContext context = FacesContext.getCurrentInstance();
DialogContext dcontext = DialogHelper.getDialogContext(context);
Object currentuser = ((appBackingBean)
dcontext).getServerModel().getRowData();
(this cause a Class CastException)OR this cause a NullPointerException
this.crudServer = (Server)
getappBackingBean().getServerModel().getRowData();
...
..
return null;
}
}
how to retriev the RowData of a datatable?
how to work with dcontext.setData?
It is not possible to provide you any specific advice without an
understanding of the code in your application. But the following
general thoughts might help you understand what the data property of
a DialogContext instance was intended to be used for.
The basic idea is that, when you have a conversation with a user
(i.e. something that takes more than one request), you want the
equivalent of a scope that lasts longer than a single request, but
shorter than an HttpSession, which typically does not go away until
the user logs off or the session times out. In the absence of a
change to the servlet specification to provide such a scope (something
along these lines *might* happen in a future Servlet spec, or perhaps
in the Web Beans spec, JSR-299). The data property is designed to
provide you a place to deal with this requirement. The DialogContext
instance is thrown away when the dialog is completed -- therefore, so
will the data object that you put here.
There are different strategies to consider for using data:
* By default, unless you do something different, the Dialog framework
will provide you an object of type java.util.Map here. That means, you
can stuff whatever state information you need into the Map, and easily
access it with EL expressions like #{dialogScope.data.foo} for key foo.
The disadvantage is that you give up type checking on the name/value pairs.
* For many applications, the state information I might want to keep is well
understood. A shopping cart is a classic example of this -- it should contain
a list of Item objects, and (during the checkout process itself)
things like the
credit card number and the expiration date. If you can encapsulate this kind
of information into a JavaBean, it is very easy to build unit tests
to validate the
behavior of your shopping cart.
* If you want a JavaBean to represent your state information, the easiest thing
to do is to declare the fully qualified class name of your JavaBean
in the dialog
configuration information. But this only guarantees that the bean instance
gets *created* -- not that it gets *populated*. For that, I
generally define an
action state as the first state of my dialogs that goes and fills in
the necessary
details (copying stuff from request scope or session scope attributes, as
needed).
* It is also possible that you might need a more intimate understanding of
the lifecycle of your dialog with a particular user. If you make
your JavaBean
class implement the DialogContextListener interface, the setData() method
will notice this and automatically register you as a listener, so you can hear
about interesting events like we just switched from state X to state Y, and
we just finished this dialog.
I'm afraid any more specific advice will require more detailed knowledge about:
* What are you trying to do?
* What did you expect to happen?
* What actually happened?
sam
Craig
Re: DialogContext and dataTable
craigmcc wrote:
On 6/19/07, samju [EMAIL PROTECTED] wrote:
public class Login extends AbstractViewController{
public String editDataTable(){
FacesContext context = FacesContext.getCurrentInstance();
DialogContext dcontext = DialogHelper.getDialogContext(context);
Object currentuser = ((appBackingBean)
dcontext).getServerModel().getRowData();
(this cause a Class CastException)OR this cause a NullPointerException
this.crudServer = (Server)
getappBackingBean().getServerModel().getRowData();
...
..
return null;
}
}
how to retriev the RowData of a datatable?
how to work with dcontext.setData?
It is not possible to provide you any specific advice without an
understanding of the code in your application. But the following
general thoughts might help you understand what the data property of
a DialogContext instance was intended to be used for.
The basic idea is that, when you have a conversation with a user
(i.e. something that takes more than one request), you want the
equivalent of a scope that lasts longer than a single request, but
shorter than an HttpSession, which typically does not go away until
the user logs off or the session times out. In the absence of a
change to the servlet specification to provide such a scope (something
along these lines *might* happen in a future Servlet spec, or perhaps
in the Web Beans spec, JSR-299). The data property is designed to
provide you a place to deal with this requirement. The DialogContext
instance is thrown away when the dialog is completed -- therefore, so
will the data object that you put here.
There are different strategies to consider for using data:
* By default, unless you do something different, the Dialog framework
will provide you an object of type java.util.Map here. That means,
you
can stuff whatever state information you need into the Map, and easily
access it with EL expressions like #{dialogScope.data.foo} for key
foo.
The disadvantage is that you give up type checking on the name/value
pairs.
* For many applications, the state information I might want to keep is
well
understood. A shopping cart is a classic example of this -- it should
contain
a list of Item objects, and (during the checkout process itself)
things like the
credit card number and the expiration date. If you can encapsulate this
kind
of information into a JavaBean, it is very easy to build unit tests
to validate the
behavior of your shopping cart.
* If you want a JavaBean to represent your state information, the easiest
thing
to do is to declare the fully qualified class name of your JavaBean
in the dialog
configuration information. But this only guarantees that the bean
instance
gets *created* -- not that it gets *populated*. For that, I
generally define an
action state as the first state of my dialogs that goes and fills in
the necessary
details (copying stuff from request scope or session scope attributes,
as
needed).
* It is also possible that you might need a more intimate understanding
of
the lifecycle of your dialog with a particular user. If you make
your JavaBean
class implement the DialogContextListener interface, the setData()
method
will notice this and automatically register you as a listener, so you
can hear
about interesting events like we just switched from state X to state
Y, and
we just finished this dialog.
I'm afraid any more specific advice will require more detailed knowledge
about:
* What are you trying to do?
i want to update the Content of a datatable:
t:dataTable var=result value=#{dialogScope.alist}
preserveDataModel=true rowId=#{dialogScope.id}
...
h:column
f:facet name=header
t:commandSortHeader columnName=servername arrow=false
h:outputText value=URL/h:outputText
/t:commandSortHeader
/f:facet
h:inputText value=#{result.sname} //this value had to be updated!
rendered=#{result.editable}/h:inputText
/h:column
...
h:column
f:facet name=header
t:commandSortHeader ...
h:outputText value=refresh/h:outputText
/t:commandSortHeader
/f:facet
t:commandButton action=#{worker.updateserver} value=update
disabled=#{not result.editable}
/t:commandButton
/h:column
/t:dataTable
where do the Value of #{dialogScope.alist} comes from?
public String bricketWood(){
..
FacesContext context = FacesContext.getCurrentInstance();
DialogContext dcontext = DialogHelper.getDialogContext(context);
appBackingBean currentuser = (appBackingBean) dcontext.getData();
Query qs = sess.createQuery(from Server);
qs.setProperties(Server.class);
List ID_UserID_ServerName_Status_Roles = qs.list();
currentuser.setAlist(ID_UserID_ServerName_Status_Roles);
...
return you can watch the Wood
}
i use
Re: DialogContext and dataTable
ok i solve the Problem.
i goes like this:
1.get dataClassName instance
2.make instance of another Bean using the getBean(another Bean);
3. get the Row index from UIData something
Like(dbserver.setId(getServerdata().getRowIndex());)
4. get the appropriate another Bean Object from a List setted in Dialog
action wich provide the datatable.
5...do something... session.update(appropriate another Bean Object from
a List);
6.close() the session.
Craig merci for your advice!!
Sam
samju wrote:
craigmcc wrote:
On 6/19/07, samju [EMAIL PROTECTED] wrote:
public class Login extends AbstractViewController{
public String editDataTable(){
FacesContext context = FacesContext.getCurrentInstance();
DialogContext dcontext = DialogHelper.getDialogContext(context);
Object currentuser = ((appBackingBean)
dcontext).getServerModel().getRowData();
(this cause a Class CastException)OR this cause a NullPointerException
this.crudServer = (Server)
getappBackingBean().getServerModel().getRowData();
...
..
return null;
}
}
how to retriev the RowData of a datatable?
how to work with dcontext.setData?
It is not possible to provide you any specific advice without an
understanding of the code in your application. But the following
general thoughts might help you understand what the data property of
a DialogContext instance was intended to be used for.
The basic idea is that, when you have a conversation with a user
(i.e. something that takes more than one request), you want the
equivalent of a scope that lasts longer than a single request, but
shorter than an HttpSession, which typically does not go away until
the user logs off or the session times out. In the absence of a
change to the servlet specification to provide such a scope (something
along these lines *might* happen in a future Servlet spec, or perhaps
in the Web Beans spec, JSR-299). The data property is designed to
provide you a place to deal with this requirement. The DialogContext
instance is thrown away when the dialog is completed -- therefore, so
will the data object that you put here.
There are different strategies to consider for using data:
* By default, unless you do something different, the Dialog framework
will provide you an object of type java.util.Map here. That means,
you
can stuff whatever state information you need into the Map, and
easily
access it with EL expressions like #{dialogScope.data.foo} for key
foo.
The disadvantage is that you give up type checking on the name/value
pairs.
* For many applications, the state information I might want to keep is
well
understood. A shopping cart is a classic example of this -- it should
contain
a list of Item objects, and (during the checkout process itself)
things like the
credit card number and the expiration date. If you can encapsulate
this kind
of information into a JavaBean, it is very easy to build unit tests
to validate the
behavior of your shopping cart.
* If you want a JavaBean to represent your state information, the easiest
thing
to do is to declare the fully qualified class name of your JavaBean
in the dialog
configuration information. But this only guarantees that the bean
instance
gets *created* -- not that it gets *populated*. For that, I
generally define an
action state as the first state of my dialogs that goes and fills in
the necessary
details (copying stuff from request scope or session scope attributes,
as
needed).
* It is also possible that you might need a more intimate understanding
of
the lifecycle of your dialog with a particular user. If you make
your JavaBean
class implement the DialogContextListener interface, the setData()
method
will notice this and automatically register you as a listener, so you
can hear
about interesting events like we just switched from state X to state
Y, and
we just finished this dialog.
I'm afraid any more specific advice will require more detailed knowledge
about:
* What are you trying to do?
i want to update the Content of a datatable:
t:dataTable var=result value=#{dialogScope.alist}
preserveDataModel=true rowId=#{dialogScope.id}
...
h:column
f:facet name=header
t:commandSortHeader columnName=servername arrow=false
h:outputText value=URL/h:outputText
/t:commandSortHeader
/f:facet
h:inputText value=#{result.sname} //this value had to be updated!
rendered=#{result.editable}/h:inputText
/h:column
...
h:column
f:facet name=header
t:commandSortHeader ...
h:outputText value=refresh/h:outputText
/t:commandSortHeader
/f:facet
t:commandButton action=#{worker.updateserver} value=update
disabled=#{not result.editable}
/t:commandButton
/h:column
/t:dataTable
where do the Value of #{dialogScope.alist} comes from?
