Backwards compatibility (DEPRECATED)

[watrboy00]

Since we are in beta 3 (I believe) and this is a new framework with notes saying that things might change...should we already be seeing this?

// Backwards compatibility (DEPRECATED)
Ext.Container.LAYOUTS = Ext.layout.TYPES;

[watrboy00]

// Backwards compatibility with desktop
Ext.CompositeElementLite = Ext.CompositeElement;

It's a mobile platform...who cares about the desktop!

[Jamie Avins]

We're trying to keep some level of familiarity across the platforms, but this one in particular will probably go away.

[watrboy00]

Oh for sure. I think there should be HUGE similarities between the two. I just don't think there should be backward compatibility all over the place if there wasn't a previous version to be backward compatible with. Just want to see that the framework isn't being bloated for no apparent reason.

[watrboy00]

These are the other ones...

//backwards compatibility
Ext.data.DataProxy = Ext.data.Proxy;

//[deprecated 5.0]
Ext.ns('Ext.data.Record');

//Backwards compat
Ext.data.Record.id = Ext.data.Model.id;
//[end]

//backwards compatibility, remove in Ext JS 5.0
Ext.data.HttpProxy = Ext.data.AjaxProxy;

//backwards compatibility, will be deprecated in 5.0
this.nocache = this.noCache;

// backwards compat, convert idPath or id / success
// DEPRECATED - remove this in 5.0
Ext.applyIf(config, {
idProperty : config.idPath || config.id,
successProperty: config.success
});

// backwards compat
Ext.data.SimpleStore = Ext.data.ArrayStore;

//backwards compatibility - deprecate in next major release
this.label = this.label || this.fieldLabel;

[stever]

Well, I imagine it is because a site's data structure is often built on top of Ext classes. To provide a desktop and a mobile UI, one can switch out the UI layer to the appropriate one, but much of how your data works will be the same and so ought to be the underlying layers where appropriate.

[watrboy00]

I'm sorry am not tracking what you say...

I think it is good design that your back end data structure should remain consistent whether you are display it on a desktop browser or mobile browser. You *should* just have to switch out the UI. Now where I am not following is how the back end data structure relates to the front end UI and the client side lib having to deal with backwards compatibility. When you swap the desktop UI for the mobile one you would also have to switch the associated client side code to make the UI functional. You wouldn't be able to use Ext Core/3.x lib on a mobile device with much success much like you wouldn't be able to use the Touch lib on a desktop browser. Sure they might work but probably not as expected or efficient.

My main point was because most of the mobile UI lib will not share much, if any, components from the desktop version why are we maintaining backwards compatibility already at this point. There won't be any cross over. Since Touch v1.0 RTM hasn't been released what's the point? It's in beta still. Things change daily I'm sure. I would say starting after 1.0 is released backwards compatibility should be managed. Until then seems pointless.

[Jamie Avins]

Some of the code base is being developed in parallel with Ext 4.0 and your seeing parts moving back and forth between the code bases. We'll get them straightened out as things become more solidified.

[TommyMaintz]

Almost all of the examples you found are within the data package which is the only piece of code that is shared one on one with Ext 4.0. This means that if you write an app for desktop and mobile, you can use all the same stores, models and validations for both versions of the app.

You just have to switch out the UI components.

We will investigate if any of them can be removed though, like label -> fieldLabel and CompositeElementLite. The others are all data related.