The dataTable in ASP.NET is a container - it is a collection of rows, which is a collection of columns that can hold textboxes, checkboxes etc that holds the data being displayed in the browser. In ASP.NET the view components are standalone passive data holders. They are not connected to any data object as JSF components do with value bindings.
The modus operandi is that the program code will give them the data, and from there they will just dutifully maintain the data until they get changed by the user or the program code give them something else. Another big distinction between ASP.NET and JSF is that every Web Form (the .aspx page) is associated with a code behind form (basically a class file). The Web Form and the code behind are compiled together as a single class. The IDE plays a central role in aspx development. It has to make sure that components added at the aspx script got a corresponding object definition in the code behind. JSF is component centric, while ASP.NET is code centric. I don't see one as superior to another, but I do think that JSF spec is too loose at present, and can easily subject itself to anti-patterns. I think framework like Shale is necessary to make JSF successful. Regards, Yee -----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Sunday, 15 January 2006 12:20 PM To: 'MyFaces Discussion' Subject: RE: JSF Flaw: Comopnent not preserving it state On Sun, 2006-01-15 at 01:18 +0800, Yee CN wrote: > Simon, > > It is a lot more complex than it looks on the surface. Looks like I have > opened a can of worms. Yep :-) > > Firstly Hibernate LazyInitializationException problem is inherent in the > SessionPerRequest pattern. It is universal to all web based framework, so it > is not unique to JSF. There are attempts to circumvent this - the SEAM > framework is an example; it is based on JSF/EJB3. It is a well known problem > that everybody learned to deal with it after a while. Agreed. All that Rich was pointing out is that in some cases, serialize/deserialize (what you were recommending) behaves differently from refetch (the current default). So users will need to know about both possible solutions and choose between them depending on their circumstances. > > Secondly the 'correct' behavior should not depend on any particular use > case. It is simply that Restore-View should do what it says - to restore in > the server the view that was being rendered to the browser. That would > include the component tree as well as the data being displayed. I think that h:dataTable is different from components like h:inputText. The difference is that the former's associated data is *user model* objects, while the latter component's data is simply a *java standard datatype*. The select components (eg h:selectOneMenu) probably have the same issues as h:dataTable if the option to bind the value to a Map object is used. And currently I bet both the RI and MyFaces use the same approach as currently used by h:dataTable, ie that after submit the component refetches the data from the user model. I haven't checked that, though, so correction welcome. > > At this stage I still feel that what I proposed in my last posting is the > right approach. There is no ambiguity semantically. Yes the dataModel will > have to be serializable, but I do not see any solution to this problem > otherwise. > > As a point of reference, this is how ASP.NET works - its dataTable is > basically a grid, you would do whatever to populate the grid, and from there > you will be working with rows and columns. There is not dataModel as such. > It is a simpler framework, but does not suffer the problems we are facing > here. I would be interested in learning more about how ASP.NET deals with this. What exactly happens when a dataTable is associated with user objects? > > >The only thing that is quite clear is that someone should patch > >t:dataTable (and maybe h:dataTable) so that on processDecodes it walks > >its children and checks if any implements EditableValueHolder. If not, > >it should skip fetching of the dataModel. I can't see any justification > >for fetching again when the table has no input components. > > I think this is not going to work - as the datatables are generally not > editable, but yet we still need to know which row is being clicked on and > the corresponding record data. Good point. Any command component in the table also needs to have its decode called, and the table associated with the correct DataModel component at that time. This is a lot more common than input components in a table, so my suggested optimisation (while still valid I think) won't help in as many situations as I'd hoped. > > I think this problem should be addressed at the JSF spec level - not at the > level of any particular implementation. At present t:dataTable is workable > with the patterns that I proposed. But h:dataTable is definitely > problematic. I think the preserveDataModel functionality can be emulated by simply using a t:saveState component to save the data model explicitly. This means that your pattern can be applied to h:dataTable too. public class MyBackingBean { private DataModel dataModel; public DataModel getDataModel() { if (this.dataModel != null) return this.dataModel; // create and populate the dataModel } public void setDataModel(DataModel model) { this.dataModel = model; } } in page: <t:saveState id="dataModel" value="#{backingBean.dataModel}"/> <h:dataModel value="#{backingBean.dataModel}" ....> I haven't tested this, but don't see why it wouldn't work. Regards, Simon
