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.
To reproduce: 1. Create a web module with a JSP at the document root (say hello.jsp). 2. Switch to the project view of the module. 3. Select the document base. 4. Select New -> JSP. 5. Enter the same name for the JSP as the one that already exists ("hello". 6. Nothing 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 should be. 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 OpenIDE/core.
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 arises.
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 issue 23116.
:) 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? Thanks, Ana
> 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. 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 Solaris.
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] possible patch
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 missing something? 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 documentation. 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 dislayed? 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 situation. 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 shown. 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 dynamic changes..
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] binary patch
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 look 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 louise.avila@sun.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: <http://openide.netbeans.org/servlets/BrowseList?listName=dev&by=thread&from=17093>
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 contextual menu. 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 accessbility problems. 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 the INF.
Implemented. 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