View Poll Results: Do you like the use of public properties for pre-render configuration options?

Voters
41. You may not vote on this poll
  • Yes

    12 29.27%
  • No

    4 9.76%
  • No, and I prefer changing the API

    25 60.98%
  1. #1
    Sencha - GXT Dev Team darrellmeyer's Avatar
    Join Date
    May 2007
    Location
    Washington, DC
    Posts
    2,242
    Vote Rating
    2
    darrellmeyer is on a distinguished road

      0  

    Default Ext GWT public properties and JavaBeans

    Ext GWT public properties and JavaBeans


    The decision to use public properties in Ext GWT was a decision that was made after much deliberation and discussion with the community. Currently, public properties are only used for pre-render options that are used before a component is rendered. Methods can be called at any time.

    Here are the issues:
    1. Ext GWT needs a way to allow components to be "configured" before rendering.
    2. Many components have a large number of config options.
    2. Any solution should be typed. No config.set("frame", true);
    3. It should be easy to identify pre-render options.

    Possible solutions
    1. Have a config object for each components that is passed in the component constructor:
    Code:
    ContentPanelConfig cfg = new ContentPanelConfig();
     cfg.setFrame(true);
     cfg.setCollapsible(true);
    panel = new ContentPanel(cfg)
    2. Use a config object that is accessed via the component:
    Code:
     panel = new ContentPanel();
    panel.getConfig().setFrame(true);
    3. Support both 1 & 2.

    4. Using a naming syntax with config options:
    Code:
    panel.setConfigFrame(true);
    panel.setCFrame(true);
    panel.setCCollapsible(true);
    5. Use public properties:
    Code:
    panel.frame = true;
    panel.collapsible = true;
    I know Java developers are not used to using public properties and getters /setters and the standard way for an API. But keep in mind, Ext GWT is not a standard java application and has unique needs.

    All that being said, we are open for feedback and suggestions. If you have an opinion, please let me know what you are thinking. If I had to pick an option that did not use properties I would probably prefer method 4 as it seems the most natural.

  2. #2
    Ext User
    Join Date
    Aug 2007
    Location
    Slovenia
    Posts
    8
    Vote Rating
    0
    avrecko is on a distinguished road

      0  

    Default


    Thanks for the clarification but I don't get it.

    ContentPanelConfig cfg = new ContentPanelConfig();
    cfg.setFrame(true);
    cfg.setCollapsible(true);
    panel = new ContentPanel(cfg)
    Shouldn't in this case ContentPanelConfig actually be in-lined in the ContentPanel? When you extend the ContentPanel you are inheriting all of the config options anyway.

    Why is there a need for ContentPanelConfig in the first place? What is wrong with plain panel.setFrame(true), panel.setCollapsable(true);?

    If by some reason public fields are needed, please just supply the getters and setters it will not spoil the Java Bean feeling but you will still get public fields.

  3. #3
    Ext User ushkinaz's Avatar
    Join Date
    Apr 2008
    Posts
    25
    Vote Rating
    0
    ushkinaz is on a distinguished road

      0  

    Default


    I'd vote for private fields and public accessors.
    Reasons:
    1. Java developers are used to search for setters in widgets.
    2. Public properties means that a developer should forget about his past experience and develop new style of coding. Not good at all, since it intoduces hidden cost into our projects.
    3. Public properties: this approach means that all my code should implement same approach. Which is bad, IMO. All my automated codesmell checkers will yell at me. I'll be spammed with false alarms, which means I'll ignore them, which means I'll have high chance of missing important ones.
    4. Related to 3) All my code reviewers are have to learn that public properties are ok. Introduces hidden cost.
    5. Consider this scenario: MyWidget is inherited from Widget. I need to have a property, which value is calculated from Widget.width property. With setter it's easy - just override setWidth() and do your (possibly heavy) calculations there. With public fields - well, more complex and obscure approach should be implemented.
    6. Regarding your remark to "Ext GWT is not a standard java application". I don't think that Ext GWT is THAT different. It could be compared to SWING, Tapestry, Wicket and many more. AFAIK, none of these great libraries are using public fields. And lifecycle of widgets in these libs are simular to lifecycle in Ext GWT.
    7. Tools support. Approach 1), 2) and 3) will introduce some difficulties to tools providers, since configuration objects should be correctly recognized and editors provided. 4) is standard, there will be little need for tailoring. 5) is in question.
    8. setters/getters might be declared in interfaces. public field can not. See GWT's interfaces like HasAlignment for use cases.
    9. 1) could be nice. Nicest thing about it - I could easily share/clone configuration objects between widgets. Cool.

    As an addition, refactoring existing code in Ext GWT is reeeeealy easy. Just 1 click on every class in my IDE of choice

  4. #4
    Ext User ChadBourque's Avatar
    Join Date
    Apr 2008
    Location
    Dallas, Texas, USA
    Posts
    8
    Vote Rating
    0
    ChadBourque is on a distinguished road

      0  

    Default


    Darrell,

    Personally, I like option 3. Have separate configuration objects that are accessible from the widgets themselves. That has the benefit of completely separating the pre-render configuration away from the widget itself while still making easily accessible from the widget. It also allows for the creation of a single configuration object that can used for multiple widgets that you want to all have the same configuration.

    Anyway, that's how I see it. Take it for what it's worth.
    There are two types of people in the world:
    • Those who need closure

  5. #5
    Ext User ushkinaz's Avatar
    Join Date
    Apr 2008
    Posts
    25
    Vote Rating
    0
    ushkinaz is on a distinguished road

      0  

    Default


    One thing I forgot. With public fields you can't add validations.

  6. #6
    Ext User
    Join Date
    Apr 2008
    Location
    Montreal, QC, CA
    Posts
    2
    Vote Rating
    0
    damsca is on a distinguished road

      0  

    Default


    Hi Darrell,

    I'm happy with any of proposed syntaxes. My main concern is upward compatibility, The code shouldn't have to be changed because a property becomes dynamic.
    Go Habs Go

  7. #7
    Ext User
    Join Date
    Apr 2008
    Posts
    9
    Vote Rating
    0
    jayj is on a distinguished road

      0  

    Default


    +1 for option 4 for the same reasons that others have pointed out above. I'd also be happy with a standard setter that throws if it does not support being used after rendering as long as the javadoc states this clearly.

  8. #8
    Ext User Cameron Braid's Avatar
    Join Date
    Mar 2008
    Posts
    6
    Vote Rating
    0
    Cameron Braid is on a distinguished road

      0  

    Default


    I don't mind using public fields, however this breaks encapsulation and makes it more difficult to evolve the API.

    I don't like the idea of a setter prefix.

    I vote for using protected (or private) fields with public mutators.

    This is how I think the code should look.

    Code:
    /**
    * <p>NOTE : pre render property</p>
    * describe the property here
    */
    public void setFrame(boolean frame) {
       assertNotRendered();
       this.frame = frame.
    }
    private boolean frame;
    
    add into Component
    protected void assertNotRendered() {
      assert !isRendered() : "property can only be set before the component is rendered";
    }

  9. #9
    Ext User ushkinaz's Avatar
    Join Date
    Apr 2008
    Posts
    25
    Vote Rating
    0
    ushkinaz is on a distinguished road

      0  

    Default


    I'd vote for what Cameron said.

  10. #10
    Ext User sheesh-kebab's Avatar
    Join Date
    Jan 2008
    Location
    Washington, DC/Falls Church, VA
    Posts
    40
    Vote Rating
    0
    sheesh-kebab is on a distinguished road

      0  

    Default


    If public properties are so annoying to folks (as a java developer I see why, although as a groovy/python developer I really like them), I'd prefer either:

    a) simple getters/setters, a la Swing (although I'm not too keen about that assertion code that Cameron is suggesting - too verbose)

    b) config object (option 1, I think)

    I don't know how intuitive option 4 would be - looks a kind of weird, but I haven't really tried it.