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
