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.

Bug 60863

Summary:	Form editor inspires hard-coding
Product:	guibuilder	Reporter:	randahl <randahl>
Component:	Code	Assignee:	issues@guibuilder <issues>
Status:	NEW ---
Severity:	blocker
Priority:	P2
Version:	5.x
Hardware:	All
OS:	All
Issue Type:	ENHANCEMENT	Exception Reporter:

Description randahl 2005-07-12 10:19:51 UTC

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

Comment 1 Tomas Pavek 2005-07-12 14:42:16 UTC

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.

Comment 2 randahl 2005-07-12 15:46:52 UTC

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

Comment 3 randahl 2005-07-13 08:52:55 UTC

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.