Gelmiş geçmiş en büyük porno sitemiz olan 2pe de her zaman en kaliteli pornoları sunmayı hedefledik. Diğer video sitemiz olan vuam da ise hd porno ağırlıklı çalışmalara başladık.

  1. #1

    Join Date
    Mar 2012
    Posts
    1
    Vote Rating
    0
    mikaellarsson is on a distinguished road

      0  

    Default Ext: 4.2.0 Beta: Object [object Object] has no method 'filterBy'

    Ext: 4.2.0 Beta: Object [object Object] has no method 'filterBy'


    I'm getting the following error while calling sync() on a buffered store:

    ....
    Uncaught TypeError: Object [object Object] has no method 'filterBy' ext-all-debug.js:65308
    Ext.define.getNewRecords ext-all-debug.js:65308
    Ext.define.sync ext-all-debug.js:61855
    buffer-grid.js:124
    Ext.define.fireHandler ext-all-debug.js:43790
    Ext.define.onClick ext-all-debug.js:43780
    Ext.apply.createListenerWrap.wrap ext-all-debug.js:10303
    ...

    code:
    var store = Ext.create('Ext.data.Store', {
    id: 'store',
    buffered: true,
    pageSize: 5000,
    model: 'Employee',


    proxy: {
    type: 'ajax',
    method : 'GET',
    api: {
    read: 'getEmployees.xml',
    update: 'setEmployees.html'
    },
    reader: {
    root: 'employees',
    record: 'employee',
    type: 'xml'
    },
    writer: {
    documentRoot: 'employees',
    record: 'employee',
    type: 'xml',
    writeAllFields: false
    }
    }
    });

    After some investigation on my own I noticed that a buffered store uses Ext.util.LruCache which lacks the method filterBy that Ext.util.AbstractMixedCollection has, which seems to be used on a non-buffered store.
    Can someone confirm if this is a bug or if I'm doing this the wrong way?

  2. #2
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,293
    Vote Rating
    121
    dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all

      1  

    Default


    The results of editing a buffered store (the prerequisite to calling sync) are not likely to be desirable. The concept of a buffered store is a large, partially available, result set. Since the entire data set is never available to the client, edits cannot be properly handled. For example, sorting and filtering cannot be updated properly because these must be handled by the server. Also, the page cache has not provision for adding or removing records.

    If you turn off the buffered config on the store, what you are doing should work fine.
    Don Griffin
    Ext JS Development Team Lead

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  3. #3
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,496
    Vote Rating
    44
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    Actually, I can see why filterBy might be wanted on a sparse store. You still might want to filter what you can see.

    filterBy is implemented in another ticket - the one about findBy.

    findBy is not supported. It's meaningless in a sparse store.

  4. #4
    Sencha Premium Member
    Join Date
    Apr 2012
    Posts
    3
    Vote Rating
    0
    Mayor_McCheese is on a distinguished road

      0  

    Default


    We are getting the same error when using store.commitchanges() on a buffered store. The only reason though is to get rid of the "dirty" red triangle on the edited cell - the actual data manipulation is handled spearately.

    Is there a better (recommended) way to remove the red triangle than commitChanges()?

  5. #5
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,474
    Vote Rating
    280
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      0  

    Default


    Quote Originally Posted by Mayor_McCheese View Post
    Is there a better (recommended) way to remove the red triangle than commitChanges()?
    http://docs.sencha.com/ext-js/4-1/#!...-cfg-markDirty

  6. #6
    Ext JS Premium Member tvanzoelen's Avatar
    Join Date
    Apr 2008
    Location
    Groningen - Netherlands
    Posts
    1,111
    Vote Rating
    30
    tvanzoelen has a spectacular aura about tvanzoelen has a spectacular aura about tvanzoelen has a spectacular aura about

      0  

    Default


    Code:
    findBy is not supported. It's meaningless in a sparse store.
    I disagree with that. Even on a sparse stores there should be some functions to search records in the store or in its page maps. Besides a local filter is common on retrieved records. I have that functionality to narrow down the search on retrieved records.

    I also see that the Ext.util.LruChache isn't documented yet, but in that class should be some search functionality.

    I think backwardscompatibility is lost now by introducing this new 'buffered' in version 4.2. But hopefully with that bufferedgrid plugin I don't need it anymore.

  7. #7
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,496
    Vote Rating
    44
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    There's no "new 'buffered'"

  8. #8
    Ext JS Premium Member tvanzoelen's Avatar
    Join Date
    Apr 2008
    Location
    Groningen - Netherlands
    Posts
    1,111
    Vote Rating
    30
    tvanzoelen has a spectacular aura about tvanzoelen has a spectacular aura about tvanzoelen has a spectacular aura about

      0  

    Default


    I mean the changes made on the store regarding buffering....

    The data structure in the store has been changed in this new version.

  9. #9
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,496
    Vote Rating
    44
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      1  

    Default


    Not much. In 4.1 it was a page map keyed by the page number

    The rendering when buffered has changed. It's now handled by a plugin.

    But buffered stores behave the same way. They are just simpler.

    You don't really need them now unless your dataset is really HUGE.

    You can load a reasonably large dataset into a regular store and just use the bufferedrenderer plugin

  10. #10
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,293
    Vote Rating
    121
    dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all

      1  

    Default


    After some discussion on this last night, it seems that there may be some confusion as to the role of a buffered store and what it represents. In previous versions, many people had to struggle through using a buffered store because what they really needed was buffered rendering. Now in 4.2 these two concerns are separate.

    So why use a buffered store? What is its purpose?

    A buffered store in 4.2 is *only* useful for managing a dataset on the client that cannot be fully loaded and hence is only partially available. By its nature then, this implies the following are true of buffered stores:

    - filtering must be remote
    - sorting must be remote
    - grouping must be remote
    - record lookup is risky
    - editing is unsupported

    Let me take on the first three first. Imagine a dataset of 10,000,000 records. A buffered store will load only a small part of that dataset (for obvious reasons). If one wants to rearrange or reduce that 10M item set, the only place that can happen correctly is where all 10M items reside - the server. So in 4.2, we will automate setting these to true for a buffered store. Whereas in previous versions you had to do this:

    Code:
      {
        buffered: true,
        remoteSort: true,
        remoteGroup: true,
        remoteFilter: true
      }
    Lookup
    Record lookup falls into 2 categories. The most likely use of lookup by record id is because of some action initiated by the user based on records they can see on the screen. Perhaps a row action or similar UI. Obviously, this would be important to support. The "risky" part is any other form of lookup. With a normal (unbuffered) store, a lookup can be performed to see if a record is present *anywhere* in the store.

    The problem here is hiding bugs. The only way to verify an app is to test it. It is likely this kind of (ab)use of a buffered store would go undetected since a testing environment may not have enough data and the buffered store may in fact have all records in its cache. So what appears to work in testing could easily fail in production as a result.

    Our plan here is to support lookup on a buffered store but if there is no match we will at a minimum issue a diagnostic message or perhaps throw an error back. The reason being that when a record is not in the page cache, that does not mean it is not "in the store" ... not in the 10M item sense. It means we don't know the answer to the membership question. If the record were being displayed somehow, then we would surely find it and all would be well.

    Editing
    Many things get exciting during edit. If any set operations are in effect (sorting, grouping or filtering) an edit can completely invalidate the cache. Editing the right field could cause the first record to become the last.

    Because the page cache has never supported saving/syncing, this was always a hack in previous versions to get working. We will not be enforcing any checks here to prevent you from trying to edit a buffered store's content, but this is not supported.... still.
    Don Griffin
    Ext JS Development Team Lead

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"