You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shale.apache.org by samju <ju...@netscape.net> on 2007/06/20 00:39:02 UTC
DialogContext and dataTable
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?
sam
--
View this message in context: http://www.nabble.com/DialogContext-and-dataTable-tf3949337.html#a11204284
Sent from the Shale - User mailing list archive at Nabble.com.
Re: DialogContext and dataTable
Posted by samju <ju...@netscape.net>.
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 <ju...@netscape.net> 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 the fully qualified class name of appBackingBean in the Dialog.xml
>> (otherwise i can´t run the Dialog! i get use to this)
>>
>> now
>> public class Login extends AbstractViewController implements
>> Serializable{
>> ....
>> private Server crudServer;
>> private ListDataModel model;
>> .....
>> public String updateserver(){
>>
>> 1.had to capture the rowdata from (<t:dataTable var="result"
>> value="#{dialogScope.alist}" )
>> 2.then set Server Bean properties
>> 3.open hibernate session, begin transaction, use hibernate session
>> facilities to save,update, merge, delete or add data.
>> 4.return null; still using the same view
>> i tried "t:updateActionListener" tag wich set the crudServer.id of our
>> backing bean and so i can user crudServer.id in this action....didn´t
>> work
>> and as i mentioned in the message befor the usual way to retriev the
>> content of the rowdata did´t work
>> }
>> }
>> * What did you expect to happen?
>> i expect to update my database
>>
>>
>> * What actually happened?
>> when the user enter the "edit mode" and make some changes, the new
>> entries got saved "client Side"as long as the Dialog exist! even if the
>> user left the "edit mode". the value="#{dialogScope.alist}" show the new
>> user entries.so from the frontend view it look like every thinks going
>> well.
>>
>>
>> can You please give a example how to do this"
>> generally define an action state as the first state of my dialogs that
>> goes and fills in the necessary details "
>> i work within one Dialog. so at the begining a action will take place and
>> launch the dialog then another action will deliver the dataBase entries
>> for each user, the user make some changes and logout, dialog end.
>>
>>
>> Sam
>>> sam
>>
>> Craig
>>
>>
>
>
--
View this message in context: http://www.nabble.com/DialogContext-and-dataTable-tf3949337.html#a11218586
Sent from the Shale - User mailing list archive at Nabble.com.
Re: DialogContext and dataTable
Posted by samju <ju...@netscape.net>.
craigmcc wrote:
>
> On 6/19/07, samju <ju...@netscape.net> 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 the fully qualified class name of appBackingBean in the Dialog.xml
> (otherwise i can´t run the Dialog! i get use to this)
>
> now
> public class Login extends AbstractViewController implements Serializable{
> ....
> private Server crudServer;
> private ListDataModel model;
> .....
> public String updateserver(){
>
> 1.had to capture the rowdata from (<t:dataTable var="result"
> value="#{dialogScope.alist}" )
> 2.then set Server Bean properties
> 3.open hibernate session, begin transaction, use hibernate session
> facilities to save,update, merge, delete or add data.
> 4.return null; still using the same view
> i tried "t:updateActionListener" tag wich set the crudServer.id of our
> backing bean and so i can user crudServer.id in this action....didn´t work
> and as i mentioned in the message befor the usual way to retriev the
> content of the rowdata did´t work
> }
> }
> * What did you expect to happen?
> i expect to update my database
>
>
> * What actually happened?
> when the user enter the "edit mode" and make some changes, the new entries
> got saved "client Side"as long as the Dialog exist! even if the user left
> the "edit mode". the value="#{dialogScope.alist}" show the new user
> entries.so from the frontend view it look like every thinks going well.
>
>
> can You please give a example how to do this"
> generally define an action state as the first state of my dialogs that
> goes and fills in the necessary details "
> i work within one Dialog. so at the begining a action will take place and
> launch the dialog then another action will deliver the dataBase entries
> for each user, the user make some changes and logout, dialog end.
>
>
> Sam
>> sam
>
> Craig
>
>
--
View this message in context: http://www.nabble.com/DialogContext-and-dataTable-tf3949337.html#a11209861
Sent from the Shale - User mailing list archive at Nabble.com.
Re: DialogContext and dataTable
Posted by Craig McClanahan <cr...@apache.org>.
On 6/19/07, samju <ju...@netscape.net> 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