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.
Add capability for users to perform search while focus is on BPEL Design view. Details to follow.
Just adding a test URL ... you may replace it later on with whatever you want.
Adding "gavotte" status whiteboard keyword (for testing of gavotte features query).
changing title to Find instead of Search. Some issues related to this feature. Big questions: How consistent/inconsistent can this feature be relative to the Find feature in XSD and WSDL editors. The question of the day is how much "choice" can be/should be crammed into the Find "window" that we currently show at the bottom of the design vew. Here are some findings of current state for Find in WSDL/XSD, Find in Source view, and Find in Firefox. These represent a bunch of different information axes. Current XSD/WSDL find --------------------------------------------------------------------------------------------------- [v] Find Type drop down (actually, not sure what this "field" is called, unlabeled. - Component Name - Component Kind - Attribute Declaration - Attribute Value ------------------ - Search from Selected - Use Regular Expression (Comment - is this the right nomenclature to use even in BPEL Design View? Pro - consistency in NB. Con - very XML centric ) [Find Next] [Find Previous] [Clear] - comment do we need clear? If absent it give more room for other options Text Search dialog XSD/WSDL Find ----------------------------------------------------------------------------------------------------- [x] Match Case absent [x] Whole Words absent [x] Regular Expressions present in Find "type" drop down list [x] Incremental Search absent [x] Highlight Results implicitly Yes [x] Search Selection absent - but there is a "Search from Selected" in drop down list [x] Wrap Around absent - meaningless perhaps [x] Search Backward presnt in form of Find Next button. Compare to Firefox Find [Find Next] [Find Previous] [x] Highlight All impclitly yes [x] Match Case absent Also, of note - the F3 Find Next) shortcut does not seem to be present. I would expet this as user, yes? Vladimir proposed [x] Result Tree (similar to Usages Tree) [x] Pattern ? * (simpler than RegEx)
As this got quite long, here is the summary: * No extra window for searches in local context (within a file); just do what's there in XSD/WSDL. * Enable also Navigator for the search in BPEL (as there's the structure, etc ...) * Merge Component Kind, Attribute Value and Attribute Declaration to "Schema Construct", fix it and do the same for BPEL ("BPEL Construct") The discussion / analysis follows ... for reference, you may see the summary of the current search offering in the URL of this issue. ---------------------------------------------------------------------------- * No extra window for searches in local context (within a file) It seems there are two different use cases - based on the scope of the search. This seems to be quite natural as a file defines a scope of work - by nature of the file types - or just for categorization (division of multifile schema into multiple files or an application to multiple Java files). UC1: User wants to find an entity within the current scope of work UC2: User wants to find an entity within a broad scope (folder, project or multiple projects - a.k.a. composite project). UC1 is nicely fulfilled with "Find in Text File" or "Find in Logical View of XML File". User types in the searched string, search occurrences are highlighted (in text, editor's tree and/or navigator), user may cycle through these with F3 / Ctrl + F3 (I filled #88833 for this) and as the search result set is not that huge, this is quite sufficient. And efficient: a couple of key strokes and you're there. No extra windows, nothing. UC2 is fulfilled with "Find Usages" (nicely) or "Find in Projects" There is an issue with Find Usages that you first need to find the thing of usages you are looking for, but that's out of our current scope ... As the result sets of these searches may be huge, you need a facility to navigate through the search results space. And that's what the "Usages Window" or "Search Results Window" is for. The feature that we are talking about now is a "local search". Perhaps the common scenario for UC1 is enough. This means - highlight search occurrences, let the user cycle through them and done. Actually the tree structure is there in Navigator, so as the user cycles, the tree expands and nodes get focused as required. We may even highlight the nodes in the same way as in XSD/WSDL editors - and it would make sense if one could also bring up the search from Navigator (with Find / Ctrl +F) ... and cycle with F3 and Ctrl + F3 as well (IZ #88843). ---------------------------------------------------------------------------- * Merge Component Kind, Attribute Value and Attribute Declaration to "Schema Construct", fix it and do the same for BPEL ("BPEL Construct") In the analysis of the use cases, I intentionally didn't touch what does it mean "to find an entity". And I think that you readers most probably didn't notice and simply assumed that I mean "find an entity with a particular string in its name". Well, let's take a look on this ... -- I THINK THIS IS AN EXEMPLAR CLASH OF USER CENTERED VS SYSTEM CENTERED ANALYSIS AND DESIGN ---------------------------------------------------------------------------- * Fix Find by Component Name - it does not work for Enumeration I cannot search for an enumeration with find by component name; I need to do this with find by "attribute value". ---------------------------------------------------------------------------- * "User model" vs "System model": Search for "Element Reference" does not work So I type in "element reference" and nothing happens. Anything like "ref" or "elementreference" does not work; the same for attribute references. The thing is that it searches on tag names; however references are not constructed with special tag names. So we have an inconsistent user model; we pretend that "element references" are components as any others (in properties window, contextual menus), but then - we pull a different concept - a tag name. That's wrong ... OTH, search on "restr" finds restriction, which is not a component (I cannot add it); it's actually just a property (mode) of the component. ---------------------------------------------------------------------------- * "User model" vs "System model": Find By Attribute Declaration and ... Attribute Value For example the "find by attribute declaration" can be used to find a usage of min/max occurs boundaries and the "find by attribute value" to find optional attributes. But these are just "language constructs" - same thing as all/choice/or element reference. ==> So really, let's merge (and tweak/fix) "Component Kind", "Attribute Declaration" and "Attribute Value" into "Schema Construct" The ease of use could be even enhanced if we implemented "Find Usages" contextual menu action on a palette item - but that's just a rough idea, which would need to be further evaluated ... ---------------------------------------------------------------------------- * Deal with remaining use cases Maybe, we want to let the users to find an element with particular xml ID. Maybe "find by component name" (should we rename it to just "find by name"?) could do that as well. Maybe #2 - we want to let the users to search in documentations/annotations; this is for sure a different use cases from the others (and it currently requires a deep thinker to go thought it ... with find in attribute value). Maybe #3 - we want to let the users to search for some other cases ... this can always be done in source (as you are a geek if you need that), no? ---------------------------------------------------------------------------- * Namespace usage What is its semantics? Could this also be merged into "component name" / or "schema/bpel construct"?
lots of subtle points to discuss. But one obvious one. You write: "- and it would make sense if one could also bring up the search from Navigator (with Find / Ctrl +F) ... and cycle with F3 and Ctrl + F3 as well (IZ #88843)." But what exactly does it mean to "bring up the search"? Is not the working assumption that the Search window is anchored at the bottom of the Design view? Are you suggesting anything different or just suggesting that that window be shown (if not shown already) and given focus?
Responding to Mike's input: - Regarding results in a tree: That doesn't make any sense to me. Highlighting elements in the diagram and text views is far more useful. Moving that information to another display is confusing, unnecessary, and a lot more work in my opinion. How big are these results likely to be anyway? Seems to me they would almost never be big enough to justify such a grandiose UI. (Find Usages is different, because it's working across files and across projects.) - Regarding additional search options, I think it's unproductive to cram so many options into the search. Finding something should be as simple as typing a few letters, seeing the results get highlighted in the editor(s), and possibly iterating through the results to find just what you want. If it takes more time to hone the search through options than it does to just see the results and pick what you want, then these additional options are worthless. I can't even remember the last time I used anything but the Firefox or Thunderbird simple search fields, and there's much more information to sift through in those apps than in our editors. - F3 should work as expected to iterate through results. - RegEx was not a feature I liked, but Prakash and Nathan really did. I agree that simple patterns are easier, but regular expressions can stand in for all those other search options. However, I don't think patterns are actually necessary. The * operator is the default already, and when's the last time you used the ? operator? - Match case is a reasonable idea, since components may be named according to a case-based convention.
In terms of a global search feature, I'm very much in favor of an API/SPI and a common search field in the upper corner of the IDE for all modules to use. The SPI would allow the TC with the current focus (maybe editors only?) to provide search types and additional options (there should be some built-in options for all searches). If a component doesn't provide the search SPI in its lookup, the search component would be disabled. The search would use a similar callback mechanism to what Nathan built to allow components to handle searches their own way. If Vladimir concurs, I would love to see a one-pager proposal and/or interface JavaDoc.
Jirka writes: Merge Component Kind, Attribute Value and Attribute Declaration to "Schema Construct", fix it and do the same for BPEL ("BPEL Construct") I am in favor of something like this because I did find these separate choices daunting and had to actually test drive them to see what was going to happen. - Component Kind - Attribute Declaration - Attribute Value Lets look at the way a BPEL programmer will think about his process and think what use cases he may want. SImple use case, I want to search and find all cases of "OnMessage" in my process, or all cases of "EventHandler", yes? These are not "values", these are just language constructs. I think you combined BPEL Construct" would work for this. A different use case is to search for the value for a given construct. Attribute values are easiest to consider here. For instance, I want to search for "CreateInstance=true". Then I want to turn around and search for CreateInstance=false". I don't want to search for just "true". That will be crazy. I am not sure that the proposed BPEL Construct solution, or the pre-existing XML categories help here. Before we go further what is your reaction to this use case? Then I want to turn around and search for all Receive eleemnts without CreateInstace attribute present at all :)))))))))))))))))).
I agree that "*" is the most important pattern support. I was not aware it is supported by default today. I concur that is probably sufficient. Ok, I also see that RegEx and Search from Selected are boolean "modifiers" (my term) that are combinable with the other choice. Hmm. This was not clear at first and I was wondering why they were in the list to begin with and not set off from the list as checkboxes. Or an alternative "modifier" list Is the modifier story part of the existing API support? Are these query "modifiers" (my term) are controllable by particular implementation? For instance, we have to discuss whether "Search from Selected" is meaningful in BPEL. Currently, we have no support for multiple select because there were too many complex issues involved with multiple selection, particularly re: move. So we felt it better to keep things simple and not supprort multiple selection unless there is compelling reason to do so. Of course, "Search from Selected" could still be meaningful in the context of a single Container being selected.
Something else that has not been discussed in this thread is the relationship, if any, b/t the Design view search results and source. From what I can see today, there is no relationship. Has Jirka suggested that there should be a relationship? This could get very complex very quickly.
(We need a way to track comments on this long thread.) Mike wrote: "Ok, I also see that RegEx and Search from Selected are boolean "modifiers" (my term) that are combinable with the other choice. Hmm. This was not clear at first and I was wondering why they were in the list to begin with and not set off from the list as checkboxes. Or an alternative "modifier" list." TAF1: Let's not quibble over the specifics--one is just as good as another, though the current approach has the convenience of being compact. I think it's that way because the search field was originally in the upper right corner on the toolbar. "Is the modifier story part of the existing API support? Are these query "modifiers" (my term) are controllable by particular implementation?" TAF2: In my proposal for a common search API, they could be, but they may be some set of these that should be common to all. RegEx and Search from Selected are probably NOT common. "For instance, we have to discuss whether "Search from Selected" is meaningful in BPEL. Currently, we have no support for multiple select because there were too many complex issues involved with multiple selection, particularly re: move. So we felt it better to keep things simple and not supprort multiple selection unless there is compelling reason to do so. Of course, "Search from Selected" could still be meaningful in the context of a single Container being selected." TAF3: Search from selected just means search within the scope of the currently selected element. Trivial case is a single selection; this is entirely valid for BPEL. (However, I do think you guys need to support multiple selection--this is just expected behavior in a diagram, especially for things like delete.)
Mike wrote: "Before we go further what is your reaction to this use case?" TAF4: I think this use case is artificial. How many receives could you have in one process that you would need to specifically search or filter them by their CreateInstance attribute? I don't buy that as a reasonable use case in the real world. For example, in Java, I never search for "methods that return boolean values == true"; instead, I learn the code I'm looking at so I can filter it intelligently on my own. I don't know why we should treat BPEL any differently (it seems to me that this long discussion about searching for esoteric things is purely theoretical). On the other hand, I might want to find all constructors in the file, but in the case of BPEL, these components are clearly displayed in a unique way in the diagram, so I don't think I really need to search for them--I can scan visually to do that because the information is evident. As for the critique of searching for "true" or "false", that's possible but not a realistic use of that feature. Instead, that feature becomes useful when searching for something like QNames that appear as attribute values.
I disagree that the use case of searching for a combination of attribute and attribute value is artificial. Why denigrate the example of CreateInstance=true per se? It happened to be based on a real world experience of mine. And it is meant as an example of a type of query. In my opinion it is a valid use case. If the search cannot satisfy it fine. That is a different story. The search does not have to satisfy every use case. I don't think the comparison to Java is accurate. Attribute and value combinations particularly enumerated values are much more fundamental to BPEL.
Ok, there are still several issues to discuss. Do we take the extra discussion to a wiki so that this thread does not get longer?
We can move into Wiki, if we need to ... here are is a couple of my answers to these questions: * Re: If you guys want to do "CreateInstance=true", I think we can also do that with "BPEL Construct" search type? And you can always fulfil this use case in source view, right? Less important use case surpressed into the secondary view. * I would keep "Search from Selected", if it is not an issue and as long as it is a secondary choice. * Re: Relationship of design/source - I think there isn't any relationship. You can search on design view and "Go To Source" or you can do text search in source view ... * Re: Invoke Search from Navigator; Let's keep it docked in the bottom part of the Editor but highlight the search results also in Navigator and allow the user to cycle (and actually invoke the Find) also from there.
implemented.
Feature implementation verified