1. #1
    Sencha User
    Join Date
    Sep 2012
    Posts
    31
    Answers
    2
    Vote Rating
    1
    billsalvucci is on a distinguished road

      0  

    Default Unanswered: defining ColumnConfig in uibinder

    Unanswered: defining ColumnConfig in uibinder


    It seems to make a lot of sense to define the ColumnConfig (widths, column header labels, autofit, etc) in the uibinder, but I don't see a way to do this.

    There is a @UiConstructor for Grid

    HTML Code:
    @UiConstructor
      public Grid(ListStore<M> store, ColumnModel<M> cm, GridView<M> view)
    But I don't see how it could be used, since there doesn't seem to be a way to create a ColumnModel in the uibinder. Is that @UiConstructor there just to taunt me , or am I missing something?

  2. #2
    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


    Just to taunt you!

    No, this is part of how UiBinder behaves - declarative widgets. Declarative, because you just set values, no logic (i.e. if, loops, etc), and widgets, because each tag with a capital letter refers to a widget type. Lower-case tags refer to methods in the parent tag's type. The only methods you can call from a uibinder file are setters and methods annotated with @UiChild. This makes it tricky to compose a List<ColumnConfig<M, ?>> in xml.

    So if we added @UiConstructor to ColumnModel, you could define the list of columns in Java and pass them in, but that seems silly. Instead, we've gone for the approach of building the entire column model in java and referencing it from the Grid's constructor in ui.xml.

    http://www.sencha.com/examples/#Exam...icuibindergrid

    Sorry for the confusion/frustration - UiBinder is intended to be good at what it is designed for, and hard to accidentally misuse in terrible ways. This is one of the costs of those decisions.

  3. #3
    Sencha User
    Join Date
    Sep 2012
    Posts
    31
    Answers
    2
    Vote Rating
    1
    billsalvucci is on a distinguished road

      0  

    Default


    Thanks for the clarification.

    Why not give ColumnModel a default constructor and an @UiChild addColumnConfig? I don't see any reason why the ColumnConfig constructors can't be given @UiConstructor. I think that is all that we would need.

  4. #4
    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


    Its a valid point, but then ColumnModel would need to support changing sets of columns (currently not allowed to keep render costs down, instead, you swap out the entire ColumnModel for a new one). Then, which ColumnConfig constructor do we pick to make it @UiConstructor? We can only pick one - probably the one-arg one, but I haven't fully looked this over. Next you'll need to provide references to your ValueProviders (that is the only thing that ColumnConfig must have in its ctor), which usually means passing in a PropertyAccess type via ui:with.

    Lastly, how would we actually create that ColumnModel so that it could be passed into the Grid's constructor? This is the only really insurmountable issue I see - it must already be created to refer to it as columnModel="{cm}" as an attribute in the Grid tag. It can't be a child tag, as constructor arguemnts can't be passed in via @UiChild.

    We could conceivably open up two new setters with @UiChild, setListStore and setColumnModel, and allow the grid to have neither when it is first created, but these would have the sole purpose of making it easier to build the grid via UiBinder - we wouldn't want them to be used in normal Java code, instead reconfigure should be used, with the added implication that this isn't a normal setter, but is much more expensive. This is the way of a lot of UiBinder - it isn't expensive on its own, but it makes it easy to write very costly code. I don't know if UiBinder allows the same property to be set by an attribute and by a @UiChild setter, so we could be breaking backward compatibility.

    We don't take this lightly, but it is a hard problem to solve with UiBinder designed as it is - written to make it possible to build widget and html structures declaratively, but no more. No logic, no loops, minimal string replacement, and only to be run once. It fits a niche well, but it cannot be used outside of that niche, at least as designed. General purpose element parsers and attribute parsers could open the door wider to what you are describing, but are harder to maintain, and very easy to abuse, so the GWT team so far as cut that option off. I'm of two minds about that approach - the risks they are concerned about are real, but it does make cases like this harder to deal with.

Thread Participants: 1

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