Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] searchClient.js

The search result presentation in searchClient.js is a simple implementation.
Before 0.3M2, the global search(keyword search) result consumed that as well( You can even see it now. Use CTRL+H inside an editor, it will bring you a simple popup version of global search result).
As Susan mentioned, after 0.3M2, we've improved global search result page by using searchExplorer.js, which is more like a MVC pattern.

Andrew, if you think you will follow the same pattern, I'd be happy to help.

Libing



Inactive hide details for Susan Franklin McCourt ---01/25/2012 12:46:35 PM--->A clean solution would be to have a way to decoupSusan Franklin McCourt ---01/25/2012 12:46:35 PM--->A clean solution would be to have a way to decouple the collecting of the results from how they are

From: Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
To: andrew@xxxxxxxxxxxx, Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 01/25/2012 12:46 PM
Subject: Re: [orion-dev] searchClient.js
Sent by: orion-dev-bounces@xxxxxxxxxxx





>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

Inactive hide details for Andrew Eisenberg ---01/25/2012 09:17:36 AM---I've been looking at https://bugs.eclipse.org/bugs/show_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

      Inactive hide details for Kris De Volder ---01/24/2012 06:31:10 PM---I created a fix for 336277. And no, this message is not abKris 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

GIF image


Back to the top