Re: [orion-dev] searchClient.js

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

A bit late chiming in on this thread, but
here is my perspective (having just refactored searchClient.js earlier
this week):

- There are only three consumers of
searchClient.js: 

1) Ctrl+H in editor (web/edit/setup.js)
2) OpenResourceDialog.js
3) globalCommands.js for the global
search box in the banner.

For 1 and 2, this script handles building
the search URL, performing the search, and rendering search results. For
3) it only builds the search URL and the result rendering is performed
separately by the search results page. This is the part I split out on
Monday because it was pulling too many dependencies into our pages (like
the editor).

- I think for 1 and 2 the presentation
of search results should be similar. If one is worth improving, it's probably
worth doing the same improvements in both cases. The showSearchResult function
in searchClient already has some boolean options for different options
between cases 1 and 2. That approach could be used in cases where we really
want different presentation between these two.

- searchClient.js has some code for
rendering "highlights" that is currently unused. Highlights are
snippets produced by Lucene that give some context on the region of the
file that contains the match, much like you see on the google search results
page. I believe I inadvertently disabled this on the server because Libing
was no longer using it in the search results page, and I didn't remember/realize
it was being used by Ctrl+H. I think we should consider turning it back
on, because in this context it might be useful to the user in deciding
which match they want to look at. For this I have opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=369728.

- splitting the presentation of results
out of this script sounds completely reasonable to me. Currently this rendering
code is pretty trivial so the duplication wouldn't bother me (an anchor
containing a text node for the file name). If we wanted to pretty up the
presentation of 'file objects' and use that presentation consistently across
other components that makes complete sense to me. Maybe there's some CSS
that could be used to apply that presentation to reduce duplication in
_javascript_. We purposely made the JSON representation of both files and
search results consistent to make it easier to treat them as the same kind
of object, so that should help.

John

Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx

01/25/2012 12:37 PM

Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx>

To	andrew@xxxxxxxxxxxx, Orion developer discussions <orion-dev@xxxxxxxxxxx>
cc
Subject	Re: [orion-dev] searchClient.js

>A clean solution would be to have a way to decouple
the collecting of the results from how they are presented.  This way
we can handle the presentation in one >location (like a label provider
in the Eclipse world).  If this seems reasonable, I can work with
Kris on a good implementation since this seems to span an area that >we
are both working on.


seems very reasonable to me, Andrew.
As for where it should live....maybe some new js file associated with rendering
orion resource objects. (renderers.js? resourceRendering.js?)
We have a some UI generation utility methods in org.eclipse.orion.client.core/web/orion/util.js
but that is all static stuff.

If you look at the various *explorer.js files scattered around the navigator,
search, git, you'll see that we do some rendering of resource objects there
a lot, and unfortunately we copy a lot of that code around. So a longer
term goal could be to have this stuff also be useful in the explorer renderers
too.

I'd be happy to review or provide input as I think having favorites accessible
from any page is important for 0.4

susan

Andrew
Eisenberg ---01/25/2012 09:17:36 AM---I've been looking at https://bugs.eclipse.org/bugs/show_bug.cgi?id=347058,
getting favorites to appe

From: Andrew Eisenberg <andrew@xxxxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 01/25/2012 09:17 AM
Subject: Re: [orion-dev] searchClient.js
Sent by: orion-dev-bounces@xxxxxxxxxxx

---

I've been looking at https://bugs.eclipse.org/bugs/show_bug.cgi?id=347058,
getting favorites to appear in the open resources dialog.  The problem
that I am going to have is that the presentation of the search results
is wrapped up in the implementation of searchClient.js.  I am going
to want to present the favorites the same way as search results are presented,
but this means I will have to copy the UI code somewhere so both favorites
and search results will look the same in the open resources dialog.  This
seems unfortunate to me.

A clean solution would be to have a way to decouple the collecting of the
results from how they are presented.  This way we can handle the presentation
in one location (like a label provider in the Eclipse world).
 If this seems reasonable, I can work with Kris on a good implementation
since this seems to span an area that we are both working on.

On Wed, Jan 25, 2012 at 8:13 AM, Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
wrote: 
Hi, Kris. First of all, thanks for jumping in and asking
questions...

Libing and/or John is probably the right person to work with on getting
the fix in, but here's my 2 cents in general:

1) I think we are trying to get away from too many API optional features
if we can help it. So I wouldn't start out with the "find a way to
turn on the 'add path' functionality." It's the safest, but kind of
a copout way. I'm guilty of it myself. Back in Eclipse Platform, this would
probably be my choice for a component that's been around forever, and I
have no idea how many plugins are depending on the behavior, etc. etc.
We have more freedom to do the right thing here.

>From a technical/conceptual point of view, "assume that it's the Ctrl+H
implementations problem" is the one I would agree with. As you say,
long files could cause the same problem. But then I think that the patch
should probably try to clean up Ctrl+H itself if that's not opening too
big of a can of worms. Another thing to realize is that we are approaching
a milestone, so a fix that improves one area but makes another one look
worse is probably not going to get in without some attention to the part
that got worse.

2) For 2, I would say use the Orion global search feature on references
to mSearchClient, etc....and from there see if there are more hits. My
knowledge on this is out of date.

As a general point, I would just mention that some of these bugs might
not get looked at til after this week because of our approaching M2 deadline,
and all the committers are pretty swamped trying to wrap things up. So
don't take that as a lack of interest...

susan

Kris
De Volder ---01/24/2012 06:31:10 PM---I created a fix for 336277. And no,
this message is not about trying to get this fix applied ASAP. R

From: Kris De Volder <kdvolder@xxxxxxxxxx>
To: orion-dev@xxxxxxxxxxx
Date: 01/24/2012 06:31 PM
Subject: [orion-dev] searchClient.js
Sent by: orion-dev-bounces@xxxxxxxxxxx

---

I created a fix for 336277. And no, this message is not about trying to
get this fix applied ASAP.
Rather, I'm having some second thoughts about the 'fix' so I'd like some
feedback about some things I'm not so sure about.

All of my changes went into 'searchClient.js' and it does seem to fix what
I was trying to fix. I.e. the 'open resource' dialog to look more like
the desktop one, with ' - path/to/file' appended to entries that have the
same file name.

However I fear about potential side-effects / breakage to other things.
Since the searchClient seems to be a more general bit of functionality
that's probably used by other things as well...

For one, there's the CTRL-H search function. 

I tried that quickly and did find that my 'fix' may cause some UI problems
there. The 'post-it' note that pops up for CTRL-H search results doesn't
seem to have enough space for results if they have long path names appended
to them. (Though I guess the same would probably happen if the file names
where too long as well).

So 3 questions:
1) what should/could I do about the breakage of CTRL-H (some options I
considered):
 - assume that its the CTRL-H implementations problem to deal with
layout/spacing for its search results.
 - find a way to only turn on the 'add path' functionality for CTRL-SHIFT-R
dialog
 - limit the length of the path strings somehow by chopping away bits
if they are 'too long'. 

2) are there other users of searchClient.js that I may have broken that
I don't even know about?

Kris
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev



_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev

_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev