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 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.
