This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Still in the latest (and extremely cool) qbuild of NetBeans the form editor keeps putting default values into the components of a form, and we, the developers, keep wasting time removing these default values. For instance, if you create a text field, NB will name it jTextField1 and set the text "jTextField1" as the value of the text field. So instead of just dragging a JTextField onto the form, the developer has to 1. Drag the JTextField onto the form 2. Mark the JTextField 3. Remove the "jTextField1" default text The fact that NB sets default values on the components in this non-configurable way has several problems: Problem 1. Removing the default values is extremely time consuming - especially if you create large forms with tabs containing dozens of text fields. Problem 2. Adding a default value involves the risk of developers forgetting to remove the default value. In systems where the values are loaded from a database, developers may test their forms with test data sets which contain proper records that make the client GUI show proper values which override the default "jTextField1" value. But on a rainy day when the application has been deployed and an error occurs that causes a record in the database to contain an unexpected or illegal value, the client application might be unable to parse the value thus the overwriting of the "jTextField" might fail. Then the users suddenly get to see this "jTextField1" default value. - Or even worse: They don't see it, because it is on a different tab, than the one they are editing, and they save the record, and we got a "jTextField1" string stored in the database. Problem 3. It teaches new users the bad practice of hardcoding data into the UI. People will think "Oh, NB sets the value of the text field by simply typing it in the property sheet - that is easy - I'll do that too". As we all know data should be kept seperately from the UI, e.g. in a database or, perhaps, an internationalized set of property files. This issue does not apply only to JTextField components but to *all* components for which NB adds default values. Another example is JTable into which NB sets a default model which not a single application on this entire planet uses. It is the same for JComboBox. I assume that the decision to create default values comes out of a sound desire to create a self-explanatory IDE. One might claim that adding the string "jTextField1" to the JTextFields make them look more like real text fields. If you really want to do something like this, why not just use a tool tip saying "This is a JTextField" above the component instead? Or, at the very least, make the addition of default values configurable, so majority of the developers who develop applications that do not hard code default values into the UI can turn it off. In hopes to make a great IDE even better Randahl
Thanks for spending time summarizing the issue of the initial (pre-set) property values. I can agree with you in point 1, point 2 is rather minor I'd say, point 3 seems to be a bit extreme - I don't think form editor inspires hard-coding (everybody notice this once need non-static data; for prototyping it is ok). Also not all components with pre-set property values make a problem. Right now it seems to me there are just 4 component types that are problematic: JTextField, JList, JComboBox, JTable. OTOH an initial value is IMO desirable e.g. for buttons. And quite necessary for labels. So we can't just turn this off. It is interesting that some pre-set values come from the components directly - e.g. JTree or JSplitPane. I would not underrate the importance of visually distinguishable components. Tooltips are not enough. Seeing immediately that a component is a JList and not JTextArea or JTable is much better. But I agree with you that we should probably achieve this a different way than pre-setting property values (that propagate to generated code). Other reasons for the pre-set values are that they give the component reasonable preferred size; and also indicate the users (who wouldn't know) what property is responsible for the content of the component. These are also points to consider. So we will consider this for the future. I think we can eliminate the text in textfields easily. Not sure about the rest right now. I suggest to make this RFE.
Thank you for getting back to me. First, I completely agree that Problem 2 is a minor one; however, my example illustrates what is bad about mixing UI design with model data. It is the *principle* of your design that seems problematic to me - ideally an IDE should be a good example of the right way to do things. Second, you mention prototype development as an argument for allowing field values to be set in the form editor, and I agree these kinds of projects need such features. Still, though prototyping is popular, I do not think that the majority of the projects being developed with NetBeans involve developing a prototype in which you hard-code values into GUI components like JTextField. This is why I think the hard-coding is a questionable default behavior. So all in all (and in a completely abstract sence) what I would like, ideally, is for NetBeans to show GUI components in a so called "design mode" in the form editor. - A mode in which the IDE is allowed to add data for illustrative purposes and spice up the components in any way imagineable. Still, this mode is to be *completely* seperated from the "runtime mode" my components are in once the application is run - in this mode every component should be completely free of the illustrative data. I am happy to hear you will look into this - if you do not plan to rewrite much of the form editor code for 4.2, it would be really great if, as mentioned, you could save everyone a lot of time by at least modifying the code which keep adding the "jTextField1" text to each and every text field we create. Randahl
JCheckBox seems very similar to JTextField in the sence that it too creates a default string, which developers then need to remove - and maybe it is similarly easy to fix. R.