Search:

OK, forget it guys -- I've updated my links. I'm not sure you understand the concept of a CDN...

Still down? Not redirected?

The calendar example is still the same old example that's been in Ext since 3.3(?) and then ported to 4.0. Nothing has changed, and Extensible is still totally separate. I'd be interested in...

Steffen, I think the idea with MVC is to get away from the basic web link notion that leads to app logic spaghetti :). Knowing how/where to navigate at any point is business logic that is best suited...

The calendar example has been updated in 4.1, though at the moment I think there might be a couple of bugs in the beta to be fixed before 4.1 final. Or you could always use the Calendar Pro version...

Just realized that I never replied to this. The compat layer was updated on Oct 10 on the download page, so hopefully this issue is now resolved.

Sorry, this was added too:


getModifiedRecords : function(){
return [].concat(this.getNewRecords(), this.getUpdatedRecords());
}


Not sure about commitChanges, will have to look into that....

This will be fixed in 4.1. It looks like this:


rejectChanges : function() {
var me = this,
recs = me.getModifiedRecords(),
len = recs.length,
i = 0;

...

I pretty much replied above -- the 3.x-style metachange event support is back in slated for 4.1 and should be working for CRUD actions as expected. For now we aren't planning on going beyond that...

Hi folks,

Sorry about that comment -- I fully agree that the changes you're asking about are not as discoverable as they could be. We did provide a compatibility layer that was meant to be...

Regarding the OP's patches, I've added in the code to set idProperty on the created implicit model if needed, which makes sense.

I'm still not understanding the first patch though... The current...

The official Ext policy has always been full support for the current and previous major versions. By that policy, Ext 3.x will be officially supported until Ext 5.0 comes out. At this time there is...

I don't understand the Timefield issue or why you are keeping the compatibility layer active if you've already migrated. There's technically no requirement to remove it (other than excess resource...

Interested to know what this is all about... :-/

I have already added that check in a bunch of places that needed it, including for Window.



Yes, good catch -- I have updated the locale files to apply the default to defaultListConfig instead,...

This was simply a bug in the original version of the compat file in that it assumed a config object would always be passed to the store constructor. It has already been fixed in the current version...

It doesn't sound like you are using the compatibility layer, or it's not being referenced correctly. Date.format() is throwing an error because Ext 4 no longer augments the basic JS object prototypes...

The meta event support is back in place a la Ext 3.x, and the issue with the reader creating a new implicit model each time has been fixed. For now I don't think we're planning on going much further...

It will be fixed in the next revision of the compat layer. You can just edit the file and remove the first arg.

FYI, I've committed some changes for 4.1 that add metachange event support back in, along with a new example showing how to use it to reconfigure a grid dynamically.

Unfortunately this is one of the hazards of JavaScript. getParams is private and was refactored internally, but obviously overridden code that calls it would be impacted. Sorry about that, and glad...

Not sure about the patch above, but I'm assuming that if responses that included metadata simply reused any existing store/proxy/model configuration and applied meta changes to them if needed...

Thanks for the detailed reply. While the immediate goal is to at least restore the functionality that 3.x had, we'll definitely take an overall look at this and see if we can improve the meta data...

I'm looking into this. It would help me a lot of anyone could post (ideally) one or more self-contained test files showing the use cases they are trying to achieve. At the very least, a description...

Hey folks, I'm looking into this issue. My initial reaction is that making guaranteeRange public (and required for buffered loading) was probably not ideal to begin with. I'm inclined to say that...