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 87850 - Find on BPEL Design view
Summary: Find on BPEL Design view
Status: VERIFIED FIXED
Alias: None
Product: soa
Classification: Unclassified
Component: BPEL (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Vladimir Yaroslavskiy
URL: http://xdesign-tools.czech.sun.com:80...
Keywords:
Depends on: 88321
Blocks: 81887 89926
  Show dependency tree
 
Reported: 2006-10-24 13:11 UTC by Michael Frisino
Modified: 2007-01-08 10:49 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Frisino 2006-10-24 13:11:20 UTC
Add capability for users to perform search while focus is on BPEL Design view.

Details to follow.
Comment 1 Jiri Kopsa 2006-11-01 20:15:03 UTC
Just adding a test URL ... you may replace it later on with whatever you want.
Comment 2 Jiri Kopsa 2006-11-03 16:20:31 UTC
Adding "gavotte" status whiteboard keyword (for testing of gavotte features query).
Comment 3 Michael Frisino 2006-11-07 16:08:55 UTC
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) 



Comment 4 Jiri Kopsa 2006-11-07 18:28:17 UTC
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"?
Comment 5 Michael Frisino 2006-11-08 01:43:05 UTC
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?
Comment 6 Todd Fast 2006-11-08 02:02:09 UTC
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.
Comment 7 Todd Fast 2006-11-08 02:09:05 UTC
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.
Comment 8 Michael Frisino 2006-11-08 11:30:15 UTC
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 :)))))))))))))))))). 







Comment 9 Michael Frisino 2006-11-08 12:27:34 UTC
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. 



Comment 10 Michael Frisino 2006-11-08 12:33:11 UTC
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.
Comment 11 Todd Fast 2006-11-09 04:59:17 UTC
(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.)

Comment 12 Todd Fast 2006-11-09 05:08:59 UTC
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.
Comment 13 Michael Frisino 2006-11-09 10:18:14 UTC
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.

Comment 14 Michael Frisino 2006-11-09 13:08:17 UTC
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?
Comment 15 Jiri Kopsa 2006-11-09 15:07:24 UTC
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.
Comment 16 Vladimir Yaroslavskiy 2006-12-15 08:01:12 UTC
implemented.
Comment 17 Mikhail Kondratyev 2007-01-08 10:49:55 UTC
Feature implementation verified