1. #1
    Sencha Premium Member
    Join Date
    Jun 2010
    Posts
    35
    Vote Rating
    0
    eguardiola is on a distinguished road

      0  

    Question Unanswered: What property to use for ModelKeyProvider?

    Unanswered: What property to use for ModelKeyProvider?


    Hi,

    Darrel is using the property name of Kid in List Property Binding example to use it as responsible for providing an unique key for Kid model. Is the property name an acceptable choice for that ? If there is the need to add a new empty Kid to the editing list what is the value for 'name' i should use ?

    I can't think on any 'clean' way to create a value for the property that is responsible for returns the value of an ModelKeyProvider.. whats ur advice on this ?

    Thanks.

  2. #2
    Sencha User PhiLho's Avatar
    Join Date
    Nov 2011
    Location
    Near Paris, France
    Posts
    139
    Answers
    2
    Vote Rating
    1
    PhiLho is on a distinguished road

      0  

    Default


    It works in this simple example, but obviously it will fail in real life for, eg., a list of kids in a classroom.
    In a real application, it is likely that you have some kind of id associated to your data: can be a social security number for a person, perhaps associated to a birthday or to the name (if kids have same SN than one of their parents; name is better here, for twins...), or any identifier you can design for your data.

  3. #3
    Sencha Premium Member
    Join Date
    Jun 2010
    Posts
    35
    Vote Rating
    0
    eguardiola is on a distinguished road

      0  

    Default


    Yes this is correct but the problem is how to generate a new id on the client.

    You can be editing Kids in the client with ids 1, 2, 4, 7... ok. But if you want to add a new Kid to the list what id should you use ? Should you create an Id generator on the client side ? Unsaved models instances usually have null Ids not client side generated ones.

    Sorry my english.

  4. #4
    Ext GWT Premium Member icfantv's Avatar
    Join Date
    Sep 2011
    Location
    Superior, CO
    Posts
    411
    Answers
    20
    Vote Rating
    21
    icfantv will become famous soon enough icfantv will become famous soon enough

      0  

    Default


    Client-side id generation is probably not the best idea in most situations. I would suggest the client-side code make an attempt to create a new Kid via a call to the server and let the server-side code create and return the new Kid object (and its id). Then, all you have to do on the client-side is add the Kid to the data store and everything else should fall into place.

    You definitely want to be careful with the key value provider because if you use a CheckBoxSelectionModel in a grid and one or more of your rows contain the same value return for the key, the checkboxes for those rows will not work. They will still be selectable via the "select all" checkbox in the header, however.

  5. #5
    Sencha Premium Member
    Join Date
    Jun 2010
    Posts
    35
    Vote Rating
    0
    eguardiola is on a distinguished road

      0  

    Default


    I usually put null Id for the new objects but if the Store needs real Ids... i can't provide real Id on editing time.

    ModelKeyProvider was optional before.. why now is required ?

  6. #6
    Sencha User PhiLho's Avatar
    Join Date
    Nov 2011
    Location
    Near Paris, France
    Posts
    139
    Answers
    2
    Vote Rating
    1
    PhiLho is on a distinguished road

      0  

    Default


    We do as icfantv described: upon creating a new object, we don't add it immediately to the store but we send it via a DTO to the server which checks its validity. If OK, it adds it to the main model and thus assign it an id, then it sends it back to the client which finally add it to the store. Thus, we are sure to be consistent, that data is checked (against duplicates, etc.) and stored (no risk of loosing data), and so on.

    These asynchronous ping-pong exchanges with the server might need to get used to do, but they are worth it.

    Some GWT applications are client-side only (!), then in this case, generating an id on the fly can make sense and shouldn't be too hard to do (eg. having a static long counter).

  7. #7
    Sencha Premium Member
    Join Date
    Jun 2010
    Posts
    35
    Vote Rating
    0
    eguardiola is on a distinguished road

      0  

    Default


    I'm editing a object graph model all in the client side and then post back the entire graph to the server to save it. Deleting the old graph from DB and recreating it with the edited one.

    So i realized the id can be whatever on client side. Only needs to be unique for each model.. a negative counter by example :-P

    Thanks.

  8. #8
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    Answers
    109
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      1  

    Default


    Requirements for the model keys are that they are unique, and consistent. Unique so that two different models will not have the same id while in the store at the same time, and consistent so that if the model is passed into the ModelKeyProvider twice, the same key should be produced.

    We require a ModelKeyProvider for a few reasons. First, for performance - by requiring a key provider, we can be sure there will be an efficient way to translate objects into strings so that a FastMap<M> can be used to track objects as changed happen. In GXT 2 there were often several code paths possible for the model key provider being present or missing - by assuming we have it, that code gets cleaner, easier to read, and easier to extend. Second, consistency with GWT data widgets

    The key can be generated on the client, as it will be tracked only by the Stores and components which use the store. In fact, if you don't override toString() and don't intend to call Store.update(M) on a different model instance than is present in the store, a ModelKeyProvider<Object> could be defined which just returns toString(), which should get a unique string. If using RequestFactory, stableId() could be used in the same way.

  9. #9
    Ext GWT Premium Member icfantv's Avatar
    Join Date
    Sep 2011
    Location
    Superior, CO
    Posts
    411
    Answers
    20
    Vote Rating
    21
    icfantv will become famous soon enough icfantv will become famous soon enough

      0  

    Default


    Quote Originally Posted by Colin Alworth View Post
    Requirements for the model keys are that they are unique, and consistent. Unique so that two different models will not have the same id while in the store at the same time, and consistent so that if the model is passed into the ModelKeyProvider twice, the same key should be produced.
    If this is the case, can you please explain why the list store is not a SortedSet? Was it simply for flexibility? I.e., every model object that exists in a store nay not have different hashcode values? Thanks.

  10. #10
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    Answers
    109
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    SortedSet might be more accurate - it is a SortedSetStore which isn't always sorted using the same comparator and sometimes filtered.

    Actually, I don't believe that ListStore does any checks that you don't add the same item twice, but only uses the keys for managing records and changes - if a change is made to one item, typically one would assume it should be made for all instances of that object. Store.update would get a little confusing too with multiple entries in the collection that are the same.

    The main reason we call it a list is that order is the main important part - ui elements don't generally make a lot of sense to draw exactly the same thing twice in a row (a SortedSet that allows duplicates almost certainly keeps them next to each other, as they are the same, so would be sorted together). It is a good thought, making sure everything is named precisely, but I don't think it is a surprising constraint that a ListStore, a cache for an ordered collection displayed visually, doesn't allow duplicates.

    Do you have a use case where you want a 'real' ListStore, accepting duplicate items? From a quick review of the code, as long as you don't call update(M), findModelWithKey(String), or findModel(M), it should work for you.

Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..." hd porno faketaxi