This is more of a personal blog post I am creating for my own referecne. We have migrated one of our apps from July/August version of Ext.Net (based on ExtJs 3.2.1) to Feb 19, 2011 (Revision 3469) version of Ext.Net (based on ExtJs 3.3.0).
There have been some breaking changes that I am enumerating for my reference so I can use this list when planning migration of other projects. This is a work in progress and I might add points to it as I find them out. So, here are some breaking changes that I have found:
- Events are now fired immediately on Components when they have a config option specified which can be changed through a method available on Component and that method causes an event to fire. Let me take an example, consider:
<ext:Checkbox runat="server" ID="chk1" Checked="true"> <Listeners> <Check Fn="chkChanged" /> </Listeners> </ext:Checkbox>This component now have its “check” event/listener fired immediately after the Component renders (in ExtJs 3.3.0). This did not used to be the case with ExtJs 3.2.1. Further, the event fires immediately as a component renders and before other components after this component have rendered.
This can cause extensive breaking of existing code, if you refer to components after this component in the check listener (i.e. in chkChanged method).Fix: Do not set Checked to true in config. Rather allow all components to Render and initialize them at the end (e.g. chk1.setValue(true);).
The confusing aspect is this does not happen for all components and for all properties. e.g. setting Text for TextField in config does not raise the Change event. You will need to test which components and properties you use are affected. A rule of thumb would be not to assign any values to any components in config, an do it in the end after all componenets have rendered.
Further this would be tricky if your components are not rendered immediately (e.g. if CheckBox is inside a Panel of a TabPanel, which is not active initially. The Checkbox renders and the corresponding event fires only when the owner Panel is activated the first time and it gets rendered).
- Calling DataBind on Store leads to “load” event on store firing. This is related to the above in a sense. Consider this:
this.Store1.DataSource = myDataTable; this.Store1.DataBind();
This code leads to firing of “load” event on Store immediately as Store is instantized (did not used to happen in ExtJs 3.2.1). Again becomes problematic if you have “load” listener on Store that references Components that are not yet rendered because they happen to be after the Store.
Fix: Set AutoLoad to false on Store and manually call load on Store when all components have rendered.
- CompositeField items earlier used to be present in: fld.items (which was an array accessible as fld.items[0] etc.). But now, in consistency with other parts of the ExtJs framework, the items are present in fld.items.items (accessible as fld.items.items[0] etc.).
- Ext.Net control id tokens are not replaced properly sometimes. In out present case, we sent an async Ajax request to the server afer the page has rendered.
In that async request, a new Panel gets rendered to the page. The content of the panel is a UserControl which contains nested UserControls. In the nested UserControls, we were using <ext:Panel> IDs as tokens in Handlers. e.g.
<Click Handler=”#{Pnl1}.something ” />
With the latest Ext.Net version, these IDs are replaced by their raw html dom on the client (it should have been an Ext.Component instance as earlier). I have not yet tried to create a reproducible case, and report it to Ext.Net team.
- PagingMemoryProxy now only loads data if passed to its constructor explicitly. e.g. earlier this used to work:
{syntaxhighlighter brush: jscript;fontsize: 100; first-line: 1; }var store = new Ext.ux.data.PagingStore({
// store configs
autoLoad: true,
autoDestroy: true,
proxy: new Ext.data.PagingMemoryProxy(),
reader: new Ext.data.JsonReader({
idProperty: ‘id’,
// reader configs
fields: [your fields here]
}),
data: dataArray
});{/syntaxhighlighter}But it does not work now, nad instead dataArray needs to be passed to PagingMemoryProxy constructor.{syntaxhighlighter brush: jscript;fontsize: 100; first-line: 1; }var store = new Ext.ux.data.PagingStore({
// store configs
autoLoad: true,
autoDestroy: true,
proxy: new Ext.data.PagingMemoryProxy(dataArray),
reader: new Ext.data.JsonReader({
idProperty: ‘id’,
// reader configs
fields: [your fields here]
})
});{/syntaxhighlighter} - I have found instances where Containers having raw html as content which further contains components are not laid out properly. e.g. consider this:
<ext:Panel runat="server"> <Content> <table style="width: 100%"> <tr> <td> <ext:Panel runat="server" Layout="Form"> <Items> Your items here... </Items> </ext:Panel> </td> </tr> <table> </Content> </ext:Panel>Items were not laid out properly after the upgrade. Had to eliminate html and use layouts and nested containers to make it work like before.
- Feb 20, 2011 – In an unmodified Store, if you add a Record, and afterwards call “load” on the Store, it triggers a Dirty Confirmation dialog in the current version of Ext.Net (this relates specifically to Ext.Net and is not a feature of ExtJs). It did not use to happen earlier.
Fix: Either set WarningOnDirty to false on the Store. However, this would suppress all dirty warning dialogs. If you do not want this to happen, and want the dialog suppressed only for the case above, then call “commitChanges” or “rejectChanges” on the Store before invoking “load”.
That’s the changes/fixes I can currently recall. I would update this post as I recall/find additional changes. I haven’t enumerated a couple of issues above because they were reported to Ext.Net ream and already stand fixed in the latest Ext.Net version in SVN.
Recent Comments