1. Create a web module with a JSP at the document root
2. Switch to the project view of the module.
Select the document base.
4. Select New -> JSP.
5. Enter the same
name for the JSP as the one that already exists ("hello".
happens. No dialog warning that the name is already used, the finish
button is not enabled.
Well, if you are saying that certain behavior is wrong,
you should also say what you think the correct behavior
Also, have you tried this for .txt file ? The behavior is
the same there, so the behavior for JSPs is consistent
with other templates.
Please specify the desired behavior and file a bug against
Don't be such a curmudgeon! OK, here is what should happen: if a user hits
enter in the text field, there should be an error message to the effect that
there already is a file of that name. Also, instead of graying out the
finish button (which means that the user has no idea what's going on), it's
better to leave it enabled and show the warning then.
To those of you on
the openide team, this might seem like a weird thing for a user to do, and
that is true in the Java space - it's fairly unlikely that users will want
several Java classes of the same name in different subpackages. But in the
web apps area, it's fairly common to have files of the same name in
different directories. For example, I might have an index.jsp in several
subdirectories of the web module. If I track badly, I select the wrong node
before I start the new wizard, and this is where this confusing situation
If I understand well there is a proposal how to handle these cases in
the same way through the IDE. Should we join the discussion about it?
Ok, Ana, sorry for being mean. That won't happen again :-)
This is a reasonable request, but I still think it should
be handled consistently through the IDE.
Unfortunately, what you are requesting is not possible in
the current wizards framework. However, there is a
proposal for enhancements which would address this. See
I reassigned the bug to openide/ui (now to wizards, my browser
didn't give me that category last time) because the file dupe is a generic
problem and not a web apps one. Should I reassign it back to webapps? I note
that 23116 provides the ability to give a warning/not go ahead after a
button has been pressed, but doesn't include specific behaviour for
duplicate file. Is the duplicate file behaviour part of the webapps code,
or is it part of the wizard code in general?
> I note that 23116 provides the ability to give a
> warning/not go ahead after a button has been pressed,
> but doesn't include specific behaviour for duplicate
This behavior is not intended to be a part of the "wizard
framework" as such, but of the "new from template wizard",
which is a particular wizard building on top of the common
framework. So the framework will provide the ability to
validate on pressing Next/Finish, and the New form
template wizard will plug in the validation of duplicate
name (when the Next/Finish button is pressed).
So yes, I believe this should be a part of the generic
functionality, similarly to the current enabling/disabling
the Finish button when duplicate name is entered.
I am increasing the priority on this issue because it is going to
significantly affect some of S1S EE (Rainier). The "inline_errors"
solution mentioned in the url associated with this issue would be the
preferable fix and must be done eventually, but even a "hack" of
showing an alert explaining that the file name is not unique would be
good enough in the short term.
The issue could be tracked as enhancement, it asks a new functionality
by Jan's "inline_errors" proposal. It depends on issue 23166, will be
resolved in 4.0 timeframe.
I'm changing this back to a defect. If the inline errors solution
isn't available, then an alert box is an acceptable alternative (as
suggested in the last message). This really is needed for S1S for
I'm going to help Jirka with this issue.
It is clearly too late for implementation of inline_errors proposal
for NB3.5. The change would have impact on modules, their UI,
documentation, etc. so it is not realistic. AFAIK we are already in UI
freeze for 3.5.
So I propose to try to implement a hack which:
* left finish/next button enabled
* would show error message box in case there is an error and user
pressed finish/next button
I already have working patch, but I would like to discuss it on
openide@dev whether there is any better way or whether it is
apropriate. It is quite ugly solution.
Created attachment 8938 [details]
Hmm, I just realized that it might be easier to implement (at least
partially and only for wizards) the inline_errors proposal. The error
message could be set instead of API through the properties as it is
done in my current patch. Not nice, but let say more acceptable than
hack I'm proposing now. The rest of the code from the patch would not
be needed - the buttons would be disabled as now and property text
would be shown in the wizard panel. WizardDescriptor would listen on
property changes and update the error text accordingly.
The potential problems I see:
* is everything related to inline_errors proposal clear from the
UI/HIE point of view?
* it is UI change and we are in UI freeze? Can it be still done?
* this change would eaten some space from each wizard dialog, but
almost none module will have time to take advantage of it and show
there some errors. The target chooser panel would of course use it to
solve problem reported in this issue.
* it has impact on the Documentation (Patrick see inline_errors
proposal in the URL field). Is that OK?
I will try to implement prototype tomorrow whether what I'm proposing
is feasible, but I would like to hear answers from UI team and Docs
team to my questions in the meantime. Thanx.
> it is UI change and we are in UI freeze? Can it be still done?
Patrick would know the definitive answer. My opinion is that this UI
change will have significant impact on Doc (there are screenshots in
many places, not only in users guide but also in various turorials)
and should not be done that late. BTW this bug is there for long
time, it's much older than the report date. This should be taken into
consideration whether or not we postpone the fix to the next release.
Actually, this looks OK to me. I can't imagine that screenshots would
focus on the scenario of a user entering a duplicate file name. Am I
Bob, could you look at this as well? The link in the URL field gives
an explanation of the change.
I don't see this, as Patrick implied, having an impact on existing
There are no existing screenshots that focus on the scenario of a user
entering a duplicate file name, which appears to be a focus of the
document in the URL.
but does it change the look of the wizards even if no error message is
From a different perspective, we are late in the cycle, I would be
very careful with API changes. Only if the change is _trivial_
we've added something similar to the UI spec for inline messages (yes,
I've been inspired by that and I really hated my colleague's
JOptionPane.showMessage() calls within the wizard)
It might be useful, attaching pictures on how it looks and the actual
code (haven't stripped it off our app related stuff, but both files
are quite small and it should not be problem to find the right stuff.)
We use JLabel as the inline message showing component, since it allows
HTML formatting (looks nice however has the drawback that depending on
the text size it influences the size and layout of the wizard panel.
for now we can live with that)
the algorithm for showing/clearing messages is not bulletproof but
works so far in our scenarios.
Created attachment 8947 [details]
example of error message
Created attachment 8948 [details]
example of a HTML formatted message in the wizard.
Created attachment 8949 [details]
sample code of the inlined error notification.
Milos, thanx for your help! That's very similar to what I have in my
mind. The only difference is that I would like to implement it wouth
any new API and was thinking about using properties for communication:
if a string property is set the panel will display the string. if a
string property is reset the panel will clear the error. Not that nice
as your API, but as a "bufgix" I believe it is acceptable. Especially
in the fact that this solution should be more trivial than my current
message box patch. The string could contain HTML to change colors etc.
I'm going to write patch which would implement this idea. If
successful I will attach it to this issue so you can all try it.
Trung, I would like to evaluate this possibility. At the moment it
looks that it could be very trivial. Definitely more trivial than
message box patch.
Patrick, thanx for the info.
there's one problem we've come across and it might be relevant to your
Imagine you have 2 fields only.
in the first one user enters a wrong value, doesn't correct it and
moves to the second field.
in the second field, enters a wrong value as well, we show another
error, which overlaps the old one.
user corrects the wrong entry in 2nd field, we clear the error message.
--> but the first field is still not correct, but the message is not
The code I've send you doesn't handle that, since we've decided that
we'll cache a last-entered correct value and will replace any error
value when the component looses focus.
however the PanelErrorNotifier Apis should be able to handle it.
re: without APIs, there's already a lot of client properties
everywhere, wich were added as a way to add stuff without adding APIs,
but in reality over time they became apis anyway. most of them are
declarative stuff though, which you set once, here we are talking
Created attachment 8950 [details]
Eliminates the dynamic nature of David's patch
I do not like the changing of closingOptions in David's proposal
because being too "dynamic". The best objects are immutable ones,
anyway. Thus I've attached a version that removes the need to change
closingOptions, it is just enough to fire properly annotated
(ErrorManager.USER, good localized message) IllegalStateException from
the attached buttonListener. If you choose to implement David's
proposal please prefer the exception to changing closingOptions.
Milos, that should not be problem in our wizards I think. Each panel
has isValid method and this method should validate all fields in some
order and set error messages. In your example the error in first field
will be reported till it is fixed. Then the isValid should continue
with validating second field.
As for the API: I agree. Adding property _means_ adding API. The whole
wizards are based on properties so adding another one seems to me at
least let say consistent. Adding property is also less burden than
adding new API interface. It is also possible that this property could
be private for openide and documented to be not used by the clients
for NB3.5 as this is still bugfix. But I think there is no need for
such a restriction. Once there is better API, the usage of the
property can be replaced by APIs.
Yarda, thanx for the patch. I agree.
Created attachment 8951 [details]
screenshot of patch in action
Created attachment 8952 [details]
source code patch
Created attachment 8953 [details]
I implemented first version. The screenshot, source code patch and
binary patch are attached. Put the binary patch into your
netbeans\lib\patches folder to try it. Currently only Target Chooser
panel uses this feature. All other panels have empty space at the
bottom. At the moment the plain text is used and by default line is
always red. If I used HTML the different font was used and sizing gets
complicated as Milos mentioned. But this could be hopefully solved
with the help of UI or in worst case we can stay with plain_red_text.
Please comment. If you look at the source code patch it is pretty
simple. Anybody can use this feature by settings one property
"WizardPanel_errorMessage". I propose to implement it this way.
The only issue I have is if the implementation of this changes the
look of a Wizard, irrespective of whether an error message is in place
in the Wizard at a particular point in time. If all Wizard Panels will
different once this is implemented (irrespective of errors, i.e. even
when no errors are written), then I have a major issue with doing this
change for 3.4.x, as it will affect Nevada docs. If the change is
targeted for 3.5, and the Wizard Panels will change irrespective of
whether an error is present, then the change is more acceptable.
BTW, I believe Jan Benway wrote the spec so that the Wizard Panel real
estate is not greatly modified when no message is present.
Right. The intention in the spec is that the wizard real estate is
only affected if the wizard in question uses the in-line error API.
Simply making the API available should not affect any wizard screenshots.
Any wizard that takes advantage of the API will change in size.
*** Issue 31132 has been marked as a duplicate of this issue. ***
Comment from email@example.com:
"I do a lot of error checking and displaying in my module was planning
to implement my own inline error display in the next version of my
module in both my wizards and property editing dialogs so I was
interested to read about this implementation. My concern is that this
new property would only apply to WizardDescriptors and not
DialogDescriptors so I would have to do my own implementation for my
dialogs which might look inconsistent with error handling in the wizard."
Bob, the change is planned for NB 3.5 (means I will commit it into
NetBeans main trunk). Current implementation affect size of all wizard
pages without regard the error message is displayed or not. When no
error message is displayed there is always *empty* space at the bottom
at the right half of the wizard dialog which is reserved for error
message. If this is a problem there could be a way to say whether the
wizard panel uses inline errors or not and then only the panels using
this feature would be affected in its size.
HIE/UI people: do you support implementation I proposed? It is not
100% according to Jan's UI spec. The text is always red. It is also
supported only for wizards what can cause inconsistence in dialogs as
described in louise.avila comment. Let me know your opinion, suggestions.
For the record discussion from openide@dev about implementation issues:
Bob, David came by my desk and confirmed my understanding of the
change. In his implementation, the some of the panels would have
slightly more grey space at the bottom to make room for the error
message. But there is nothing that would make the panels *noticeably*
different -- no visible widgets, no new borders, so I don't think
this is a problem for screenshots.
Another clarification, "3.4.x" now equals 3.5.
I have a few comments about the patch. Some of them are just a bugs,
some are UI issues.
1. Warning label is not shown when you invoke the wizard from the
2. If the label is shown and you press "Previous" button the label is
shown in the previous panel too.
3. Current wording of the error label may be a problem as you are
referring to "already existing file", but the user is creating Java
Class, JPanel Form, etc. OTOH, existing file is the actual error, so
if we can't find better wording I am fine with the current state.
4. Anyway, comma should be at the end of the sentence.
Otherwise I think it looks good and solves the problem.
I would like Jan Benway to check the patch too, as she has written the
error handling proposal.
It looks pretty good to me. I see all the issues that Jano mentions,
above, although it seems that #2, that the message appears also on the
previous panel, is the most serious.
Ideally, I'd like to get away from the all-red text, but I see that
there are some difficulties in using HTML.
The problem is that all red may be unreadable by color-blind users, so
hard coding the text to red will not pass accessibility requirements.
Accessibility is part of the reason why the spec shows most of the
text in black, and only the leading words (Error or Missing Data) in
red. The other reason is that all red is kind of rude, especially in
the "Missing Data" case, where the error may appear when the user
first comes to the wizard page and hasn't even had a chance to fill
anything in yet.
I talked to Bruce Lee (visual design) about this, and if all of the
text must be a single color, we agree that having it be all blue would
be better than all red. All blue is more readable than the red used in
the patch (for all users) and blue is much less likely to cause
Bruce suggests using R=89, G=79, B=191
Lastly, I would love to see this implemented for dialog boxes as well,
but I don't see a problem in doing it for wizards first and dialog
boxes a little later on.
Louise and others could still do a custom implementation for dialog
boxes for the time being.
Thank you for your comments. I will change the color to Bruce's RGB
and fix all found problems. I will integrate the issue ASAP and close
Checking in openide/openide-spec-vers.properties;
new revision: 1.104; previous revision: 1.103
Checking in openide/api/doc/changes/apichanges.xml;
new revision: 1.139; previous revision: 1.138
Checking in openide/src/org/openide/WizardDescriptor.java;
new revision: 1.79; previous revision: 1.78
Checking in ui/www/docs/ui_apis/wide/index.html;
new revision: 1.3; previous revision: 1.2
Checking in openide/src/org/openide/loaders/Bundle.properties;
new revision: 1.95; previous revision: 1.94
Checking in openide/src/org/openide/loaders/NewObjectWizardPanel.java;
new revision: 1.3; previous revision: 1.2
Checking in openide/src/org/openide/loaders/TemplateWizard2.java;
new revision: 1.52; previous revision: 1.51
Checking in openide/src/org/openide/loaders/TemplateWizardPanel2.java;
new revision: 1.3; previous revision: 1.2
verified in nb35 FCS