[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] [SnipMatch] New search result display module trial version is finished

newName is used, but not for the variables that we want to be specified in the search query (e.g. it wasn't used for the variables that you added "var" to). Unless I'm missing something (which is entirely possible), this approach makes sense - I don't think we'd want (i), (ii), or (iii) for the particular variable specified with newName.

On Thu, Apr 12, 2012 at 5:52 AM, Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx> wrote:
Just as reference: [1] is a complete reference of the JFace Template Lanugage.

I think that newName() is not a good fit here if proposals should allow for editing and/or reusing existing variables in code. When using newName() it should be possible to (i) jump between the locations where variable names/values will be filled in, (ii) edit multiple occurrences of the same variable at the same time, and (iii) reuse variable guessers for existing variables in the template.


Doug, 
why did you decide to use freeName() instead of var() for template variables? 
Does it make sense to change the templates and remove the parameter specification from Snipmatch in favor of specifying snippets completely using JFace template language? I don't see any real drawback with this solution but I might miss an important point here...

Thanks,
Marcel



[1] http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Fconcepts%2Fconcept-template-variables.htm




On 12.04.2012, at 11:16, Marcel Bruch wrote:

Hi Cheng,

I had a closer look at the templates and I wonder whether we couldn't change them a little bit to make them conform to real JFace templates.

 Example common14.json looks as follows:

{
  "patterns": [
    "move file at $filePathString to folder $dirPathString",
    "move file at $filePathString to directory $dirPathString"
  ],
  "params": [
    {
      "name": "filePathString",
      "majorType": "expr",
      "minorType": "String"
    },
    {
      "name": "dirPathString",
      "majorType": "expr",
      "minorType": "String"
    }
  ],
  "envName": "javasnippet",
  "majorType": "stmt",
  "minorType": "",
  "code": "${import(java.io.File)}\r\n\r\nFile ${file:freeName(file)} \u003d new File(${filePathString});\r\n${file}.renameTo(new File(${dirPathString} + File.separator + ${file}.getName()));",
  "summary": "Move the file at a string path to a directory string path.",
  "id": ""
}

Can't we get rid of the params section when using the jface templates completely? For instance using a snippet such as follows (untested braindump)


${import(java.io.File)} File ${file:newName(java.io.File)} = new File(${filePathString:var(java.lang.String)}); ${file}.renameTo(new File(${dirPathString:var(java.lang.String)+ File.separator + ${file}.getName()));

Or something similar? There might be a little more changes but if this works, we could get rid of the whole parameter section, right?


(I'd prefer this over tests ATM since there are only 15 templates so far ;))


On 12.04.2012, at 08:58, Chen Cheng wrote:

So, my following task is contributing unit test before GSoC starts (maybe fix some exist bugs), right?

2012/4/12 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
Hi,
On 12.04.2012, at 07:35, Chen Cheng wrote:

Hi Marcel,

2012/4/12 Marcel Bruch <marcel.bruch@xxxxxxxxx>
Hi Chen,

You mentioned before, we should prepare a Snipmatch package before Eclipse Juno M2, so what will be focus on after search result display module before M2 ?

IMHO, focus should be:

Doug: check in snipmatch into code recommenders repository
Chen: convert code to the new structure

You mean change project name, re-factor packages etc?
For example, change project name from SnipMatchPlugin -> "org.eclipse.recommenders.snipmatch
Right?

I'm hoping this will be done by Doug? Doug. Maybe it makes sense to commit all the code to gerrit first and work on this patchset until it is in a good shape?

 
Chen: commit changes against gerrit. If possible create only patches smaller than 200 lines. if this is not possible create one large commit.

I am not very sure why we have to create patches smaller than 200 lines. This is Eclipse's rule? Anyway, i will follow this rule. 

all patches below 200 lines don't need an IP check by the Eclipse Legal Team. If it's larger we have a lengthy process to follow. If your initial commit is hard to split into several smaller ones create one large commit to gerrit.


 
Doug: initiate an IP check for that patch.
All: wait for IP check

In the meanwhile:
Integrate snipmatch into the build and write tests ;)

I will start contribute unit test code soon, but i want to know, is there any *special* rules towards unit-test bundles in Eclipse community?

Hard to say ;) You should have a look at the test bundles in our repository to get an idea.
Marcel

 

My time is unfortunately very limited until the 18th April. We apply for a large funding and have the final presentation round net week. After that I'll have a close look.

Marcel

On 11.04.2012, at 11:01, Chen Cheng wrote:

Hi all,

SnipMatch's new search result display module is finished, i built it similar with JDT's content assit, you can find the GUI in the attach picture file. You guys can have a trial of it, then i can improve it according to the feedbacks. Or if there are any advises, you can just post it here.

Marcel,
You mentioned before, we should prepare a Snipmatch package before Eclipse Juno M2, so what will be focus on after search result display module before M2 ?

--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
<search_result_display.png>


_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev




--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

Thanks,
Marcel



_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev




--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

Thanks,
Marcel



_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev