Stemming from Ext.form.BasicForm extending Component...

[Animal]

I think Form should be Components like other... well.. "components". This gives consistency, but also useful functionality. Like destroy().

It needs a destroy method which cleans up its components before calling Component's destroy to clear itself out from the document:



/** Destroys this form, and all its Fields. */
destroy: function() {
this.items.each(function(f){
f.destroy();
});
Ext.form.BasicForm.superclass.prototype.destroy.apply(this, arguments);
}

[jack.slocum]

It coming.. upgrading the form stuff is next on the Ext 2.0 list. First we have to get 1.1 ready. ;)

[Animal]

Great to hear. My overrides file will need a lot of pruning after 2.0 :)

[sjivan]

Can you give us a sense of the compatibilty level between 1.1 and 2.0? I realize that certain classes like BorderLayout are being deprecated and replaced with other classes but what about the compatibility of things like the form class changes that you mention. Are these just compatible enhancements or major overhauls?

Thanks,
Sanjiv

[Animal]

Yes, if ContentPanel is disappearing, will its replacement look similar? eg, have "el", getEl(), update(), the same (or a superset) events etc. Because I'm extending ContentPanel into what will become the cointainer for all our Components. Whenever a JSP is output, it will be put into an aspicio.ComponentPanel.

So I'm really dependent upon the machinery of ContentPanel.

[jack.slocum]

Can you give us a sense of the compatibilty level between 1.1 and 2.0? I realize that certain classes like BorderLayout are being deprecated and replaced with other classes but what about the compatibility of things like the form class changes that you mention. Are these just compatible enhancements or major overhauls?

Thanks,
Sanjiv

The layouts and panels are a complete rewrite and will have very little backwards compatibility. The major components like grids and trees (the ones you likely have more code running against) are not going to change much - only their constructor call.

The primary difference between 2.0 vs 1.0 is that in 2.0 widgets are in charge of their own UI. The layouts are used only for layout purposes and have very little UI creation (only UI elements specific to them). In 1.0, the entire UI was generated by the layout.

In 2.0 a Panel is a widget - it can be used standalone and has it's own UI. BorderLayout (and other layouts) are only in charge of moving/resizing the the Panel. The only UI elements generated by BorderLayout are collapsed and splitter elements. Most layouts have no UI elements at all.

A Panel extends from a Container base class. This means each Panel can house other Panels as well and have a layout. Layouts automatically cascade changes. No more special "NestedLayouts" or unfriendly classes.

There has been lots of discussion on improving the API for BorderLayout. I listen of course, and the API is much easier to work with. So, while there will be some initial code changes required it shouldn't be too ridiculous (a day for a medium sized app?) and the long term benefits will be apparent once you start using it.

[sjivan]

I think you've mentioned elsewhere that the current (1.1) layout code is going to be deprecated in 2.0 but still available for use. While I'm just messing around with Ext whenever I get some free time, the impression of "shifting sand" could scare some more serious users even if the upgrade path is not very expensive. There's a good blog about why tapestry lost a lot of its user base and the primary reason seems to be the changes and revamps introduced with each version. http://jroller.com/page/WarnerOnstine?entry=why_hasn_t_tapestry_been

I'm sure you're well aware of this, but thought I'd just mention it :)

Thanks,
Sanjiv

[jack.slocum]

I think you've mentioned elsewhere that the current (1.1) layout code is going to be deprecated in 2.0 but still available for use. While I'm just messing around with Ext whenever I get some free time, the impression of "shifting sand" could scare some more serious users even if the upgrade path is not very expensive. There's a good blog about why tapestry lost a lot of its user base and the primary reason seems to be the changes and revamps introduced with each version. http://jroller.com/page/WarnerOnstine?entry=why_hasn_t_tapestry_been

I'm sure you're well aware of this, but thought I'd just mention it :)

Thanks,
Sanjiv

Each minor version will always be backwards compatible (unlike Tapestry). With a major version, some things may require an upgrade. This isn't a new concept, it is part of most libraries.

With JavaScript and the web, it is especially important as tons of dead-code just increases the size of the overall files. If you include full backwards compatibility across every major release, by 3.0 we would be at 1.5mb of JS and running so many conditional checks performance suffers.

Don't get me wrong, we are making things backwards compatible where we can, but on some things it wouldn't make sense.

Also, I think it's worth noting that this stuff has been requested on quite a few occasions. We try to listen and respond to those requests with what you (the community) ask for, improve the library and roll out new features. If we spend 3 months working on the things that were requested and it takes people 1 day to upgrade, I think that's a fair deal.

[Animal]

I think it's still early enough in the evolution of Ext for changes like this to be OK. I'll put some overtime in to refactor our classes at work so that people don't notice. As long as my API doesn't change, then our existing pages will all still work.

The thing is that Ext is reaching a really overarching position in terms of UI design and creation, and it evolved from some quickly whipped up (but high quality) classes on Jack's blog. The Layout was an addition which came after the initial Grid and Tab widgets.

There had to be some change from a set of disparate widgets into a totally consistent, page-controlling UI framework.