Community
Participate
Working Groups
Created attachment 209783 [details] screen capture When creating a new Dynamic Web Project, I pressed the New Runtime button and typed "j2ee" into the filter text field. All of the contents of the tree expanded, but nothing was hidden as I expected.
Created attachment 217054 [details] Patch v1.0 The filtering for runtimes and servers is quite confusing. I believe filtering on the name (that appears in the tree) and the the folders that organizes these tree items makes the most sense. Prior to the fix, it will filter based on the supported module type, supported module version, and the description of the server or runtime. As a result, putting in values like "2.2" and "J2EE" will seemingly not filter anything, as many servers support modules of that version and module type. Filtering based on what is seen in the tree is much more intuitive sense than looking at the "hidden" things like descriptions or supported modules. The fix only checks for the name of the server or runtime when doing filtering. This name also includes the folder names too. Tests run: 1. Put "2.2" into the filter for the new server wizard, ensure that nothing shows up (since no servers have a name with "2.2") 2. Put "B" into the filter for the new server wizard, ensure that the "basic" folder shows up and the servers within it 3. Put "Tomcat" into the filter for the new server wizard, ensure that only the "Tomcat" servers are shown 4. Put "J2EE" into the filter for the new server wizard, ensure that only the "J2EE Preview Server" is shown 5. Repeated steps 1-4 with the new runtime wizard to verify the same thing
Accidentally marked this as closed. Reopening.
Changing the version number to 3.4 based on the whiteboard comment.
The filter is supposed to do a deeper search than just the server and runtime name. It is supposed to search through the server/runtime type description, the supported modules, etc. The main reason is to allow the user to help users that doesn't have a particular brand of server in mind, e.g. I just want to run web or jee applications. Then, they can just put in the technology that they want to run. Instead of changing the more powerful searching mechanism to reduce the filter based on server/runtime name and type only, I would suggest to take a different approach to change the default text on the filter box to describe more on what can be searched instead of just having the "type filter text" as the default text. Then, we can inform the user on can be put on the filter. For users that have a particular vendor of server in mind, they will probably put in the vendor as their search, e.g. tomcat, for tomcat servers.
(In reply to comment #4) > The filter is supposed to do a deeper search than just the server and > runtime name. It is supposed to search through the server/runtime type > description, the supported modules, etc. The main reason is to allow the > user to help users that doesn't have a particular brand of server in mind, > e.g. I just want to run web or jee applications. Then, they can just put in > the technology that they want to run. I'm not certain users think in that order (technology vs. server name), but it appears a little inconsistent with how filtering works elsewhere (other than P2), where it's based strictly on name and explicitly declared keywords.
A deep search shows in eclipse itself, e.g. on preferences page, you can type timeout and it filters all page that contains timeout (not just category titles that contains those). That'll be similar to the description of the server/runtime type search to me. I agree with the existing default description, the user will expect the same type of filter based on name only and it does causes confusion to user. Therefore, I am suggesting to change the default text on the filter field so the user know the search can go beyond the label search. Do you think changing the default text to clarify the scope of the search addresses the issue? I am open to change if you strongly belief the search should be narrower, e.g. I am will to take off relatively implicit search for searching through the supported module types but I think at least the description search should remain. The way that I foresee is users who knows the exact server type name, they will probably type text go by the brand of the server first anyway and won't notice the difference. It is for those users who don't know too much and fishing for something that can support, say EJB, will get benefit from the deep search.
(In reply to comment #6) > Do you think > changing the default text to clarify the scope of the search addresses the > issue? I am open to change if you strongly belief the search should be > narrower, e.g. I am will to take off relatively implicit search for > searching through the supported module types but I think at least the > description search should remain. > > The way that I foresee is users who knows the exact server type name, they > will probably type text go by the brand of the server first anyway and won't > notice the difference. It is for those users who don't know too much and > fishing for something that can support, say EJB, will get benefit from the > deep search. I'm not advocating it being narrower, but I had typed in "j2ee" in hopes of finding the "J2EE Preview Server" more easily. It's a corner case where the existing filtering mechanisms didn't help. Off topic, but Tomcat's not a J2EE server. Why does it match?
The reason that tomcat matches is because the tomcat server description, e.g. tomcat 7, is "Publishes and runs J2EE and Java EE Web projects and server configurations to a local Tomcat server."
Nitin, for your comment 7, can you clarify if you are ok with the approach of modifying the default filter text description or are you still looking for changes in the existing logic? I just want to make sure I didn't interpret it incorrectly.
Ideally there would be some way to give more prominance to filtered results where the match is on the name itself over those that match against the description. Yes, changing the description of the filter field would be at least a short-term improvement.
Created attachment 267917 [details] screencast of PoC idea Here's a really hacked up implementation I have as an opportunity. I'm not sure if you'll all like it, but I figured it was worth a try. It uses a combo to select what filter-mode you want. It's just a PoC but I thought it'd be worthy of discussion.
(In reply to Rob Stryker from comment #11) > Created attachment 267917 [details] > screencast of PoC idea > > Here's a really hacked up implementation I have as an opportunity. I'm not > sure if you'll all like it, but I figured it was worth a try. > > It uses a combo to select what filter-mode you want. It's just a PoC but I > thought it'd be worthy of discussion. Perhaps something less intrusive like attachment 262011 [details] from bug 488504 (sans the endless loop the initial fix caused)? Given how supported versions only seem to increase, it could still use a way to make name matches more prominent so that they're not always below the fold.
